bea ホーム | 製品 | dev2dev | support | askBEA |
![]() |
![]() |
|
![]() |
e-docs > Tuxedo > Tuxedo アプリケーション実行時の管理 > イベントのサブスクライブ |
Tuxedo アプリケーション実行時の管理
|
イベントのサブスクライブ
ここでは、次の内容について説明します。
イベント・ブローカを使用するためのプロセス
イベント・ブローカを使用するには、準備作業を行う必要があります。次の図は、それらの準備作業、およびアプリケーション管理者またはプログラマのどちらがその作業を行うのかを示しています。
これらの作業を行う手順に関しては、図のボックスをクリックしてください。 注記 イベント・ブローカで行われる処理を理解するには、bankapp を実行します。これは、BEA Tuxedo システムに同梱のサンプル・アプリケーションです。bankapp のコピー方法とデモとしての実行方法については、『サンプルを使用した BEA Tuxedo アプリケーションの開発方法』の3-1 ページの「bankapp (複雑な C 言語アプリケーション) のチュートリアル」を参照してください。
イベント・ブローカ・サーバの設定
クライアントがイベント・ブローカにアクセスするには、BEA Tuxedo システムで提供されている 2 つのサーバのいずれかを使用します。つまり、アプリケーション・イベントを処理する TMUSREVT(5)、またはシステム・イベントを処理する TMSYSEVT(5) を使用します。このサーバは両方ともイベントを処理し、サブスクライバへの通知を開始します。
ご使用のシステムに BEA 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 サイトには主要サーバを割り当てることをお勧めします。
注記 イベント・ポストとイベント通知に起因するネットワーク・トラフィックは、ネットワーク上の別のマシンにセカンダリ・サーバを割り当てると減らすことができます。
ポーリング間隔の設定
セカンダリ・サーバは、プライマリ・サーバをポーリングして現在のサブスクリプション・リストを取得します。このリストには、フィルタと通知に関するルールが定義されています。デフォルトでは、ポーリングは 30 秒間隔で行われます。必要に応じて、この間隔は変更することができます。
ポーリング間隔 (秒単位) を設定するには、コンフィギュレーション・ファイルの TMUSREVT(5) または TMSYSEVT(5) エントリに -p コマンド行オプションを使用します。
-p poll_seconds
サブスクリプションが追加されている間と、セカンダリ・サーバが更新されている間は、イベント・メッセージが失われたように見えます。
ATMI および EVENT_MIB を使用したイベントのサブスクライブ、ポスト、サブスクライブの取り消し
BEA Tuxedo アプリケーション管理者は、クライアント・プロセスとサーバ・プロセスの代わりに、EVENT_MIB(5) に関する追加情報 の T_EVENT_COMMAND クラスへの呼び出しを行って、サブスクリプションを要求できます。プログラムで tpsubscribe(3c) 関数を呼び出して、イベントをサブスクライブすることもできます。
次の図は、クライアントとサーバがイベント・ブローカを使用して、イベントのサブスクライブ、ポスト、サブスクライブの取り消しを行うプロセスを示しています。
図 6-1 イベントのサブスクライブ
eventexpr およびフィルタを使用したイベント・カテゴリの識別 クライアントまたはサーバがイベントをサブスクライブするには、tpsubscribe(3c) を呼び出します。tpsubscribe() の引数はeventexpr (必須) だけです。eventexpr の値はワイルドカード文字列で、ユーザに通知する必要があるイベント名を識別します。ワイルドカード文字列については、『BEA Tuxedo C リファレンス』の tpsubscribe(3c) リファレンス・ページを参照してください。 たとえば、UNIX システム・プラットフォーム上のユーザに、ネットワーキング・カテゴリに関するすべてのイベントを通知する必要があるとします。その場合、eventexpr に次の値を指定します。 ピリオド (.) の前のバックスラッシュは、ピリオドがリテラルであることを示します。ピリオドの前にバックスラッシュがない場合は、ピリオドは改行文字以外の任意の文字として解釈されます。¥.SysNetwork.* の最後にある .* は、改行文字以外の 0 個以上の任意の文字として解釈されます。 また、クライアントまたはサーバがイベント・データをフィルタするには、tpsubscribe() の呼び出し時に filter 引数 (省略可能) を指定します。filter の値は、ブール値のフィルタ・ルールを含む文字列です。イベント・ブローカがイベントをポストする場合、このルールが正常に評価されることが必要です。 たとえば、ユーザに重要度レベルが ERROR であるシステム・イベントだけを通知する必要があるとします。その場合、filter に次の値を指定します。 イベント名がポストされ、それが eventexpr に合致すると、イベント・ブローカは eventexpr に対応付けられているフィルタ・ルールでポストされたデータをテストします。データがフィルタ・ルールに違反していない場合、またはイベントに対するフィルタ・ルールが存在しない場合、サブスクライバはイベント通知およびイベントと共にポストされたすべてのデータを受け取ります。 イベント・ブローカへのアクセス アプリケーションからイベント・ブローカにアクセスするには、ATMI または EVENT_MIB(5) に関する追加情報 を使用します。次の表は、この 2 つの方法について説明しています。
¥.SysNetwork.*
”TA_EVENT_SEVERITY=’ERROR’”
注記 tppost(3c)、tpsubscribe(3c)、および tpunsubscribe(3c) は C 言語の関数です。これらの関数に相当するルーチン (TPPOST(3cbl)、TPSUBSCRIBE(3cbl)、および TPUNSUBSCRIBE(3cbl)) が COBOL プログラマ用に提供されています。詳細については、『BEA Tuxedo C リファレンス』および『BEA Tuxedo COBOL リファレンス』を参照してください。
通知方法の選択
イベント・ブローカでは、次の図に示すように、各種のイベント通知方法がサポートされています。
図 6-2 イベント・ブローカでサポートされている通知方法
どの通知方法を選択しても、そのインプリメント方法は同じです。tpsubscribe() への呼び出しで、TPEVCTL 型の構造体を参照する引数を指定します。 引数の値が NULL の場合、イベント・ブローカは任意通知型メッセージをサブスクライバに送信します。通知をサービスに送信する方法と、安定記憶域のキューに送信する方法では、クライアントが通知を直接要求することはできません。サブスクライブするには、クライアントがサービス・ルーチンを呼び出す必要があります。 各サブスクリプションに対して、次の通知方法を選択することができます。つまり、イベント・ブローカでは以下を行うことができます。
イベントへのサブスクリプションの取り消し
クライアントが tpterm(3c) を呼び出してアプリケーションを終了すると、サブスクリプションが永続として指定されていない限り、すべてのサブスクリプションは取り消されます。永続として指定されている場合、クライアントが tpterm() を実行した後でも、サブスクリプションは引き続きポストを受け取ります。クライアントが後でアプリケーションに再度参加し、これらのサブスクリプションを新しくする場合、再度サブスクライブする必要があります。
良く設計されたクライアントは、tpterm() を呼び出す前にサブスクライブを取り消します。その場合、アプリケーションを終了する前に、tpunsubscribe(3c) を呼び出します。
トランザクションでのイベント・ブローカの使用
トランザクションでイベント・ブローカを使用する場合は、次の内容に注意してください。
注記 この方法は、BEA Tuxedo サービスが呼び出されるサブスクリプション、またはレコードを永続的なキューに登録するサブスクリプションに対してのみ使用できます。
イベント・ブローカでのトランザクションのしくみ
ポスト元とサブスクライバがトランザクションをリンクすることに合意すると、ボーティング・フォームが作成されます。ポスト元では、なんらかの条件が合致するとアサーションを出力し、メッセージをトランザクションに対応付けます。つまり、元のプロセスを離れたメッセージは、トランザクションと対応付けられていると見なされます。そのトランザクションはイベント・ブローカに渡されます。
サービスの呼び出しやサブスクライバに対してメッセージをキューに格納することなど、イベント・ブローカの処理も同じトランザクションの一部です。実行中のサービス・ルーチンがエラーを検出すると、そのルーチンはトランザクションを失敗させることができます。その場合、トランザクションに関与するほかのすべてのサブスクリプションおよびポストされた元のトランザクションなど、ほかのサービスを呼び出していたり、ほかのデータベース処理を行っていたすべての処理がロールバックされます。ポスト元は (「ポスト元」がこの処理を行うという) アサーションを出力し、データを提供し、そのデータをトランザクションとリンクさせます。
数多くの無名サブスクライバ、つまりポスト元が認識していないサブスクライバは、トランザクションに関与して呼び出されます。サブスクライバがその処理をポスト元の処理とリンクできなかった場合、トランザクション全体がロールバックされます。トランザクションに関与するすべてのサブスクライバは、その処理をポスト元の処理とリンクする必要があります。リンクしないと、すべての処理がロールバックされます。ポスト元がそのトランザクションでポストすることを許可していない場合、イベント・ブローカによって別のトランザクションが開始され、トランザクションに関与するすべてのサブスクリプションがそのトランザクションに集められます。これらのトランザクションのいずれかが失敗すると、トランザクションに関与するサブスクリプションの代わりに行われたすべての処理はロールバックされます。ただし、ポスト元のトランザクションはロールバックされません。このプロセスは、TPEVTRAN フラグによって制御されます。
トランザクションでのイベント・ブローカの使用例
株式売買が、取引売買アプリケーションで完了しようとしています。取引トランザクションで、各種のサービスによって数多くのデータベース・レコードが更新されました。イベントがポストされると、取引が今行われようとしていることが通知されます。
このような取引の監査を記録するアプリケーションは、このイベントをサブスクライブしています。つまり、このアプリケーションでは、このようなイベントがポストされたら、指定されたキューに必ずレコードを格納するように要求しています。サービス・ルーチンは取引を実行できるかどうかを決定し、このようなイベントをサブスクライブしています。また、そのような取引が行われる場合は通知されます。
すべての処理が問題なく行われると、取引が完了し、監査が記録されます。
キューでエラーが発生し、監査が記録されなかった場合、株式取引全体がロールバックされます。同様に、サービス・ルーチンが失敗すると、トランザクションがロールバックされます。すべての処理が正常に行われると、取引が行われてトランザクションがコミットされます。
関連項目
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |