6 イベントのサブスクライブ

このトピックには、次の項があります。

6.1 イベント・ブローカを使用するためのプロセス

イベント・ブローカを使用するには、準備ステップの完了が必要です。次のフローチャートは、これらのステップをリストし、およびアプリケーション管理者またはプログラマがそのステップを行うべきかを示しています。

図6-1 イベント・ブローカを使用するための準備ステップ


イベント・ブローカを使用するための準備ステップ

これらの作業を行う手順に関しては、図のボックスをクリックしてください。

ノート: イベント・ブローカで行われる処理を学習するよい方法は、bankapp (Oracle Tuxedoシステムに同梱のサンプル・アプリケーション)を実行することです。bankappのコピー方法とデモとしての実行方法については、『Oracle Tuxedo ATMIアプリケーション開発のためのチュートリアル』のbankapp(完全なCアプリケーション)のチュートリアルに関する項を参照してください。

6.2 イベント・ブローカ・サーバーの構成

クライアントがイベント・ブローカにアクセスするには、Oracle Tuxedoシステムで提供されている2つのサーバーのいずれかを使用します。つまり、アプリケーション・イベントを処理するTMUSREVT(5)、またはシステム・イベントを処理するTMSYSEVT(5)を使用します。このサーバーは両方ともイベントを処理し、サブスクライバへの通知をトリガーします。

ご使用のシステムにOracle Tuxedoのイベント・ブローカを構成するには、次の例に示すように、この2つのサーバーのいずれかまたは両方をUBBCONFIGファイルのSERVERSセクションで設定します:

*SERVERS 
TMSYSEVT SRVGRP=ADMIN1 SRVID=100 RESTART=Y GRACE=900 MAXGEN=5 
CLOPT="-A --" 
TMSYSEVT SRVGRP=ADMIN2 SRVID=100 RESTART=Y GRACE=900 MAXGEN=5 
CLOPT="-A -- -S -p 90" 
TMUSREVT SRVGRP=ADMIN1 SRVID=100 RESTART=Y 
MAXGEN=5 GRACE=3600 
CLOPT="-A --" 
TMUSREVT SRVGRP=ADMIN2 SRVID=100 RESTART=Y 
MAXGEN=5 GRACE=3600
CLOPT="-A -- -S -p 120"

どちらのサーバーもネットワーク上の任意の場所に配置できます。ただし、MASTERサイトには主要サーバーを割り当てることをお薦めします。

ノート:

イベント・ポストとイベント通知に起因するネットワーク・トラフィックは、ネットワーク上の別のマシンにセカンダリ・サーバーを割り当てると減らすことができます。

6.3 ポーリング間隔の設定

セカンダリ・サーバーは、プライマリ・サーバーをポーリングして現在のサブスクリプション・リストを取得します。このリストには、フィルタリングと通知に関するルールが定義されています。デフォルトでは、ポーリングは30秒間隔で行われます。必要に応じて、この間隔は変更することができます。

ポーリング間隔(秒単位で表される)を設定するには、構成ファイルのTMUSREVT(5)またはTMSYSEV(5)エントリに次のように-pコマンド行オプションを使用します。

-p poll_seconds

サブスクリプションが追加されている間と、セカンダリ・サーバーが更新されている間は、イベント・メッセージが失われたように見えます。

6.4 ATMIおよびEVENT_MIBを使用したイベントのサブスクライブ、ポスト、サブスクライブ解除

Oracle Tuxedoアプリケーション管理者は、クライアント・プロセスとサーバー・プロセスのかわりに、EVENT_MIB(5)T_EVENT_COMMANDクラスを呼び出して、サブスクリプション・リクエストを入力できます。プログラムでtpsubscribe(3c)関数を呼び出して、イベントをサブスクライブすることもできます。

次の図に、クライアントとサーバーがイベント・ブローカを使用して、イベントのサブスクライブ、ポスト、サブスクライブ解除を実行するプロセスを示します。

イベントのサブスクライブ

図6-2 イベントのサブスクライブ


イベントのサブスクライブ

6.4.1 eventexprおよびフィルタを使用したイベント・カテゴリの識別

