使用するノードの決定

WebSphere® Message Broker には、メッセージ・フロー内で使用できるメッセージ処理ノードが多数あります。

始める前に:

メッセージ・フロー・ノードに関する概念トピックに目を通しておきます。

WebSphere Message Broker はまた、ユーザー定義ノードと呼ばれる独自のノードを定義するのに使用できるインターフェースも提供します。

どのノードを使用するかは、メッセージに対して実行する処理によって異なります。

入出力ノード
入出力ノードは、クライアント・アプリケーションがメッセージを送信する先のメッセージ・フロー中のポイント (MQInput などの入力ノード) を定義し、また、どのクライアント・アプリケーションからメッセージを受信するか (MQOutput などの出力ノード) を定義します。 クライアント・アプリケーションは、ノードがメッセージの送信元または宛先として指定した I/O リソースとの間でメッセージの書き込みと読み取りを行うことにより、これらのノードと相互作用します。 メッセージ・フローには少なくとも 1 つの入力ノードが組み込まれていなければなりませんが、出力ノードが組み込まれている必要はありません。
  • ブローカーにデプロイするためのメッセージ・フローを作成する場合、メッセージを受け取る入力ノードを少なくとも 1 つ組み込む必要があります。 選択する入力ノードは、入力メッセージの送信元、およびメッセージを受け取りたいフロー内の場所によって異なります。
    MQInput
    メッセージが WebSphere MQ キューのブローカーに到達し、ノードがメッセージ・フローの先頭になる場合は、MQInput ノードを使用します。

    MQeInput ノードを含むメッセージ・フローを WebSphere Message Broker バージョン 6.0 で使用することは推奨されていません。 メッセージ・フローを再設計して、MQe ノードを除去し、独自の仕様に構成され MQe ゲートウェイ構成で調整された MQ ノードに置き換えてください。 詳細については、WebSphere MQ Everyplace ノードを含むメッセージ・フローのマイグレーションを参照してください。

    MQGet
    メッセージが WebSphere MQ キューのブローカーに到達し、ノードがメッセージ・フローの先頭にならない場合は、MQGet ノードを使用します。
    SCADAInput
    メッセージが telemetry 装置によって送信される場合は、SCADAInput ノードを使用します。
    HTTPInput
    メッセージが Web サービス・クライアントによって送信される場合は、HTTPInput ノードを使用します。
    Real-timeInputまたはReal-timeOptimizedFlow
    メッセージが JMS またはマルチキャスト・アプリケーションによって送信される場合は、これらのノードのいずれかを使用します。

    Real-timeInput ノードは入力ノードであり、Real-timeOptimizedFlow ノードは高性能のパブリッシュ/サブスクライブ・メッセージ・フローを提供する完全なメッセージ・フローです。

    JMSInput
    メッセージが JMS アプリケーションによって送信される場合は、JMSInput ノードを使用します。
    ユーザー定義入力ノード
    メッセージ送信元が、異なるプロトコルまたはトランスポートを使用するクライアントまたはアプリケーションである場合は、ユーザー定義入力ノードを使用します。
    Input ノード
    スタンドアロン・メッセージ・フローとしてデプロイしない、別のメッセージ・フローに埋め込みたいメッセージ・フロー (サブフロー) を作成している場合、メッセージを受け取る少なくとも 1 つの Input ノードを、そのサブフローに組み込む必要があります。

    Input ノードのインスタンスは In ターミナルを表します。例えば、Input ノードのインスタンスを 1 つ組み込んだ場合、サブフローのアイコンは、別のノードに接続するのと同じ方法でメイン・フローの他のノードに接続できる 1 つの In ターミナルを表示します。

    メッセージ・フローをデプロイするには、少なくとも 1 つの入力ノードが必要です。メッセージ・フローに入力ノードが含まれていない場合には、それをブローカー・アーカイブ・ファイルに追加することはできません。 入力ノードはメイン・フロー、またはメイン・フローに組み込まれたメッセージ・フローに置くことができます。

    メッセージ・フローでは、複数の入力ノードを使用できます。 詳しくは、複数の入力ノードの使用を参照してください。

  • メッセージ・フローで作成されたメッセージをターゲット・アプリケーションに送信する場合、1 つ以上の出力ノードを組み込むことができます。 選択する出力ノードは、次のように、そのメッセージのターゲット・アプリケーションでの受け取りの際に予定されているトランスポートによって決まります。
    Publication
    パブリッシュ/サブスクライブ・ネットワークを使用して、サポートされるすべてのプロトコルを介してブローカーにサブスクライブするアプリケーションにメッセージを配布する場合は、Publication ノードを使用します。 Publication ノードは出力ノードであり、それが使用する出力宛先は、現在のメッセージの特性とサブスクリプションが一致するサブスクライバーによって識別されます。
    MQOutput
    WebSphere MQ キュー上、または入力メッセージ MQMD に指定されている WebSphere MQ 応答先キュー上で、ターゲット・アプリケーションがメッセージを受け取る予定の場合は、MQOutput ノードを使用します。

    MQeOutput ノードを含むメッセージ・フローを WebSphere Message Broker バージョン 6.0 で使用することは推奨されていません。 メッセージ・フローを再設計して、MQe ノードを除去し、独自の仕様に構成され MQe ゲートウェイ構成で調整された MQ ノードに置き換えてください。 詳細については、WebSphere MQ Everyplace ノードを含むメッセージ・フローのマイグレーションを参照してください。

    MQReply
    入力メッセージ MQMD に指定されている WebSphere MQ 応答先キュー上で、ターゲット・アプリケーションがメッセージを受け取る予定である場合は、MQReply ノードを使用します。
    SCADAOutput
    telemetry 装置が出力メッセージのターゲットであり、Publication ノードが適切でない場合は、SCADAOutput ノードを使用します。
    HTTPReply
    メッセージが Web サービス・クライアント要求に応答している場合は、HTTPReply ノードを使用します。
    HTTPRequest
    メッセージ・フローが Web サービスと対話する場合は、HTTPRequest ノードを使用します。
    Real-timeOptimizedFlow
    ターゲット・アプリケーションが JMS またはマルチキャスト・アプリケーションである場合は、Real-timeOptimizedFlow ノードを使用します。
    JMSOutput
    メッセージが JMS 宛先に対するものである場合は、JMSOutput ノードを使用します。
    ユーザー定義出力ノード
    ターゲットが、異なるプロトコルまたはトランスポートを使用するクライアントまたはアプリケーションである場合は、ユーザー定義出力ノードを使用します。
    Output ノード
    スタンドアロン・メッセージ・フローとしてデプロイしない、別のメッセージ・フローに埋め込みたいメッセージ・フロー (サブフロー) を作成する場合、接続する後続のノードにメッセージを伝搬する少なくとも 1 つの Output ノードを、サブフローに組み込む必要があります。

    Output ノードのインスタンスは Out ターミナルを表します。例えば、Output ノードのインスタンスを 2 つ組み込んだ場合、サブフローのアイコンは、2 つの Out ターミナルを表示します。これを、他のノードに接続するのと同じ仕方で、メイン・フロー内の他のノードに接続することができます。

