使用するノードの決定

始める前に:

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

WebSphere Message Broker には、メッセージ・フロー内で使用できるメッセージ処理ノードが多数あります。 また、ユーザー定義ノードと呼ばれる独自のノードを定義するためのインターフェースも提供します。

どのノードを使用するかは、メッセージに対して実行する処理によって異なります。 組み込みノードは、いくつかのカテゴリーに分けることができ、それらのカテゴリーに ワークベンチ グループ化されて表示されます (ただし、このグループ化は操作には影響しません)。 また、同じ方法で、ユーザー定義ノードもカテゴリー化できます。 次のようなカテゴリーがあります。

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

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

    MQGet
    メッセージが WebSphere MQ キューのブローカーに到達し、ノードがメッセージ・フローの先頭にならない場合。
    SCADAInput
    メッセージが telemetry 装置によって送信される場合。
    HTTPInput
    メッセージが Web サービス・クライアントによって送信される場合。
    Real-timeInput または Real-timeOptimizedFlow
    変更の始まりメッセージが JMS またはマルチキャスト・アプリケーションによって送信される場合。Real-timeInput ノードは入力ノードであり、Real-timeOptimizedFlow ノードは高性能のパブリッシュ/サブスクライブ・メッセージ・フローを提供する完全なメッセージ・フローです。変更の終わり
    変更の始まりJMSInput変更の終わり
    変更の始まりメッセージが JMS アプリケーションによって送信される場合。変更の終わり
    ユーザー定義入力ノード
    メッセージ送信元が、異なるプロトコルまたはトランスポートを使用するクライアントまたはアプリケーションである場合。
    Input ノード
    スタンドアロン・メッセージ・フローとしてデプロイしない、別のメッセージ・フローに埋め込みたいメッセージ・フロー (サブフロー) を作成している場合、メッセージを受け取る少なくとも 1 つの入力ノードを、そのサブフローに組み込む必要があります。

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

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

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

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

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

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

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

メッセージ操作、拡張、および変換

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

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

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

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

以下の例は、メッセージ変換がどれほど重要なものになりえるかを示しています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DataDelete、DataInsert、DataUpdate
DataDelete、DataInsert、および DataUpdate ノードは、対話の単一モードを提供する Database ノードの特殊な形式です (それぞれ 1 つ以上の行の削除、1 つ以上の行の挿入、または 1 つ以上の既存の行の更新を行う)。 DataDelete、DataInsert、および DataUpdate ノードは、事前定義メッセージだけを処理します。 マッピング・エディターを使用して、これらの関数を実行するためのマッピングを作成してください。他のいかなるタイプのノードにおいても、これらのノードのために作成したマッピングは使用しないでください。 これらのノードも、実行する更新のトランザクション特性を制御するのに使用できます。

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

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

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

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

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

XMLTransformation

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

基礎となる変換エンジンとして、Xalan-Java 変換エンジン (Apache Xalan-java XSLT プロセッサー (Apache Xalan-java XSLT processor)) が使用されます。XMLT についての詳細は、W3C XSL 変換 (W3C XSL Transformations)を参照してください。

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

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

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

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

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

変更の終わり
変更の始まりMQOptimizedFlow変更の終わり
変更の始まり

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

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

変更の終わり
ユーザー定義
ユーザー定義ノードを組み込んで、データベースと対話することもできます。

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

次の表は、これらのノードで何が更新できるかを要約しています。

ノード データベースの更新 メッセージの更新 LocalEnvironment の更新 メッセージ・セットが必要か ?
Compute はい はい はい いいえ
Database はい いいえ はい いいえ
DataDelete はい いいえ はい はい
DataInsert はい いいえ はい はい
DataUpdate はい いいえ はい はい
Extract はい はい はい はい
Mapping はい はい はい はい
Warehouse はい いいえ はい はい
意思決定

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

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

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

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

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

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

Validate ノードは、WebSphere Message Broker バージョン 6.0 および以降のリリースで推奨されない Check ノードを置換するものです。Validate ノードは Check ノードと 同様の処理をしますが、Validation プロパティーが追加されており、当該機能をサポートするパーサーがメッセージの内容を 検証できます。

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

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

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

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

