WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

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

メッセージ・フロー・ノードは、メッセージ・フローの処理ステップです。 組み込みノード (built-in node)、ユーザー定義ノード (user-defined node) またはサブフロー・ノード (subflow node) のいずれかにできます。

メッセージ・フロー・ノードは、メッセージを受信し、メッセージに対してアクションのセットを実行し、オプションでメッセージ・フロー内の次のノードに元のメッセージと 0 個以上の他のメッセージを渡します。

1 つのメッセージ・フロー・ノードには、特定の数の入力点および出力点があり、これらをターミナルといいます。 メッセージ・フロー内のメッセージの経路を定義するために、複数のターミナル間の接続を作成できます。 メッセージ・フロー・ノードは、メッセージ・フロー・エディターに関連付けられたノード・パレットに表示されます。 パレットはカテゴリー別に配置されます。カテゴリーは、関連する処理 (例えば変換) を提供するノードを一緒にグループ化したものです。

入力ノードには入力ターミナルがありません。 メッセージが入力装置から取得されると (例えば WebSphere® MQ キュー)、メッセージ・フローが開始します。 0 個以上の出力メッセージが 1 つ以上の出力ノードから送信され、入力ノードに制御が返されると、メッセージ・フローは終了します。 入力ノードはトランザクションをコミットするか、ロールバックするかのどちらかです。 入力ノードと出力ノードは、Web サービスなどの特定のシステムと対話するために、プロトコル固有のものにできます。

大半のノードは処理ノードであり、入力ノードと出力ノードの間に組み込んで一緒に接続することにより、制御の流れを定義することができます。 それらのノードは通常、ある形式から別の形式へメッセージを変換するか、特定のパスに沿ってメッセージを経路指定するか、または集約やフィルターといったさらに複雑なオプションを提供します。

ノードを構成するには、ノード・プロパティーの値を設定または変更します。 一部のノードには、必須プロパティー、つまり必ず値を設定しなければならないプロパティーがあります。 さらに、値が必要ではあっても、デフォルト値が割り当てられているプロパティーもあります。その種のプロパティーは、変更しないでそのままにしておいてもかまいません。 その他のプロパティーは、オプション・プロパティー、つまり値が必須ではないプロパティーです。

メッセージ・フローを開発するときに、そのフローに含まれている各ノードのプロパティーをどのように設定するかによって、そのフローでメッセージがどのように処理されるかが影響を受けます。 例えば、WebSphere MQ の入力キュー名と出力キュー名を定義するプロパティーを設定すれば、メッセージ・フローがどこからメッセージを受信し、どこにメッセージを送信するかが決まります。

ノードを構成するときに、プロモートされたプロパティー を使用することもできます。つまり、1 つ以上のノード・プロパティーをプロモートして、ノードが含まれているメッセージ・フローのプロパティーにする、という技法です。 そのようなプロパティーは、フローのレベルで変更できるので、1 つ以上の個々のノードを更新する必要はありません。 さらに、複数のノードのそれぞれ等価のプロパティーを同じ「メッセージ・フロー」プロパティー にプロモートすることも可能です。例えば、この技法を使用すれば、メッセージ・フローに含まれているすべてのノードの接続先のデータベースの名前をフローのレベルで設定できます。

ノード・プロパティーには、構成可能プロパティー というサブセットがあります。つまり、メッセージ・フローをブローカーにデプロイして実行するときに値を変更できるプロパティーです。 複数のブローカーにメッセージ・フローをデプロイするときに、それぞれのブローカーでの動作を少し変えるような場合に、この機能は便利です。 例えば、テスト・ブローカーにメッセージ・フローをデプロイするときは、構成可能プロパティーを使用して、フローの通信先をテスト・データベースに強制設定できます。 一方、実動ブローカーに同じメッセージ・フローをデプロイするときは、その同じプロパティーを実動データベースの値に設定できます。メッセージ・フローそのものを更新する必要はありません。

ブローカーが稼働しているモードは、使用可能なノードのタイプに影響を与えることがあります。各動作モードに適用される制約事項を参照してください。

メッセージ・フローには、以下の 3 種類のノードを追加できます。

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

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

WebSphere Message Broker をアプリケーションに接続するために使用できるノードについては、『接続のためのノード』を参照してください。

ユーザー定義ノード
ユーザー定義ノードは、製品で提供されているノードのほかに新しいメッセージ・フロー・ノードを提供する、ブローカーの拡張機能です。 ユーザー定義ノードは C 言語と Java™ 言語の両方で、WebSphere Message Broker によって提供されるユーザー定義ノード API に書き込む必要があります。 以下のサンプルは、独自のノードを C と Java の両方の言語で作成する方法を示しています。

サンプルに関する情報は、WebSphere Message Broker Toolkit に統合されているインフォメーション・センター、またはオンライン・インフォメーション・センターを使用する場合にのみ表示できます。 サンプルは、WebSphere Message Broker Toolkit に統合されているインフォメーション・センターを使用する場合にのみ実行できます。

サブフロー
サブフローはメッセージ・フロー・ノードおよびコネクターから構成される方向付きグラフで、 メッセージ・フローまたは他のサブフローに組み込むように設計されています。 サブフローをメイン・フロー内にある他のノードに接続するには、Input ノードと Output ノードをサブフローに追加できます。 サブフローは、.subflow ファイルまたは .msgflow ファイルの 2 つのリソース・タイプのいずれかで定義できます。 .subflow ファイルで定義されているサブフローは、別個のリソースとしてデプロイできます。 .msgflow ファイルで定義されているサブフローは、それ自体が組み込まれているメイン・フローと一緒にデプロイしなければなりません。

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

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

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

詳しくは、サブフローを参照してください。

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

複数のターミナルを別のノードに接続した場合、ノード内の処理により、接続先のノードにメッセージが伝搬される順序が決まります。この順序を変更することはできません。 ノードはそれぞれのターミナルに対して出力メッセージを送りますが、現在のターミナルの処理が完了して初めて、次のターミナルに対して送信します。

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

すべての組み込みノードには、それぞれの処理の一部としてエラー処理が組み込まれています。 ノード内でエラーが検出された場合、メッセージが failure ターミナルに伝搬されます。 それから何が起きるかは、メッセージ・フローの構造次第です。 ブローカーによって提供されている基本的なエラー処理だけを使用するか、またはさらに包括的な障害処理を提供するために、エラー処理のノードおよびフローを追加して、フローを機能拡張することができます。 これらのオプションについて詳しくは、メッセージ・フローのエラー処理を参照してください。

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

以下のサンプルは、XML_Reservation サンプルの環境変数を使用して、データベース表から取得された情報を保管し、その情報をメッセージ・フロー内のノード・ダウンストリームに渡します。

サンプルに関する情報は、WebSphere Message Broker Toolkit に統合されているインフォメーション・センター、またはオンライン・インフォメーション・センターを使用する場合にのみ表示できます。 サンプルは、WebSphere Message Broker Toolkit に統合されているインフォメーション・センターを使用する場合にのみ実行できます。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:45:32


概念トピック概念トピック | バージョン 8.0.0.5 | ac12640_