メッセージの操作、拡張、および変換を行うためのノード

たいていどの企業でも、さまざまなシステム上で、さまざまなプログラム言語とさまざまな通信方法を使って、長年に渡って開発されてきた複数のアプリケーションがあるものです。 WebSphere Message Broker では、メッセージの形式を変換するようにメッセージ・フローを構成する機能を提供することにより、アプリケーションがこうした相違を理解しなくても良いようになっています。

例えば、個人名を保持する形式は多数あり、アプリケーションごとに異なります。 姓を最初と最後のどちらに置くか、ミドルネームのイニシャルの有無、大/小文字の別は、置換される可能性のある事柄のほんの一部に過ぎません。各アプリケーションの要件を認識するようにメッセージ・フローを構成できるので、送信または受信アプリケーションには変更を加えることなく、各メッセージを正しい形式に変換できます。

メッセージの内容を処理し、いくつかの方法でそれを更新することができます。 ここでのユーザーの選択は、メッセージ・フローが処理するのが、事前定義 (モデル化) メッセージなのか、自己定義メッセージ (例えば XML) なのか、またはその両方なのかによって異なります。

メッセージ・フローでは、メッセージを完全に再作成すること、メッセージの形式 (フィールドの順番、バイト・オーダー、言語、その他) を変換すること、メッセージから内容を除去すること、またはメッセージに特定のデータを挿入することができます。例えば、あるノードでは、データベースと対話して追加情報を検索すること、あるいはメッセージのコピー (全体または一部) をデータベースに保管して、オフライン処理を可能にすることができます。