クライアントまたはサーバーがイベントをサブスクライブするには、tpsubscribe(3c)を呼び出します。tpsubscribe()の引数はeventexpr (必須)だけです。eventexprの値はワイルドカード文字列で、ユーザーに通知する必要があるイベント名を識別します。ワイルドカード文字列については、『Oracle Tuxedo ATMI C関数リファレンス』tpsubscribe(3c)リファレンス・ページを参照してください

たとえば、UNIXシステム・プラットフォーム上のユーザーに、ネットワーキング・カテゴリに関するすべてのイベントを通知する必要があるとします。その場合、eventexprに次の値を指定します:

\.SysNetwork.*

ピリオド(.)の前のバックスラッシュは、ピリオドがリテラルであることを示します。(ピリオドの前にバックスラッシュがない場合は、ピリオドは改行文字以外の任意の文字として解釈されます。)\.SysNetwork.*の最後にある.*は、改行文字以外の0個以上の任意の文字として解釈されます。

また、クライアントまたはサーバーがイベント・データをフィルタするには、tpsubscribe()の呼出し時にfilter引数(オプション)を指定します。filterの値は、ブール値のフィルタ・ルールを含む文字列です。イベント・ブローカがイベントをポストする場合、このルールが正常に評価されることが必要です。

たとえば、ユーザーに重大度レベルが ERRORであるシステム・イベントだけを通知する必要があるとします。その場合、filterに次の値を指定します。

”TA_EVENT_SEVERITY=’ERROR’”

イベント名がポストされ、それがeventexprに合致すると、イベント・ブローカはeventexprに対応付けられているフィルタ・ルールでポストされたデータをテストします。データがフィルタ・ルールに違反していない場合、またはイベントに対するフィルタ・ルールが存在しない場合、サブスクライバはイベント通知およびイベントと共にポストされたすべてのデータを受け取ります。

6.4.2 イベント・ブローカへのアクセス

