使用するノードの決定

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

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

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

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

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

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

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

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

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

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

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

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

基礎となる変換エンジンとして、Xalan-Java 変換エンジン (http://xml.apache.org/xalan-j) が使用されます。 XMLT について詳しくは、http://www.w3.org/TR/xslt を参照してください。

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

意思決定

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

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

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

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

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

Check
メッセージ特性を検査してその構造を判別し、それが必要な特性に合うかどうかに従って、メッセージの経路を定めます。
Filter
ESQL ステートメントをコーディングして、このノードによるメッセージの送信先になる次のノードを決定することができます。 他のいかなるタイプのノードにおいても、Filter ノード内で使用するために作成した ESQL コードは使用しないでください。

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

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

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

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

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

FlowOrder
このノードのターミナルを接続して、ノードの 1 つのシーケンス、続いてノードの 2 番目のシーケンスがメッセージを処理するように強制できます。
Passthru
Passthrough ノードは、サブフローの中で、Input ノードに続く最初のノードとして使用してください。 これにより、このノードがどのサブフローの中に組み込まれているかを識別します。 例えば、いくつかのメッセージ・フローに組み込まれるエラー処理サブフローを開発している場合に、このサブフローを変更する必要が生じるかもしれません。 しかし、初めは、この変更済みバージョンを、組み込み先のメッセージ・フローのサブセットにだけ導入したいと思うかもしれません。 Passthrough ノードのインスタンスに、組み込んだサブフローのバージョンを識別する値を設定することができます。
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 Last updated: 5 01, 2006
ac00330_