以下の例は、メッセージ変換がどれほど重要なものになりえるかを示しています。
  • ある受注入力アプリケーションは Part ID をメッセージの本文に入れるのに対し、それと関連付けられた在庫アプリケーションは Part ID がメッセージ・ヘッダーに入っているものと期待しています。 メッセージをあるメッセージ・フローに送ります。 このメッセージ・フローは、これらの 2 種類の形式が分かっているので、必要に応じて情報を形式設定し直すことができます。
  • あるデータ入力アプリケーションは、株式取引情報の入ったメッセージを作成します。 このメッセージを受信するアプリケーションによっては、そのままの情報を必要とする場合も、メッセージに株価収益 (PE) 率の情報を追加する必要がある場合もあります。 株式取引メッセージをあるメッセージ・フローに送ります。 このメッセージ・フローは、ある出力ノードへはメッセージに変更を加えずに渡し、他の出力ノードへは付加的な情報を計算して追加します。 それを行うため、このメッセージ・フローでは、データベースで現在の株価を検索し、この値と元のメッセージの取引情報を使用して PE 値を計算してから、更新したメッセージを渡します。

また、以下のノードを使って相互に対話するメッセージ・フローを作成することもできます。 あるメッセージ・フローのデフォルト操作が他のメッセージ・フローの操作に影響を与えることはありませんが、データベースなどの外部ソースで情報の保管や検索を行うようにメッセージ・フローを構成すれば、このアクションを強制的に起こすことができます。

Compute
以下の目的で、Compute ノードを使用します。
  • メッセージ内容を操作する
  • 何らかの方法でメッセージを変換する
  • データベースと対話してメッセージまたはデータベースの内容を変更し、1 つ以上の新しいメッセージを渡す
このノードを使用して、事前定義および自己定義メッセージを操作することができます。

ESQL エディターを使って ESQL モジュールを作成します。これはこのノードに特有のものであり、メッセージまたはデータベースに対して実行するアクションを定義するステートメントが入ります。 他のいかなるタイプのノードにおいても、Compute ノード内で使用するために作成した ESQL コードは使用しないでください。

このノードがデータベースにアクセスする方法を、ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、制御することができます。 これらの値を初期化し、保守するには、mqsisetdbparms コマンドを使用します。

メッセージ操作の要件が複雑な場合、これらを単一の Compute ノード内で実行してください。少ない数の、より複雑な Compute ノードのパフォーマンスの方が、大量の単純なノードよりも良好です。 これは、ブローカーはそれぞれの Compute ノードへのエントリーの時点で、メッセージを構文解析するからです。

JavaCompute
以下の目的で、JavaCompute ノードを使用します。
  • 着信メッセージを調べ、その内容に応じてノードの 2 つの出力ターミナルのどちらかにそれを無変更で伝搬します。このノードの動作は Filter ノードと似ていますが、使用する出力ターミナルを決めるために ESQL ではなく Java™ を使用します。
  • 着信メッセージの一部を変更して、変更されたメッセージを出力ターミナルの 1 つに伝搬します。
  • 入力メッセージから完全に独立した新規の出力メッセージを作成および構築します。
