メッセージ・フロー・ノード
メッセージ・フロー・ノードは、メッセージ・フローの処理ステップです。 組み込みノード (built-in node)、ユーザー定義ノード (user-defined node) またはサブフロー・ノード (subflow node) のいずれかにできます。
メッセージ・フロー・ノードは、メッセージを受信し、メッセージに対してアクションのセットを実行し、オプションでメッセージ・フロー内の次のノードに元のメッセージと 0 個以上の他のメッセージを渡します。
1 つのメッセージ・フロー・ノードには、特定の数の入力点および出力点があり、これらをターミナルといいます。 メッセージ・フロー内のメッセージの経路を定義するために、複数のターミナル間の接続を作成できます。 メッセージ・フロー・ノードは、メッセージ・フロー・エディターに関連付けられたノード・パレットに表示されます。 パレットはカテゴリー別に配置されます。カテゴリーは、関連する処理 (例えば変換) を提供するノードを一緒にグループ化したものです。
入力ノードには入力ターミナルがありません。 メッセージ・フローは、入力デバイス (例えば、 WebSphere® MQ キュー) からメッセージが取得されたときに開始されます。 0 個以上の出力メッセージが 1 つ以上の出力ノードから送信され、入力ノードに制御が返されると、メッセージ・フローは終了します。 入力ノードはトランザクションをコミットするか、ロールバックするかのどちらかです。 入力ノードと出力ノードは、Web サービスなどの特定のシステムと対話するために、プロトコル固有のものにできます。
大半のノードは処理ノードであり、入力ノードと出力ノードの間に組み込んで一緒に接続することにより、制御の流れを定義することができます。 それらのノードは通常、ある形式から別の形式へメッセージを変換するか、特定のパスに沿ってメッセージを経路指定するか、または集約やフィルターといったさらに複雑なオプションを提供します。
ノードを構成するには、ノード・プロパティーの値を設定または変更します。 一部のノードには、必須プロパティー、つまり必ず値を設定しなければならないプロパティーがあります。 さらに、値が必要ではあっても、デフォルト値が割り当てられているプロパティーもあります。その種のプロパティーは、変更しないでそのままにしておいてもかまいません。 その他のプロパティーは、オプション・プロパティー、つまり値が必須ではないプロパティーです。
メッセージ・フローを開発するときに、そのフロー内のノードのプロパティーをどのように設定するかによって、そのフローでメッセージがどのように処理されるかが影響を受けます。 例えば、入力および出力の WebSphere MQ キュー名を定義するプロパティーを設定することにより、メッセージ・フローがメッセージをどこから受信し、どこにメッセージを送信するかを決定します。
ノードを構成するときに、プロモートされたプロパティー を使用することもできます。つまり、1 つ以上のノード・プロパティーをプロモートして、ノードが含まれているメッセージ・フローのプロパティーにする、という技法です。 そのようなプロパティーは、フローのレベルで変更できるので、1 つ以上の個々のノードを更新する必要はありません。 さらに、複数のノードのそれぞれ等価のプロパティーを同じ「メッセージ・フロー」プロパティー にプロモートすることも可能です。例えば、この技法を使用すれば、メッセージ・フローに含まれているすべてのノードの接続先のデータベースの名前をフローのレベルで設定できます。
ノード・プロパティーには、構成可能プロパティー というサブセットがあります。つまり、メッセージ・フローを統合ノードにデプロイして実行するときに値を変更できるプロパティーです。 複数の統合ノードにメッセージ・フローをデプロイするときに、それぞれの統合ノードでの動作を少し変えるような場合に、この機能は便利です。 例えば、テスト統合ノードにメッセージ・フローをデプロイするときは、構成可能プロパティーを使用して、フローの通信先をテスト・データベースに強制設定できます。 一方、実動統合ノードに同じメッセージ・フローをデプロイするときは、その同じプロパティーを実動データベースの値に設定できます。メッセージ・フローそのものを更新する必要はありません。
ノード・プロパティーのもう 1 つのサブセットは、運用プロパティー です。 つまり、運用ポリシーを使用してプロパティーの値を制御できます。 運用ポリシーを使用すると、メッセージ・フローの動作に関する特定の側面や、特定のノード・プロパティー (接続資格情報など) を制御するための、共通の方法を定義できます。 運用ポリシーはソリューション・ライフサイクルのどの時点でも作成および更新できます。 運用ポリシーについて詳しくは、 運用ポリシーを参照してください。
統合ノードが動作している モード は、使用できるノードのタイプに影響を与える可能性があります。 各動作モードに適用される制約事項を参照してください。
メッセージ・フローには、以下の 3 種類のノードを追加できます。
ノードは、すべての出力ターミナルに対する出力メッセージを常に生成するとは限りません。 受信したメッセージに基づき、またはノードの操作結果に基づいて、ノードは通常、1 つのターミナルに対して 1 つの出力を生成します。 例えば、 フィルター ノードは通常、True ターミナルまたは False ターミナルのいずれかでメッセージを送信しますが、両方では送信しません。
複数のターミナルを別のノードに接続した場合、ノード内の処理により、接続先のノードにメッセージが伝搬される順序が決まります。この順序を変更することはできません。 ノードはそれぞれのターミナルに対して出力メッセージを送りますが、現在のターミナルの処理が完了して初めて、次のターミナルに対して送信します。
メッセージの更新内容は以前に実行したノードには伝搬されず、更新を行ったノードの後に続くノードにのみ伝搬されます。 メッセージが複数の出力ターミナルの間で伝搬される順番は統合ノードによって決定されるため、この順番は変更できません。 この規則の唯一の例外は、 フロー・オーダー ノードです。このノードでは、メッセージがそれぞれに伝搬される順序をターミナルが示します。
すべての組み込みノードには、それぞれの処理の一部としてエラー処理が組み込まれています。 ノード内でエラーが検出された場合、メッセージが failure ターミナルに伝搬されます。 それから何が起きるかは、メッセージ・フローの構造次第です。 統合ノードによって提供されている基本的なエラー処理だけを使用するか、またはさらに包括的な障害処理を提供するために、エラー処理のノードおよびフローを追加して、フローを機能拡張することができます。 これらのオプションについて詳しくは、 メッセージ・フロー内のエラーの処理を参照してください。
メッセージ・フローのすべてのパス (つまり、すべての出力ターミナルから接続されたすべてのノード) が完了し、トランザクションをコミットまたはロールバックした入力ノードに制御が戻されて初めて、メッセージ・フローは新規メッセージを受け入れて処理することができます。