z/OS の場合、データベースにアクセスするには、ブローカーが開始するタスクの ID を使用します。

この機能を提供するためには、このノードを Compute ノードより優先して使用してください。 Compute ノードを構成してメッセージ選択およびルーティングを制御することはできますが、Filter ノードを使用したほうがパフォーマンスが良くなります。

FlowOrder
このノードのターミナルを接続して、ノードの 1 つのシーケンス、続いてノードの 2 番目のシーケンスがメッセージを処理するように強制できます。
変更の始まりPassthrough変更の終わり
変更の始まりPassthrough ノードは、実行時にサブフローをバージョン管理できるようにするために使用します。Passthrough ノードを使用すると、メッセージ・フローまたはサブフローにラベルを追加できます。このラベルと、バージョン管理システムからのキーワード置換とを併用すると、デプロイ済みのメッセージ・フローに組み込まれているサブフローのバージョンを識別できます。このラベルは自分独自の目的のために使用できます。ラベルに正しいバージョン・キーワードを組み込んでいる場合は、以下のようにラベルの値を参照できます。
  • ブローカー・アーカイブ (BAR) ファイルに保管されているものを、mqsireadbar コマンドを使用して
  • 特定のブローカーに最後にデプロイされたものを、Message Brokers Toolkit から、デプロイされたメッセージ・フローのプロパティーによって
  • 実行時に (メッセージ・フローのユーザー・トレースを使用可能にしている場合)
変更の終わり
RouteToLabel および Label
Compute ノードに、RouteToLabel ノードによって使用される宛先のリストを定義することができます。 RouteToLabel ノードは、宛先を尋ね、対応する Label ノードにメッセージを渡します。
ResetContentDescriptor
メッセージ・ビット・ストリームがメッセージ・フローの後続のノードによって次に解析されるときに使用される、新しいメッセージ・プロパティーを設定します。

毎日特定の時刻にバッチ・ジョブを実行したり、一定間隔で情報を処理してパブリッシュしたり (例えば通貨の為替レートを計算して銀行に送るなど)、または既定時間内で特定のトランザクションが完了しない場合に、指定のリカバリー・アクションを取りたいことがあります。 これらすべてのケースに対して、2 つのタイムアウト・ノード (TimeoutControl および TimeoutNotification) が提供されています。

TimeoutControl
メッセージ・フロー内で TimeoutControl ノードと TimeoutNotification ノードを共に使用して、特定の時刻または既定の時間間隔で生じるイベントを制御します。 TimeoutControl ノードは、タイムアウト要求を含む入力メッセージを受け取ります。 この入力メッセージは、(メッセージのすべてまたは一部が) 妥当性検査されて保管され、メッセージ・フロー内の関連 TimeoutNotification ノードによって伝搬されます。 入力メッセージも、未変更のままメッセージ・フロー内の次のノードまで伝搬されます。

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

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

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

エラー処理およびレポート

エラー処理およびレポートに影響するノードを使用できます。

Trace
Trace ノードを組み込むと、この時点でメッセージ・フローに何が起きているかを記録する、1 つ以上のトレース・エントリーを生成できます。
TryCatch
TryCatch を組み込むと、例外のスロー時にエラー処理を制御できます。
Throw
Throw ノードを組み込むと、例外のスローを強制でき、さらに例外の ID を指定して問題の診断をより容易にすることができます。

Compute、Extract、および Mapping ノード以外の場合は、ノードによって受信される入力メッセージと、ノードによって送信される出力メッセージは同一です。

関連概念
メッセージ・フローの概要
エンド・ユーザー・アプリケーションのサポート
LocalEnvironment ツリー構造
関連タスク
DB2 のセットアップ
メッセージ・フローの設計
メッセージ・フローからデータベースへのアクセス
メッセージ・フローの作成
メッセージ・フローの内容の定義
ノードを使用した意思決定
デプロイ
関連資料
mqsisetdbparms コマンド
組み込みノード
エンド・ユーザー・アプリケーションのサポート
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック
Copyright IBM Corporation 1999, 2006 最終更新: 08/21/2006
ac00330_