Mapping
Mapping ノードを使用して、入力メッセージのエレメントまたはデータベース内容から、出力メッセージのエレメントの内容をマッピングすることによって、入力メッセージから新規メッセージを作成することができます。 メッセージの一部を抽出して、必要があればその内容を変更し、ノードが受け取ったメッセージの部分的なコピーとして新規出力メッセージを作成することができます。 Mapping ノードは、事前定義メッセージのみを処理します。

このノードがデータベースにアクセスする方法を、ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、制御することができます。 これらの値を初期化し、保守するには、mqsisetdbparms コマンドを使用します。

事前定義メッセージの簡単な操作を実行するためのマッピングを開発するには、マッピング・エディターを使用します。 他のいかなるタイプのノードにおいても、Mapping ノードで使用するために作成したマッピングは使用しないでください。

Extract
Extract ノードは、WebSphere Message Broker バージョン 6.0 では使用すべきではなくなりました。Extract ノードを含むメッセージ・フローは、WebSphere Message Broker バージョン 6.0 でも有効ですが、可能であればメッセージ・フローを再設計して Extract ノードを Mapping ノードで置き換えられるようにしてください。

Extract ノードを使用して、入力メッセージの指定されたエレメントから、新規出力メッセージを作成することができます。 メッセージの一部を抽出して、任意にその内容を変更し、ノードが受け取ったメッセージの部分的なコピーである、新規出力メッセージを作成することができます。 Extract ノードは、事前定義メッセージのみを処理します。

マッピング・エディターを使用して、Extract ノード内の事前定義メッセージのシンプルな操作を実行するためのマッピングを作成します。 他のいかなるタイプのノードにおいても、Extract ノードで使用するために作成したマッピングは使用しないでください。

Database
Database ノードを使用して、ノード・プロパティーが識別するデータベースと対話します。 Database ノードは、事前定義および自己定義の両方のメッセージを処理します。 おそらくメッセージの情報に基づいて、メッセージからのデータベース内容の更新、データベースへの新規情報の挿入、およびデータベースからの情報の削除を行うための ESQL 関数をコーディングするには、ESQL エディターを使用します。 他のいかなるタイプのノードにおいても、Database ノード内で使用するために作成した ESQL コードは使用しないでください。

このノードは、広範囲の機能を持つ非常に柔軟なインターフェースを提供します。 また、対話がトランザクションに参加する方法を制御するのに使用できるプロパティーもあります。

このノードがデータベースにアクセスする方法を、ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、制御することができます。 これらの値を初期化し、保守するには、mqsisetdbparms コマンドを使用します。

このノードからはデータベースのみ更新することができます。メッセージ内容を更新することはできません。メッセージ内容を更新するには、Compute または Mapping ノードを使用します。

DataDelete, DataInsert, DataUpdate
DataDeleteDataInsert、および DataUpdate ノードは、対話の単一モードを提供する Database ノードの特殊な形式です (1 つ以上の行の削除、1 つ以上の行の挿入、または 1 つ以上の既存の行の更新を行う)。

DataDeleteDataInsert、および DataUpdate ノードは、事前定義メッセージだけを処理します。 マッピング・エディターを使用して、これらの関数を実行するためのマッピングを作成してください。他のいかなるタイプのノードにおいても、これらのノードのために作成したマッピングは使用しないでください。 これらのノードは、実行する更新のトランザクション特性を制御するのに使用できます。

このノードがデータベースにアクセスする方法を、ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、制御することができます。 これらの値を初期化し、保守するには、mqsisetdbparms コマンドを使用します。

これらのノードからはデータベースのみ更新することができます。メッセージ内容を更新することはできません。メッセージ内容を更新するには、Compute または Mapping ノードを使用します。

Warehouse
Warehouse ノードは、例えば監査上の理由で、データベースのメッセージすべてまたは一部を保管するのに使用できる保管インターフェースを提供します。 Warehouse ノードは、事前定義メッセージのみを処理します。 マッピング・エディターを使用して、このアクションを実行するためのマッピングを作成してください。 他のいかなるタイプのノードにおいても、Warehouse ノードのために作成したマッピングは使用しないでください。

