メッセージ・フロー・ノード

メッセージ・フロー・ノードは、メッセージ・フローの処理ステップです。

メッセージ・フロー・ノードは、メッセージを受信し、メッセージに対してアクションのセットを実行し、オプションでメッセージ・フロー内の次のノードにメッセージを渡します。 メッセージ・フロー・ノードは、組み込みノード、ユーザー定義ノード、またはサブフロー・ノードのいずれかにできます。

1 つのメッセージ・フロー・ノードには、特定の数の入力点および出力点があり、これらをターミナルといいます。 メッセージ・フロー内のメッセージの経路を定義するために、複数のターミナル間の接続を作成できます。

組み込みノード
組み込みノードは、WebSphere® Message Broker に備わっているメッセージ・フロー・ノードです。 組み込みノードは、入力機能と出力機能、操作と変換、意思決定、要求の照合、およびエラー処理とレポート機能を提供します。

WebSphere Message Broker が提供するすべての組み込みノードについては、組み込みノードを参照してください。

ユーザー定義ノード
ユーザー定義ノードは、製品に付属しているものに追加される、新規のメッセージ・フロー・ノードを提供するブローカーの拡張機能です。 これは C 言語と Java™ 言語の両方で、 WebSphere Message Broker によって提供されるユーザー定義ノード API に書き込む必要があります。 以下のサンプルは、独自のノードを C と Java の両方の言語で作成する方法を示しています。 サンプルは、Message Brokers Toolkit と統合されているインフォメーション・センターを使用する場合にのみ表示できます。
サブフロー
サブフローはメッセージ・フロー・ノードおよびコネクターから構成される方向付きグラフで、 メッセージ・フローまたは他のサブフローに組み込むように設計されています。 サブフローには、少なくとも 1 つの Input ノードまたは Output ノードが含まれている必要があります。 ブローカーがサブフローを実行できるのは組み込み先のメッセージ・フローの一部としてだけなので、個別にデプロイすることはできません。

メッセージは Input ノードが受け取り、サブフローの定義に応じて処理します。 それには、Warehouse ノードを介して保管されることや、 (たとえば MQOutput ノードを介して) 他のメッセージ・ターゲットに配送されることが含まれる場合があります。 必要であれば、メッセージを Output ノードを介してメイン・フローに戻し、処理を続けることもできます。

サブフローはメイン・フローに組み込まれているとき、固有のアイコンを持つ単一のサブフロー・ノードによって表されます。 アイコンと共に、サブフロー定義に含めた Input ノードと Output ノードを表す ターミナルの正確な数が表示されます。

サブフローの最も一般的な使用方法としては、メッセージ・フロー内の多くの場所で必要となる処理を提供するか、または複数のメッセージ・フロー間で共有されるようにします。 例えば、サブフロー内にエラー処理をコーディングすることも、監査証跡を提供する (メッセージ全体を保管して、トレース・エントリーを記述する) サブフローを作成することもできます。

サブフローの使用例が、以下の例に示されています。 Error Handler サンプルでは、サブフローを使用してエラーについての情報をトラップし、情報をデータベースに保管します。Coordinated Request Reply サンプルでは、処理ロジックを他のメッセージ・フローで再利用できるようにし、代替インプリメンテーションを置換できるようにするために、サブフローを使用して ReplyToQ および ReplyToQMgr 値の保管を WebSphere MQ メッセージ内でカプセル化します。 サンプルは、Message Brokers Toolkit と統合されているインフォメーション・センターを使用する場合にのみ表示できます。

ノードは、すべての出力ターミナルに対する出力メッセージを常に生成するとは限りません。 受信したメッセージに基づき、またはノードの操作結果に基づいて、ノードは通常、1 つのターミナルに対して 1 つの出力を生成します。 たとえば、Filter ノードは通常、 真のターミナルまたは偽のターミナルのいずれかに対して 1 つのメッセージを送信しますが、この両方には送りません。

複数のターミナルが接続されている場合、ノードはそれぞれのターミナルに対して出力メッセージを送りますが、現在のターミナルの処理が完了して初めて、次のターミナルに対して送信します。 メッセージの更新内容は以前に実行したノードには伝搬されず、更新を行ったノードの後に続くノードにのみ伝搬されます。メッセージが複数の出力ターミナルの間で伝搬される順番はブローカーによって決定されるため、この順番は変更できません。 この規則の唯一の例外は、FlowOrder ノードの場合です。 このノードでは、メッセージが各ターミナルに伝搬される順番をターミナルが指示します。

メッセージ・フローのすべてのパス (つまり、すべての出力ターミナルから接続されたすべてのノード) が完了して初めて、メッセージ・フローは新規メッセージを受け入れて処理することができます。

以下のサンプルは、XML_Reservation サンプルの環境変数を使用して、データベース表から取得された情報を保管し、その情報をメッセージ・フロー内のノード・ダウンストリームに渡します。 サンプルは、Message Brokers Toolkit と統合されているインフォメーション・センターを使用する場合にのみ表示できます。
関連概念
メッセージ・フロー・プロジェクト
メッセージ・フローの接続
メッセージのモデル化
関連タスク
メッセージ・フローの作成
関連資料
メッセージ・フロー・プロジェクトおよびファイル
組み込みノード
関連情報
Java ユーザー定義拡張 API
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

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

ac12640_