WebSphere Business Integration Message Broker には、メッセージ・フロー内で使用できるメッセージ処理ノードが多数あります。 また、ユーザー定義ノードと呼ばれる独自のノードを定義するためのインターフェースも提供します。
どのノードを使用するかは、メッセージに対して実行する処理によって異なります。 組み込みノードは、いくつかのカテゴリーに分けることができ、 それらのカテゴリーに ワークベンチ グループ化されてに表示されます (ただし、このグループ化は操作には影響しません)。 また、同じ方法で、ユーザー定義ノードもカテゴリー化できます。 次のようなカテゴリーがあります。
入力ノードのインスタンスは in ターミナルを表します。 たとえば、入力ノードのインスタンスを 1 つ組み込んだ場合、サブフローのアイコンは、1 つの in ターミナルを表示します。 これを、他のノードに接続するのと同じ仕方で、メイン・フロー内の他のノードに接続することができます。
UDPSend ノードは、この機能を提供するユーザー定義ノードの実例です。
出力ノードのインスタンスは out ターミナルを表します。 たとえば、出力ノードのインスタンスを 2 つ組み込んだ場合、 サブフローのアイコンは、2 つの out ターミナルを表示します。 これを、他のノードに接続するのと同じ仕方で、メイン・フロー内の他のノードに接続することができます。
たいていどの企業でも、さまざまなシステム上で、 さまざまなプログラム言語とさまざまな通信方法を使って、 長年に渡って開発されてきた複数のアプリケーションがあるものです。WebSphere Business Integration Message Broker では、メッセージの形式を変換するようにメッセージ・フローを構成できるため、 アプリケーションがこうした相違を理解する必要はなくなります。
たとえば、個人名を保持する形式は、アプリケーションごとに異なります。 姓を最初と最後のどちらに置くか、ミドル・ネームのイニシャルの有無、 大文字小文字の別は、置換される可能性のある事柄のほんの一部に過ぎません。 各アプリケーションの要件を認識するようにメッセージ・フローを構成できるので、 送信または受信アプリケーションには変更を加えることなく、 各メッセージを正しい形式に変換できます。
メッセージの内容を処理し、いくつかの方法でそれを更新することができます。 ここでのユーザーの選択は、メッセージ・フローが処理するのが、事前定義 (モデル化) メッセージなのか、 自己定義メッセージ (たとえば XML) なのか、またはその両方なのかによって異なります。
メッセージ・フローでは、メッセージを完全に再作成すること、 メッセージの形式 (フィールドの順番、バイト・オーダー、言語、その他) を変換すること、 またはメッセージに特定のデータを挿入することができます。たとえば、あるノードでは、データベースと対話して追加情報を検索すること、 あるいはメッセージのコピー (全体または一部) をデータベースに保管して、 オフライン処理を可能にすることができます。
以下の例は、メッセージ変換がどれほど重要なものになりえるかを示しています。
以下のノードを使うと、 他のメッセージ・フローと相互作用するメッセージ・フローを作成することもできます。 デフォルトでは、 あるメッセージ・フローの動作が他のメッセージ・フローの動作に影響を与えることはありませんが、 データベースなどの外部ソースで情報の保管や検索を行うようメッセージ・フローを構成することにより、 強制的にこれを作り出すことができます。
ESQL エディターを使って ESQL モジュールを作成します。これはこのノードに特有のものであり、 メッセージまたはデータベースに対して実行するアクションを定義するステートメントが入ります。 他のいかなるタイプのノードにおいても、Compute ノード内で使用するために作成した ESQL コードは使用しないでください。
このノードがデータベースにアクセスする方法を、 ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、 制御することができます。 分散システムの場合、これらの値を初期化し、 保守するには、mqsisetdbparms コマンドを使用します。
z/OS の場合、データベースにアクセスするには、 ブローカーが開始するタスクの ID を使用します。
メッセージ操作の要件が複雑な場合、これらを単一の Compute ノード内で完了してください。 少ない数の、より複雑な Compute ノードのパフォーマンスの方が、大量の単純なノードよりも良好です。 これは、ブローカーはそれぞれの Compute ノードへのエントリーの時点で、メッセージを構文解析するからです。
このノードがデータベースにアクセスする方法を、 ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、 制御することができます。 分散システムの場合、これらの値を初期化し、 保守するには、mqsisetdbparms コマンドを使用します。
z/OS の場合、データベースにアクセスするには、 ブローカーが開始するタスクの ID を使用します。
マッピング・エディターを使用して、マッピングを作成できます。それは Mapping ノード内の事前定義メッセージの簡単な操作を実行するためのものです。 他のいかなるタイプのノードにおいても、Mapping ノードで使用するために作成したマッピングは使用しないでください。
マッピング・エディターを使用して、マッピングを作成できます。それは Extract ノード内の事前定義メッセージのシンプルな操作を実行するためのものです。 他のいかなるタイプのノードにおいても、Extract ノードで使用するために作成したマッピングは使用しないでください。
このノードは、広範囲の機能を持つ非常に柔軟なインターフェースを提供します。 また、対話がトランザクションに参加する方法を制御するのに使用できるプロパティーもあります。
このノードがデータベースにアクセスする方法を、 ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、 制御することができます。 分散システムの場合、これらの値を初期化し、 保守するには、mqsisetdbparms コマンドを使用します。
z/OS の場合、データベースにアクセスするには、 ブローカーが開始するタスクの ID を使用します。
このノードからはデータベースのみ更新することができます。 メッセージ内容を更新することはできません。 メッセージ内容を更新するには、Compute または Mapping ノードを使用します。
これらのノードがデータベースにアクセスする方法を、 ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、 制御することができます。 分散システムの場合、これらの値を初期化し、 保守するには、mqsisetdbparms コマンドを使用します。
z/OS の場合、データベースにアクセスするには、 ブローカーが開始するタスクの ID を使用します。
これらのノードからはデータベースのみ更新することができます。 メッセージ内容を更新することはできません。 メッセージ内容を更新するには、Compute または Mapping ノードを使用します。
このノードがデータベースにアクセスする方法を、 ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、 制御することができます。 分散システムの場合、これらの値を初期化し、 保守するには、mqsisetdbparms コマンドを使用します。
z/OS の場合、データベースにアクセスするには、 ブローカーが開始するタスクの ID を使用します。
このノードからはデータベースのみ更新することができます。 メッセージ内容を更新することはできません。 メッセージ内容を更新するには、Compute または Mapping ノードを使用します。
このノードがデータベースにアクセスする方法を、 ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、 制御することができます。 分散システムの場合、これらの値を初期化し、 保守するには、mqsisetdbparms コマンドを使用します。
z/OS の場合、データベースにアクセスするには、 ブローカーが開始するタスクの ID を使用します。
次の表は、これらのノードで何が更新できるかを要約しています。
ノード | データベースの更新 | メッセージの更新 | LocalEnvironment の更新 | メッセージ・セットが必要か ? |
---|---|---|---|---|
Compute | はい | はい | はい | いいえ |
Database | はい | いいえ | はい | いいえ |
DataDelete | はい | いいえ | はい | はい |
DataInsert | はい | いいえ | はい | はい |
DataUpdate | はい | いいえ | はい | はい |
Extract | はい | はい | はい | はい |
Mapping | はい | はい | はい | はい |
Warehouse | はい | いいえ | はい | はい |
さまざまな方法で処理の順序およびメッセージ・フロー内の制御のフローを決定するノードを使用して、 メッセージがフローによって処理される方法についての決定を下すことができます。 ルーティングがメッセージ変換に依存することはありませんが、 メッセージがたどる経路により、 メッセージに対して実行される変換が左右されることはあります。
たとえば、ある振替アプリケーションが、 常にもう 1 つのアプリケーションにメッセージを送信するとします。 振替額が 10,000 ドルを上回るメッセージについては、 もう 1 つ別のアプリケーションにも送信して、高額の取引をすべて記録できるようにします。
別の例として、ある全国規模の自動車クラブでは、 特定のメンバーに対し、しきい値を超える注文について特別サービスを提供します。 大部分の注文は通常のチャネルへルーティングされますが、 メンバーシップ番号と注文額が特定の基準にかなう場合は特殊な処理が適用されます。
メッセージを処理する時点で追加のルーティング情報をメッセージに組み込むことにより、 さらに動的なルーティング・オプションも設定できます。 オプションの規則セットをセットアップし、 メッセージに設定された値 (宛先) に基づいてメッセージ受信が行えるようにします。 こうした規則を設定するにあたっては、 追加したメッセージ内容で決めた順番に従って、 1 つ以上のオプションの規則セットでメッセージを処理するようにできます。
以下のノードを使って、 メッセージ・フローの中でメッセージがたどる経路を決定することができます。
ノードのターミナルとしては true、false、unknown、および failure があります。 テストが成功すると、メッセージは true ターミナルに伝搬し、失敗すると、false ターミナルに伝搬します。 ステートメントが解決できない場合 (たとえば、入力メッセージにはないフィールドの値をテストする場合)、 メッセージは unknown ターミナルに伝搬します。 他のエラーが検出された場合、メッセージは failure ターミナルに伝搬されます。
ESQL ステートメントのテストの結果は、 メッセージの内容、データベースの内容、または両者の組み合わせによって左右されることがあります。
データベースを参照する場合、このノードがデータベースにアクセスする方法を、 ブローカー・システムのレジストリーで定義される各データ・ソースごとに、 ユーザーおよびパスワード情報を指定することによって、制御することができます。 分散システムの場合、これらの値を初期化し、 保守するには、mqsisetdbparms コマンドを使用します。
z/OS の場合、データベースにアクセスするには、 ブローカーが開始するタスクの ID を使用します。
この機能を提供するためには、このノードを Compute ノードより優先して使用してください。 Compute ノードを構成してメッセージ選択およびルーティングを制御することはできますが、Filter ノードを使用したほうがパフォーマンスが良くなります。
AggregateControl、AggregateReply、 および AggregateRequest ノードを使用して、関連する要求および応答を照合することができます。 これらのノードを使用して、1 つの入力メッセージの応答していくつかの要求を生成し、 それらの要求に対する応答として受け取られる応答を制御および調整し、応答が提供する情報を結合して処理を続行します。
エラー処理およびレポートに影響するノードを使用できます。
Compute、Extract、および Mapping ノード以外の場合は、 ノードによって受信される入力メッセージと、ノードによって送信される出力メッセージは同一です。
関連概念
メッセージ・フロー
エンド・ユーザー・アプリケーションのサポート
LocalEnvironment ツリー
関連タスク
DB2 のセットアップ
メッセージ・フローの設計
メッセージ・フローからデータベースへのアクセス
メッセージ・フローの作成
メッセージ・フローの内容の定義
ノードを使用した意思決定
メッセージ・フロー・アプリケーションのデプロイ
注意 |
商標 |
ダウンロード |
ライブラリー |
技術サポート |
フィードバック
![]() ![]() |
ac00330_ |