このノードがデータベースにアクセスする方法を、ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、制御することができます。 これらの値を初期化し、保守するには、mqsisetdbparms コマンドを使用します。

このノードからはデータベースのみ更新することができます。メッセージ内容を更新することはできません。メッセージ内容を更新するには、Compute または Mapping ノードを使用します。

XMLTransformation
XMLTransformation ノード を使用すると、入力 XML メッセージを、XSLT スタイル・シートを使って別の形式に変換することができます。 データの XML メッセージへの構文解析は必須です。 変換の結果は、BLOB メッセージとして送出されます。スタイル・シートは、その中で定義されている規則を使って、次のようなアクションを実行することができます。
  • データをソートする。
  • いくつかの基準に基づいて組み込むかまたは除外するデータ・エレメントを選択する。
  • データを別の形式に変換する。

基礎となる変換エンジンとして、Xalan-Java 変換エンジン (Apache Xalan-java XSLT プロセッサー (Apache Xalan-java XSLT processor)) が使用されます。XML 文書を他の XML 文書に変換するための XML 変換、構文の W3C 仕様、および XSL 変換言語の意味の詳細は、W3C XSL 変換 (W3C XSL Transformations)を参照してください。

スタイル・シートおよび XML ファイルをブローカーの実行グループにデプロイすることにより、スタイル・シートおよび XML ファイルの保守に役立てることができます。

JMSMQTransform
JMSMQTransform ノードを使用して、JMS メッセージ・ツリーを持つメッセージを、WebSphere MQ JMS プロバイダーによって生成されるメッセージの形式と互換性のあるツリー構造を持つメッセージに変換します。

JMSMQTransform ノードを使用して、既存のメッセージ・フローにメッセージを送信し、さらに WebSphere MQ JMS および WebSphere MQ パブリッシュ/サブスクライブと相互操作を行うことができます。

MQJMSTransform
MQJMSTransform ノードを使用して、WebSphere MQ JMS プロバイダーのメッセージ・ツリー形式のメッセージを受け取り、それらを JMS 宛先に送るメッセージと互換性のある形式に変換します。

MQJMSTransform ノードを使用して、既存のメッセージ・フローにメッセージを送信し、さらに WebSphere MQ JMS および WebSphere MQ パブリッシュ/サブスクライブとの相互運用を行うことができます。

MQOptimizedFlow

MQOptimizedFlow ノードを使用して、Publication ノードに接続した MQInput ノードで構成されていて、しかも WebSphere MQ トランスポートを通して JMS を使用する パブリッシュ/サブスクライブ・メッセージ・フローを置き換えます。 MQOptimizedFlow ノードは、z/OS® システム上では使用できません。

MQOptimizedFlow ノードを使用すると、特に単一のパブリッシャーが単一のサブスクライバーに持続パブリケーションを生成する場合に、パフォーマンスが向上します。

ユーザー定義
ユーザー定義ノードを使用すると、組み込みノードでは満たされない特定の要件を処理できます。

例えば、ノードがデータベースにアクセスする場合、ユーザー定義ノードを組み込んで、データベースと対話するようにします。このノードがデータベースにアクセスする方法を、ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、制御することができます。 これらの値を初期化し、保守するには、mqsisetdbparms コマンドを使用します。

次の表は、これらのノードで何が更新できるかを要約しています。
ノード データベースの更新 メッセージの更新 LocalEnvironment の更新 メッセージ・セットが必要か ?
Compute はい はい はい いいえ
Database はい いいえ はい いいえ
DataDelete はい いいえ はい はい
DataInsert はい いいえ はい はい
DataUpdate はい いいえ はい はい
Extract はい はい はい はい
Mapping はい はい はい はい
Warehouse はい いいえ はい はい
決定を下すためのノード

