WebSphere® Message Broker には、メッセージ・フロー内で使用できるメッセージ処理ノードが多数あります。
メッセージ・フロー・ノードに関する概念トピックに目を通しておきます。
WebSphere Message Broker はまた、ユーザー定義ノードと呼ばれる独自のノードを定義するのに使用できるインターフェースも提供します。
どのノードを使用するかは、メッセージに対して実行する処理によって異なります。
MQeInput ノードを含むメッセージ・フローを WebSphere Message Broker バージョン 6.0 で使用することは推奨されていません。 メッセージ・フローを再設計して、MQe ノードを除去し、独自の仕様に構成され MQe ゲートウェイ構成で調整された MQ ノードに置き換えてください。 詳細については、WebSphere MQ Everyplace ノードを含むメッセージ・フローのマイグレーションを参照してください。
Real-timeInput ノードは入力ノードであり、Real-timeOptimizedFlow ノードは高性能のパブリッシュ/サブスクライブ・メッセージ・フローを提供する完全なメッセージ・フローです。
Input ノードのインスタンスは In ターミナルを表します。例えば、Input ノードのインスタンスを 1 つ組み込んだ場合、サブフローのアイコンは、別のノードに接続するのと同じ方法でメイン・フローの他のノードに接続できる 1 つの In ターミナルを表示します。
メッセージ・フローをデプロイするには、少なくとも 1 つの入力ノードが必要です。メッセージ・フローに入力ノードが含まれていない場合には、それをブローカー・アーカイブ・ファイルに追加することはできません。 入力ノードはメイン・フロー、またはメイン・フローに組み込まれたメッセージ・フローに置くことができます。
メッセージ・フローでは、複数の入力ノードを使用できます。 詳しくは、複数の入力ノードの使用を参照してください。
MQeOutput ノードを含むメッセージ・フローを WebSphere Message Broker バージョン 6.0 で使用することは推奨されていません。 メッセージ・フローを再設計して、MQe ノードを除去し、独自の仕様に構成され MQe ゲートウェイ構成で調整された MQ ノードに置き換えてください。 詳細については、WebSphere MQ Everyplace ノードを含むメッセージ・フローのマイグレーションを参照してください。
Output ノードのインスタンスは Out ターミナルを表します。例えば、Output ノードのインスタンスを 2 つ組み込んだ場合、サブフローのアイコンは、2 つの Out ターミナルを表示します。これを、他のノードに接続するのと同じ仕方で、メイン・フロー内の他のノードに接続することができます。
たいていどの企業でも、さまざまなシステム上で、さまざまなプログラム言語とさまざまな通信方法を使って、長年に渡って開発されてきた複数のアプリケーションがあるものです。 WebSphere Message Broker では、メッセージの形式を変換するようにメッセージ・フローを構成する機能を提供することにより、アプリケーションがこうした相違を理解しなくても良いようになっています。
例えば、個人名を保持する形式は多数あり、アプリケーションごとに異なります。 姓を最初と最後のどちらに置くか、ミドルネームのイニシャルの有無、大/小文字の別は、置換される可能性のある事柄のほんの一部に過ぎません。各アプリケーションの要件を認識するようにメッセージ・フローを構成できるので、送信または受信アプリケーションには変更を加えることなく、各メッセージを正しい形式に変換できます。
メッセージの内容を処理し、いくつかの方法でそれを更新することができます。 ここでのユーザーの選択は、メッセージ・フローが処理するのが、事前定義 (モデル化) メッセージなのか、自己定義メッセージ (例えば XML) なのか、またはその両方なのかによって異なります。
メッセージ・フローでは、メッセージを完全に再作成すること、メッセージの形式 (フィールドの順番、バイト・オーダー、言語、その他) を変換すること、メッセージから内容を除去すること、またはメッセージに特定のデータを挿入することができます。例えば、あるノードでは、データベースと対話して追加情報を検索すること、あるいはメッセージのコピー (全体または一部) をデータベースに保管して、オフライン処理を可能にすることができます。
また、以下のノードを使って相互に対話するメッセージ・フローを作成することもできます。 あるメッセージ・フローのデフォルト操作が他のメッセージ・フローの操作に影響を与えることはありませんが、データベースなどの外部ソースで情報の保管や検索を行うようにメッセージ・フローを構成すれば、このアクションを強制的に起こすことができます。
ESQL エディターを使って ESQL モジュールを作成します。これはこのノードに特有のものであり、メッセージまたはデータベースに対して実行するアクションを定義するステートメントが入ります。 他のいかなるタイプのノードにおいても、Compute ノード内で使用するために作成した ESQL コードは使用しないでください。
このノードがデータベースにアクセスする方法を、ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、制御することができます。 これらの値を初期化し、保守するには、mqsisetdbparms コマンドを使用します。
メッセージ操作の要件が複雑な場合、これらを単一の Compute ノード内で実行してください。少ない数の、より複雑な Compute ノードのパフォーマンスの方が、大量の単純なノードよりも良好です。 これは、ブローカーはそれぞれの Compute ノードへのエントリーの時点で、メッセージを構文解析するからです。
このノードがデータベースにアクセスする方法を、ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、制御することができます。 これらの値を初期化し、保守するには、mqsisetdbparms コマンドを使用します。
事前定義メッセージの簡単な操作を実行するためのマッピングを開発するには、マッピング・エディターを使用します。 他のいかなるタイプのノードにおいても、Mapping ノードで使用するために作成したマッピングは使用しないでください。
Extract ノードを使用して、入力メッセージの指定されたエレメントから、新規出力メッセージを作成することができます。 メッセージの一部を抽出して、任意にその内容を変更し、ノードが受け取ったメッセージの部分的なコピーである、新規出力メッセージを作成することができます。 Extract ノードは、事前定義メッセージのみを処理します。
マッピング・エディターを使用して、Extract ノード内の事前定義メッセージのシンプルな操作を実行するためのマッピングを作成します。 他のいかなるタイプのノードにおいても、Extract ノードで使用するために作成したマッピングは使用しないでください。
このノードは、広範囲の機能を持つ非常に柔軟なインターフェースを提供します。 また、対話がトランザクションに参加する方法を制御するのに使用できるプロパティーもあります。
このノードがデータベースにアクセスする方法を、ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、制御することができます。 これらの値を初期化し、保守するには、mqsisetdbparms コマンドを使用します。
このノードからはデータベースのみ更新することができます。メッセージ内容を更新することはできません。メッセージ内容を更新するには、Compute または Mapping ノードを使用します。
DataDelete、DataInsert、および DataUpdate ノードは、事前定義メッセージだけを処理します。 マッピング・エディターを使用して、これらの関数を実行するためのマッピングを作成してください。他のいかなるタイプのノードにおいても、これらのノードのために作成したマッピングは使用しないでください。 これらのノードは、実行する更新のトランザクション特性を制御するのに使用できます。
このノードがデータベースにアクセスする方法を、ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、制御することができます。 これらの値を初期化し、保守するには、mqsisetdbparms コマンドを使用します。
これらのノードからはデータベースのみ更新することができます。メッセージ内容を更新することはできません。メッセージ内容を更新するには、Compute または Mapping ノードを使用します。
このノードがデータベースにアクセスする方法を、ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、制御することができます。 これらの値を初期化し、保守するには、mqsisetdbparms コマンドを使用します。
このノードからはデータベースのみ更新することができます。メッセージ内容を更新することはできません。メッセージ内容を更新するには、Compute または Mapping ノードを使用します。
基礎となる変換エンジンとして、Xalan-Java 変換エンジン (Apache Xalan-java XSLT プロセッサー (Apache Xalan-java XSLT processor)) が使用されます。XML 文書を他の XML 文書に変換するための XML 変換、構文の W3C 仕様、および XSL 変換言語の意味の詳細は、W3C XSL 変換 (W3C XSL Transformations)を参照してください。
スタイル・シートおよび XML ファイルをブローカーの実行グループにデプロイすることにより、スタイル・シートおよび XML ファイルの保守に役立てることができます。
JMSMQTransform ノードを使用して、既存のメッセージ・フローにメッセージを送信し、さらに WebSphere MQ JMS および WebSphere MQ パブリッシュ/サブスクライブと相互操作を行うことができます。
MQJMSTransform ノードを使用して、既存のメッセージ・フローにメッセージを送信し、さらに WebSphere MQ JMS および WebSphere MQ パブリッシュ/サブスクライブとの相互運用を行うことができます。
MQOptimizedFlow ノードを使用して、Publication ノードに接続した MQInput ノードで構成されていて、しかも WebSphere MQ トランスポートを通して JMS を使用する パブリッシュ/サブスクライブ・メッセージ・フローを置き換えます。 MQOptimizedFlow ノードは、z/OS® システム上では使用できません。
MQOptimizedFlow ノードを使用すると、特に単一のパブリッシャーが単一のサブスクライバーに持続パブリケーションを生成する場合に、パフォーマンスが向上します。
例えば、ノードがデータベースにアクセスする場合、ユーザー定義ノードを組み込んで、データベースと対話するようにします。このノードがデータベースにアクセスする方法を、ノード・プロパティーに指定する各データ・ソースのユーザーおよびパスワード情報を指定することによって、制御することができます。 これらの値を初期化し、保守するには、mqsisetdbparms コマンドを使用します。
ノード | データベースの更新 | メッセージの更新 | LocalEnvironment の更新 | メッセージ・セットが必要か ? |
---|---|---|---|---|
Compute | はい | はい | はい | いいえ |
Database | はい | いいえ | はい | いいえ |
DataDelete | はい | いいえ | はい | はい |
DataInsert | はい | いいえ | はい | はい |
DataUpdate | はい | いいえ | はい | はい |
Extract | はい | はい | はい | はい |
Mapping | はい | はい | はい | はい |
Warehouse | はい | いいえ | はい | はい |
さまざまな方法で順序およびメッセージ・フロー内の制御のフローを決定するノードを使用して、メッセージがフローによって処理される方法についての決定を下すことができます。 メッセージ・フロー内のイベントの、時間と発生頻度を決定するノード (TimeoutControl および TimeoutNotification) を使用することもできます。 ルーティングはメッセージ変換には依存しません。ただし、メッセージがたどる経路によって、メッセージに対してどのような変換が実行されるかが正確に決定されることはあります。
例えば、ある振替アプリケーションが、常にもう 1 つのアプリケーションにメッセージを送信するとします。 振替額が 10,000 ドルを上回るメッセージについては、もう 1 つ別のアプリケーションにも送信して、高額の取引をすべて記録できるようにします。
別の例として、ある全国規模の自動車クラブでは、特定のメンバーに対し、しきい値を超える注文について特別サービスを提供します。 大部分の注文は通常のチャネルへルーティングされますが、メンバーシップ番号と注文額が特定の基準にかなう場合は特殊な処理が適用されます。
メッセージを処理する時点で追加のルーティング情報をメッセージに組み込むことにより、さらに動的なルーティング・オプションも設定できます。 オプションの規則セットをセットアップし、メッセージに設定された値 (宛先) に基づいてメッセージ受信が行えるようにします。 こうした規則を設定するにあたっては、追加したメッセージ内容で決めた順番に従って、1 つ以上のオプションの規則セットでメッセージを処理するようにできます。
以下のノードを使って、メッセージ・フローの中でメッセージがたどる経路を決定することができます。
Validate ノードは、WebSphere Message Broker バージョン 6.0では使用すべきでない Check ノードに取って代わるものです。 Validate ノードは Check ノードと同様の処理をしますが、「妥当性検査」プロパティーが追加されており、当該機能をサポートするパーサーがメッセージの内容を検証できます。
ノードのターミナルとしては True、False、Unknown、および Failure があります。テストが成功すると、メッセージは True ターミナルに伝搬し、失敗すると、False ターミナルに伝搬します。ステートメントが解決できない場合 (例えば、入力メッセージにはないフィールドの値をテストする場合)、メッセージは Unknown ターミナルに伝搬します。他のエラーが検出された場合、メッセージは Failure ターミナルに伝搬されます。
ESQL ステートメントのテストの結果は、メッセージの内容、データベースの内容、またはこの両者の組み合わせによって異なることがあります。
データベースを参照する場合、このノードがデータベースにアクセスする方法を、ブローカー・システムのレジストリーで定義されるデータ・ソースごとに、ユーザーおよびパスワード情報を指定することによって、制御することができます。 これらの値を初期化し、保守するには、mqsisetdbparms コマンドを使用します。
メッセージ選択およびルーティングを提供するためには、このノードを Compute ノードより優先して使用してください。このタスクでは Filter ノードのほうが効率的です。
複数の TimeoutControl ノードをそれぞれの TimeoutNotification ノードに関連付けることができます。
AggregateControl、AggregateReply、および AggregateRequest ノードを使用すると、関連する要求および応答を照合することができます。これらのノードを使用して、1 つの入力メッセージに応答していくつかの要求を生成し、それらの要求に対する応答として受け取られる応答を制御および調整し、応答が提供する情報を結合して処理を続行します。
以下のノードを使用すると、エラーの処理および報告に影響します。