アプリケーションからイベント・ブローカにアクセスするには、ATMIまたは(EVENT_MIB(5)を使用します。

次の表で、両方の方法について説明します。

イベント・ブローカへのアクセス

表6-1 イベント・ブローカへのアクセス

     
ATMI tppost(3c) イベント・ブローカに通知を行うか、またはイベントとそれに伴うデータをポストします。イベント名はeventname引数とdata引数で指定され、NULL以外の場合はデータを指します。ポストされたイベントとそのデータは、Oracle Tuxedoのイベント・ブローカによって、eventnameに対して正常に評価されるサブスクリプション、およびdataに対して正常に評価されるフィルタ・ルール(オプション)が設定されたすべてのサブスクライバにディスパッチされます
tpsubscribe(3c) eventexprで指定されたイベントをサブスクライブします。サブスクリプションはOracle Tuxedoのイベント・ブローカによって保持され、tppost()を介してイベントがポストされたときにサブスクライバに通知するために使用されます。各サブスクリプションには、クライアントへの通知、サービスの呼び出し、安定したストレージ・キューへの登録、コマンドの実行、ユーザー・ログへの記録のいずれかの方法が指定されています。通知方法は、サブスクライバのプロセス・タイプ(つまり、プロセスがクライアントであるか、サーバーであるか)、および tpsubscribe()に渡される引数によって決定されます。
tpunsubscribe(3c) Oracle Tuxedoのイベント・ブローカのアクティブ・サブスクリプションのリストから、イベント・サブスクリプションを削除します。subscriptionは、tpsubscribe()で返されるイベント・サブスクリプション・ハンドルです。subscriptionをワイルドカード値の-1に設定すると、呼出し側プロセスが以前に行ったすべての非永続的なサブスクリプションがtpunsubscribeによって取り消されます。非永続的なサブスクリプションとは、tpsubscribe()のctl->flagsパラメータにTPEVPERSISTビットが設定されずに行われたサブスクリプションです。持続タイプのサブスクリプションは、tpsubscribe()から返されたハンドルを使用することによってのみ削除できます。
EVENT_MIB(5) なし EVENT_MIBは、サブスクリプション情報およびフィルタリング・ルールを格納する管理情報ベース(MIB)です。EVENT_MIBを使用しても、Oracle Tuxedoのイベント・ブローカに新しいイベントをアプリケーションで定義することはできません。ただし、イベント・ブローカをカスタマイズして、イベントを追跡し、アプリケーションに要求されるイベントの発生をサブスクライバに通知することができます。EVENT_MIBを使用して、イベントのサブスクライブまたはサブスクリプションの変更や取消しを行うことができます。

ノート:

tppost(3c)tpsubscribe(3c)、およびtpunsubscribe(3c)はCの関数です。これらの関数に相当するルーチン(TPPOST(3cbl)TPSUBSCRIBE(3cbl)、およびTPUNSUBSCRIBE(3cbl))がCOBOLプログラマ用に提供されています。『Oracle Tuxedo ATMI C関数リファレンス』および『Oracle Tuxedo ATMI COBOL関数リファレンス』を参照してください。

6.5 ドメイン全体のイベントのサブスクライブ、ポストおよびサブスクライブ解除

6.5.1 概要

クロス・ドメイン環境でブローカ・イベントのサブスクライブ、ポストおよびサブクスライブ解除を行うための機能がTuxedoに追加されています。

この機能を有効にするには、静的イベント入出力情報を管理するために、DM_EVT_INおよびDM_EVT_OUTという2つの新しいセクションがDMCONFIGに追加されています。

DM_EVT_INおよびDM_EVT_OUTの詳細は、『Tuxedoリファレンス・ガイド』DMCONFIG(5)に関する項を参照してください。

ノート:

UBBCONFIGでは、GWTサーバーの前にEvtBrokerサーバーを構成する必要があります。これは、GWTが起動時にEvtBrokerへの構成済イベントをサブスクライブするためです。
6.5.1.1 ドメインを横断するブローカ・イベントの処理方法

次の図に、クロス・ドメイン環境におけるブローカ・イベントのサブスクライブ、ポストおよびサブクスライブ解除の一般的な処理フローを示します。

クロス・ドメイン・イベントの全体フロー

図6-3 クロス・ドメイン・イベントの全体フロー


クロス・ドメイン・イベントの全体フロー

6.5.1.2 DMCONFIGの構成方法 — ケース・スタディ

この使用事例では、DMCONFIGがどのように構成されるかを詳しく説明します。

図6-3に示すように、2つのクライアント(クライアントAおよびクライアントB)が2つのドメイン(ドメインAおよびドメインB)に設置され、各ドメインにはSHMモードのマシンが1台ずつ(マシンAおよびマシンB)含まれます。

マシンAについて、dmloadcfを使用して、次に示すようにDMCONFIGの追加構成を有する新しいBDMCONFIGを作成し、次にtmboot Tuxedoを使用します。

*DM_EVT_IN

MACHINEB_EVT

LACCESSPOINT=DOMAINA

*DM_EVT_OUTMACHINEA_EVT

LACCESSPOINT= DOMAINA

RACCESSPOINT= DOMAINB

マシンBについて、dmloadcfを使用して、次に示すようにDMCONFIGの追加構成を有する新しいBDMCONFIGを作成し、次にtmboot Tuxedoを使用します。

*DM_EVT_IN MACHINEA_EVT /> LACCESSPOINT=DOMAINB

*DM_EVT_OUT

MACHINEB_EVT

LACCESSPOINT= DOMAINB

RACCESSPOINT= DOMAINA

上記のとおりに構成した後、2つのクライアントごとに次に示す2ステップのテストを実行します。

  1. クライアントBはマシンBでtpsubscribe (“MACHINEA_EVT”)を発行します。
  2. クライアントAはマシンAでtppost (“MACHINEA_EVT”)を発行します。

結果: DMCONFIGが正しく構成されていれば、クライアントBはイベントMACHINEA_EVTを受信します。

クロス・ドメイン環境では、すべてのイベントが明示的にインポート/エクスポートされます(不明なドメインへのリクエストは受け入れられません)。正しく構成されると、GWTサーバーはTuxedoの起動時にローカル・イベント・ブローカへのすべての構成済イベントを自動的にサブスクライブします。リモート・イベント・メッセージを受信すると、ローカルGWTはそのリクエストをイベント・ブローカに転送します。一方、ローカル・イベントがポストされると、イベント・ブローカはそのイベントをローカルGWT (そのイベントをサブスクライブ済)に転送します。その後、ローカルGWTはそのイベントを構成済リモート・ドメインのGWTに転送します。

6.5.2 イベント構成の動的変更

ユーザーが上記のとおりに静的構成を設定できるようになる以外にも、Tuxedoでは、システムをシャットダウンせずに必要に応じてイベント構成を動的に変更するための2種類の管理方法(dmadminコマンドおよびMIB操作)を使用できます。

dmadmin」コマンドでは、イベント構成を動的にサポートするサブコマンド(「advertiseevent」および「unadvertiseevent」)ならびに2つのセクション(「EVENTS_IN」および「EVENTS_OUT」)が追加されます。関連クラスがMIB操作に追加されます。

詳細は、『Tuxedoコマンド・リファレンス』dmadmin(1)に関する項および『Tuxedoリファレンス・ガイド』DM_MIB(5)に関する項を参照してください。

6.5.3 相互運用性

クロス・ドメイン・イベント・ブローカ機能がサポートされるのは、GWTおよびEvtBrokerの両方がOracle Tuxedo 12cリリース1 (12.1.1)以上で実行されている場合のみです。

6.6 通知方法の選択

イベント・ブローカでは、次の図に示すように、サブスクライバにイベントを通知する様々な方法がサポートされています。

イベント・ブローカでサポートされている通知方法

図6-4 イベント・ブローカでサポートされている通知方法


イベント・ブローカでサポートされている通知方法

どの通知方法を選択しても、その実装方法は同じです。 tpsubscribe()への呼出しで、TPEVCTL型の構造体を参照する引数を指定します。

引数の値がNULLの場合、イベント・ブローカは非請求メッセージをサブスクライバに送信します。通知をサービスに送信する方法と、安定したストレージ・キューに送信する方法では、クライアントが通知を直接要求することはできません。サブスクライブするには、クライアントがサービス・ルーチンを呼び出す必要があります。

各サブスクリプションに対して、次の通知方法を選択することができます。イベント・ブローカでは次のことを行うことができます:

  • クライアントへの通知 - イベント・ブローカは、クライアントへの通知が必要なイベントを追跡します。該当するイベントが発生すると、非請求通知をクライアントに送信します。匿名でポストされるイベントもあります。ほかのクライアントがサブスクライブしているかどうかにかかわらず、クライアントはアプリケーションに参加し、イベント・ブローカにイベントをポストできます。イベント・ブローカは、これらのイベントをサブスクリプションのデータベースと照合し、該当するクライアントに非請求通知を送信します。『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「EVENT_MIB(5)」T_EVENT_CLIENTクラスの定義を参照してください。
  • サービスの呼出し - サブスクライバがイベント通知をサービス呼出しに渡す必要がある場合、ctlパラメータが有効なTPEVCTL構造体を指していることが必要です。『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「EVENT_MIB(5)」T_EVENT_SERVICEクラスの定義を参照してください。
  • 安定したストレージ・キューへのメッセージの登録 - 安定したストレージ・キューへのサブスクリプションでは、マッチングを実行できるようにeventexprおよびfilterの値のほかに、キュー・スペース、キュー名、相関識別子が指定されています。これは、合致を検出する場合に使用されます。 相関識別子は、同じイベント記述とフィルタ・ルールが定義され、格納先が同じキューである複数のサブスクリプションを区別するために使用されます。『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「EVENT_MIB(5)」T_EVENT_QUEUEクラスの定義を参照してください。
  • コマンドの実行 - EVENT_MIBT_EVENT_COMMAND クラスを使用して、サブスクライバは実行可能プロセスを呼び出すことができます。合致するデータが検出されると、そのデータは要求されたオプションと、実行可能プロセスの名前として使用されます。『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「EVENT_MIB(5)」T_EVENT_COMMANDクラスの定義を参照してください。
  • ユーザー・ログ(ULOG)へのメッセージの記録 - EVENT_MIBT_EVENT_USERLOGクラスを使用して、サブスクライバはシステムUSERLOGメッセージを書き込むことができます。イベントが検出されて合致すると、これらのイベントはUSERLOGに書き込まれます。『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』「EVENT_MIB(5)」T_EVENT_USERLOGクラスの定義を参照してください。

6.7 イベントへのサブスクリプションの取消し

クライアントがtpterm(3c)を呼び出してアプリケーションを終了すると、サブスクリプションが永続として指定されていないかぎり、すべてのサブスクリプションは解除されます。(永続として指定されている場合、クライアントがtpterm()を実行した後でも、サブスクリプションは引き続きポストを受け取ります。)クライアントが後でアプリケーションに再度参加し、これらのサブスクリプションを新しくする場合、再度サブスクライブする必要があります。

良く設計されたクライアントは、tpterm()を呼び出す前にサブスクライブを取り消します。その場合、アプリケーションを終了する前に、tpunsubscribe(3c)呼出しを発行します。

6.8 トランザクションでのイベント・ブローカの使用

トランザクションでイベント・ブローカを使用する場合は、次の内容に注意してください。

  • トランザクションでイベント・ブローカを使用する前に、イベント・ブローカを実行しているサーバー・グループで、TMUSREVT(5)サーバーにNULL_TMSパラメータを構成する必要があります。
  • トランザクションにイベントをポストする長所は、トランザクションが成功すると、ポストに関係のない処理も含めて、すべての処理が必ず完了することです。トランザクション内で行われたいずれかの処理が失敗すると、トランザクション内で行われたすべての処理は必ずロールバックされます。短所は、なんらかの理由でトランザクションがアボートすると、ポストが失われる可能性があることです。
  • サブスクリプションがトランザクションの一部であることを指定するには、tpsubscribe(3c)TPEVTRANフラグを使用します。サブスクリプションがトランザクションに関与して行われた場合、イベントに応答して行われる処理は、呼出し側のトランザクションの一部として行われます。

    ノート:

    この方法は、Oracle Tuxedoサービスが呼び出されるサブスクリプション、またはレコードを永続的なキューに登録するサブスクリプションに対してのみ使用できます。

6.8.1 イベント・ブローカでのトランザクションのしくみ

ポスト元とサブスクライバがトランザクションをリンクすることに合意すると、ボーティング・フォームが作成されます。ポスト元では、なんらかの条件が合致するとアサーションを出力し、メッセージをトランザクションに対応付けます。(つまり、元のプロセスを離れたメッセージは、トランザクションと対応付けられていると見なされます。)そのトランザクションはイベント・ブローカに渡されます。

サービスの呼び出しやサブスクライバに対してメッセージをキューに格納することなど、イベント・ブローカの処理も同じトランザクションの一部です。実行中のサービス・ルーチンがエラーを検出すると、そのルーチンはトランザクションを失敗させることができます。その場合、トランザクションに関与するほかのすべてのサブスクリプションおよびポストされた元のトランザクションなど、ほかのサービスを呼び出していたり、ほかのデータベース処理を行っていたすべての処理がロールバックされます。ポスト元はアサーションを実行(「私がこれを行います」と表明)し、データを提供し、そのデータをトランザクションとリンクさせます。

数多くの無名サブスクライバ、つまりポスト元が認識していないサブスクライバは、トランザクションに関与して呼び出されます。サブスクライバがその処理をポスト元の処理とリンクできなかった場合、トランザクション全体がロールバックされます。トランザクションに関与するすべてのサブスクライバは、その処理をポスト元の処理とリンクする必要があります。リンクしないと、すべての処理がロールバックされます。ポスト元がそのトランザクションでポストすることを許可していない場合、イベント・ブローカによって別のトランザクションが開始され、トランザクションに関与するすべてのサブスクリプションがそのトランザクションに集められます。これらのトランザクションのいずれかが失敗すると、トランザクションに関与するサブスクリプションの代わりに行われたすべての処理はロールバックされます。ただし、ポスト元のトランザクションはロールバックされません。このプロセスは、TPEVTRANフラグによって制御されます。

6.8.1.1 トランザクションでのイベント・ブローカの使用例

株式売買が、取引売買アプリケーションで完了しようとしています。取引トランザクションで、各種のサービスによって数多くのデータベース・レコードが更新されました。イベントがポストされると、取引が今行われようとしていることが通知されます。

このような取引の監査を記録するアプリケーションは、このイベントをサブスクライブしています。つまり、このアプリケーションでは、このようなイベントがポストされたら、指定されたキューに必ずレコードを格納するように要求しています。サービス・ルーチンは取引を実行できるかどうかを決定し、このようなイベントをサブスクライブしています。また、そのような取引が行われる場合は通知されます。

すべての処理が問題なく行われると、取引が完了し、監査が記録されます。

キューでエラーが発生し、監査が記録されなかった場合、株式取引全体がロールバックされます。同様に、サービス・ルーチンが失敗すると、トランザクションがロールバックされます。すべての処理が正常に行われると、取引が行われてトランザクションがコミットされます。

関連項目