さまざまな方法で順序およびメッセージ・フロー内の制御のフローを決定するノードを使用して、メッセージがフローによって処理される方法についての決定を下すことができます。 メッセージ・フロー内のイベントの、時間と発生頻度を決定するノード (TimeoutControl および TimeoutNotification) を使用することもできます。 ルーティングはメッセージ変換には依存しません。ただし、メッセージがたどる経路によって、メッセージに対してどのような変換が実行されるかが正確に決定されることはあります。

例えば、ある振替アプリケーションが、常にもう 1 つのアプリケーションにメッセージを送信するとします。 振替額が 10,000 ドルを上回るメッセージについては、もう 1 つ別のアプリケーションにも送信して、高額の取引をすべて記録できるようにします。

別の例として、ある全国規模の自動車クラブでは、特定のメンバーに対し、しきい値を超える注文について特別サービスを提供します。 大部分の注文は通常のチャネルへルーティングされますが、メンバーシップ番号と注文額が特定の基準にかなう場合は特殊な処理が適用されます。

メッセージを処理する時点で追加のルーティング情報をメッセージに組み込むことにより、さらに動的なルーティング・オプションも設定できます。 オプションの規則セットをセットアップし、メッセージに設定された値 (宛先) に基づいてメッセージ受信が行えるようにします。 こうした規則を設定するにあたっては、追加したメッセージ内容で決めた順番に従って、1 つ以上のオプションの規則セットでメッセージを処理するようにできます。

以下のノードを使って、メッセージ・フローの中でメッセージがたどる経路を決定することができます。

Validate
Validate ノードは、入力ターミナルに到着するメッセージが予想したとおりであるかどうかを検査するために使用します。メッセージが、予想した メッセージ・テンプレート・プロパティー (メッセージ・ドメイン、メッセージ・セット、 およびメッセージ・タイプ) を持つかどうか、またメッセージの内容が正しいかどうかを検査できます。 メッセージは、1 つ以上のメッセージ・ドメイン、メッセージ・セット、またはメッセージ・タイプに照らして検査できます。

Validate ノードは、WebSphere Message Broker バージョン 6.0では使用すべきでない Check ノードに取って代わるものです。 Validate ノードは Check ノードと同様の処理をしますが、「妥当性検査」プロパティーが追加されており、当該機能をサポートするパーサーがメッセージの内容を検証できます。

Filter
Filter ノードを ESQL ステートメントと一緒に使用すると、このノードによるメッセージの送信先になる次のノードを決定することができます。 他のいかなるタイプのノードにおいても、Filter ノード内で使用するために作成した ESQL コードは使用しないでください。

ノードのターミナルとしては True、False、Unknown、および Failure があります。テストが成功すると、メッセージは True ターミナルに伝搬し、失敗すると、False ターミナルに伝搬します。ステートメントが解決できない場合 (例えば、入力メッセージにはないフィールドの値をテストする場合)、メッセージは Unknown ターミナルに伝搬します。他のエラーが検出された場合、メッセージは Failure ターミナルに伝搬されます。

ESQL ステートメントのテストの結果は、メッセージの内容、データベースの内容、またはこの両者の組み合わせによって異なることがあります。

データベースを参照する場合、このノードがデータベースにアクセスする方法を、ブローカー・システムのレジストリーで定義されるデータ・ソースごとに、ユーザーおよびパスワード情報を指定することによって、制御することができます。 これらの値を初期化し、保守するには、mqsisetdbparms コマンドを使用します。

メッセージ選択およびルーティングを提供するためには、このノードを Compute ノードより優先して使用してください。このタスクでは Filter ノードのほうが効率的です。

