メッセージ・フローがイベントを発行するように構成できます。 トランザクション・モニター、トランザクション監査、およびビジネス・プロセス・モニターのために、他のアプリケーションがイベントを読み取って使用できます。
モニター・イベントとは、モニター・イベント・スキーマに準拠する XML 文書です。 各イベントには、以下の情報が含まれます。
詳細については、モニター・イベントを参照してください。
イベント・ソース・アドレスは、メッセージ・フロー内のイベント・ソースを識別します。
ターミナル・イベントはメッセージ・フロー内の任意のノードから発行できるため、専用のイベント発行ノードまたはサブフロー (SupportPac IA9V で提供されるサブフローなど) の代わりとしてこれらを使用できます。
モニターがメッセージ・フローにおいてアクティブな場合にのみ、イベント・ソースはイベントを発行します。
メッセージ・フロー内の任意のターミナルがイベント・ソースとなり得ます。 イベント・ソースがアクティブの場合、eventFilter 式の評価に従い、メッセージがターミナル を通過するたびにイベントを発行します。イベント出力オプションを参照してください。
イベント・ソース | イベント・ソース・アドレス | 説明 |
---|---|---|
トランザクションの開始 | Nodename.transaction.Start | トランスポートからメッセージが読み取られると、イベントが発行されます。 |
トランザクションの終了 | Nodename.transaction.End | WebSphere Message Broker が、メッセージのすべての処理を完了すると、イベントが発行されます。 |
トランザクションのロールバック | Nodename.transaction.Rollback | メッセージ・フローがメッセージ・フロー内でキャッチされない、そして処理されない例外をスローすると、トランザクションの終了の代わりにイベントが発行されます。 |
eventFilter 式の評価に従い、イベントが発行されます。イベント出力オプションを参照してください。
メッセージ・フローがそれ自身の例外を扱う場合、トランザクション・ロールバック・イベントではなくトランザクション終了イベントが発行されます。これは、そのフローがエラーを制御し、正常に終了するからです。 この場合、エラーを判別する必要があるなら、フロー内の適切なノードでターミナル・イベントを構成することができます。
$Body/StockTrade/Details/Value > 10000
これによって、発行されるイベントの数が減るため、モニター・アプリケーションへのワークロードを低減できます。3 >= $Root/MQMD/BackoutCount
$SYS/Broker/brokerName/Monitoring/executionGroupName/flowName
この階層構造を使用すると、サブスクライバーは受信するイベントをフィルターに掛けることができます。 あるサブスクライバーはブローカー内のすべてのメッセージ・フローからのイベントを受信しますが、別のサブスクライバーは単一の実行グループからのイベントのみを受信するようにできます。