FlowOrder
このノードのターミナルを接続すると、ノードの 1 つのシーケンス、続いてノードの 2 番目のシーケンスがメッセージを処理するように強制できます。
Passthrough
Passthrough ノードは、実行時にサブフローをバージョン管理できるようにするために使用します。ラベルをサブフローに追加するには、このノードを使用します。 このラベルと、バージョン管理システムからの予約語置換とを併用すると、デプロイ済みのメッセージ・フローに組み込まれているサブフローのバージョンを識別できます。このラベルは自分独自の目的のために使用できます。ラベルに正しいバージョン・キーワードを組み込んでいる場合は、以下のようにラベルの値を参照できます。
  • ブローカー・アーカイブ (BAR) ファイルに保管されているものを、mqsireadbar コマンドを使用して
  • 特定のブローカーに最後にデプロイされたものを、Message Brokers Toolkit から、デプロイされたメッセージ・フローのプロパティーによって
  • 実行時に (メッセージ・フローのユーザー・トレースを使用可能にしている場合)
RouteToLabel および Label
複雑なルーティングでは、Compute ノードに続いて RouteToLabel ノードを使用してください。 Compute ノードに、RouteToLabel ノードによって使用される宛先のリストを定義します。 このノードは、宛先を尋ね、対応する Label ノードにメッセージを渡します。
ResetContentDescriptor
ResetContentDescriptor ノードを使用すると、メッセージ・ビット・ストリームがメッセージ・フローの後続のノードによって次に解析されるときに使用される、新しいメッセージ・プロパティーを設定できます。
時間に制約される操作を制御するためのノード
毎日特定の時刻にバッチ・アプリケーション・プロセスを実行したり、一定間隔で情報を処理してパブリッシュしたり (例えば通貨の為替レートを計算して銀行に送るなど)、または既定時間内で特定のトランザクションが完了しない場合に、指定のリカバリー・アクションを取りたいことがあります。 これらすべてのケースに対して、2 つのタイムアウト・ノード (TimeoutControl および TimeoutNotification) が提供されています。
TimeoutControl
メッセージ・フロー内で TimeoutControl ノードと TimeoutNotification ノードを共に使用して、特定の時刻または既定の時間間隔で生じるイベントを制御します。 TimeoutControl ノードは、タイムアウト要求を含む入力メッセージを受け取ります。 この入力メッセージのすべてまたは一部が妥当性検査されて保管され、メッセージ・フロー内の関連 TimeoutNotification ノードによって伝搬されます。入力メッセージも、未変更のままメッセージ・フロー内の次のノードまで伝搬されます。

複数の TimeoutControl ノードをそれぞれの TimeoutNotification ノードに関連付けることができます。

TimeoutNotification
独立した TimeoutNotification ノードを使用して、構成済みの時刻にまたは時間間隔で、さらに処理するためにメッセージ・フロー内の次のノードに伝搬されるメッセージを生成します。
要求の照合のためのノード

AggregateControlAggregateReply、および AggregateRequest ノードを使用すると、関連する要求および応答を照合することができます。これらのノードを使用して、1 つの入力メッセージに応答していくつかの要求を生成し、それらの要求に対する応答として受け取られる応答を制御および調整し、応答が提供する情報を結合して処理を続行します。

エラーを処理し、報告するためのノード

以下のノードを使用すると、エラーの処理および報告に影響します。

Trace
Trace ノードを組み込むと、この時点でメッセージ・フローに何が起きているかを記録する、1 つ以上のトレース・エントリーを生成できます。
TryCatch
TryCatch ノードを組み込むと、例外のスロー時にエラー処理を制御できます。
Throw
Throw ノードを組み込むと、例外のスローを強制でき、さらに例外の ID を指定して問題の診断をより容易にすることができます。
関連概念
メッセージ・フローの概要
エンド・ユーザー・アプリケーションのサポート
ローカル環境のツリー構造
関連タスク
ブローカーおよびユーザー・データベースの構成
z/OS での DB2 セキュリティーのセットアップ
メッセージ・フローの設計
メッセージ・フローからデータベースへのアクセス
メッセージ・フローの作成
メッセージ・フローの内容の定義
ノードを使用した意思決定
デプロイ
関連資料
mqsisetdbparms コマンド
組み込みノード
エンド・ユーザー・アプリケーションのサポート
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
最終更新 : 2009-02-20 12:42:34

ac00330_