メッセージ・ツリーの移植方法

メッセージ・ツリーには、メッセージ・フローの入力ノードによって最初にデータが取り込まれます。

入力ノードが入力メッセージを受け取ると、プロパティー・ツリー (メッセージ・ツリーの最初のサブツリー) が作成され、そこにメッセージ・フローで構成したノード・プロパティーが移植されます。 このツリーは入力メッセージのビット・ストリームの内容を調べ、メッセージ・ツリーの残りを作成してその内容を反映させます。 このプロセスはある程度、入力ノード自体に依存しており、メッセージを受信するトランスポートによって制御されます。

WebSphere MQ Enterprise Transport、および WebSphere MQ Telemetry Transport プロトコル
ご使用のアプリケーションがこうしたプロトコルを介してブローカーと通信しており、メッセージ・フローには、対応する MQInput、、または SCADAInput ノードが組み込まれている場合には、受信するすべてのメッセージが Message Queue Message Descriptor (MQMD) ヘッダーで開始する必要があります。メッセージの開始時に有効な MQMD がない場合には、メッセージは拒否され、それ以上処理されません。

入力ノードはまず MQMD パーサーを起動し、そのヘッダーのサブツリーを作成します。

メッセージは追加のヘッダー全く持たないか、MQMD の後に相互にチェーニングされた追加のヘッダーを持つことができます。 追加のヘッダーを持つ場合、あるヘッダーの「形式」フィールドで、メッセージ本体の形式を定義する最後のヘッダーに至るまでの後続のヘッダーの形式を定義します。 チェーン内に MQRFH および MQRFH2 ヘッダーがある場合には、これら 2 つのヘッダーのいずれかの「名前/値」データにも、後続のデータの形式に関する情報を含めることができます。 「形式」で指定した値が認識済みパーサーで、「名前/値」データよりも常に優先されます。

ブローカーは適切なパーサーを呼び出し、メッセージ内のチェーンに従って、それぞれのヘッダーを解釈します。各ヘッダーは、個別に構文解析されます。 単一のヘッダー内のフィールドは、パーサーが定める順序で解析されます。 選択される順序を予測したり定めたりはできませんが、フィールドが構文解析される順序はヘッダー内にフィールドが現れる順序には影響しません。

メッセージ本体に先行するヘッダーの整合性の保守は、ブローカーが行います。 メッセージの各部分の形式は、直前のヘッダーの中の「形式」フィールド (続く部分が認識されている WebSphere MQ 形式の場合) か、MQRFH または MQRFH2 ヘッダー内で設定されている値によって定義されます。

  • 最初のヘッダーの形式は既知であり、MQMD でなければなりません。
  • メッセージ内の後続のヘッダーの形式は、最初のヘッダーの「形式」フィールドで設定されます。
  • 本文の形式は、メッセージ・ドメインと、メッセージ本体 のために呼び出す必要のあるパーサー (例えば、XML) に対応しています。 この情報は、MQRFH または MQRFH2 ヘッダーで設定されるか、メッセージを 受信する入力ノードのドメイン・プロパティーで設定されるかのいずれかです。

この処理は、メッセージ本体に先行するヘッダーの数に必要な回数反復されます。 ユーザー自身がこれらのフィールドにデータを移植する必要はありません。 このシーケンスはブローカーが処理してくれます。

ブローカーは、この処理を完了し、ヘッダーの「形式」フィールド がメッセージの各部分を正確に識別するようにします。 ブローカーが正確に識別しない場合、WebSphere MQ ではメッセージを送達できない可能性があります。 メッセージ本体のパーサーが、認識された WebSphere MQ ヘッダー形式でないため、ブローカーはこの値を最終ヘッダーの「形式」フィールドで値 MQFMT_NONE に置き換えます。 そのフィールドの元の値は、MQRFH または MQRFH2 ヘッダー内の「ドメイン」 フィールドに保管され、メッセージ本体の内容についての情報が保存されます。 MQRFH や MQRFH2 がない場合、情報はプロパティー・ツリーに保管されます。

例えば、MQRFH2 ヘッダーのすぐ後にメッセージ本体が続く場合で、ヘッダーの「形式」フィールドが XML に設定されている (つまり、メッセージ本体は汎用の XML パーサーによって構文解析されなければならない) 場合、MQRFH2 の「ドメイン」フィールドは XML に設定され、「形式」 フィールドは MQFMT_NONE にリセットされます。

これらのアクションの結果、ESQL 式によって明示的に保管された情報がブローカーによって置き換えられることがあります。

すべてのヘッダーが構文解析され、対応するサブツリーがメッセージ・ツリーに作成された場合には、入力ノードは指定されたパーサーとメッセージ本体とを関連付けます。 メッセージ本体の内容と関連したパーサーを指定する必要があります。 このことは、メッセージのヘッダー、例えば MQRFH2 内の <mcd> フォルダー内 (一般に推奨)、または入力ノード・プロパティー内 (メッセージにヘッダーが組み込まれていない場合に推奨される) のいずれかで行うことができます。入力ノードは、下記のように関連付けを行います。

  • メッセージに MQRFH または MQRFH2 ヘッダーが付いている場合、そのヘッダーで指定されているドメイン (「形式」または「名前/値」データのいずれか) が、このメッセージに関連付けられるパーサーを判別します。

    SCADAInput ノードは、TCP/IP ポート上でリスナーが受信する入力メッセージから、MQRFH2 ヘッダーを持つ WebSphere MQ フォーマット設定メッセージを作成します。

  • メッセージに MQRFH または MQRFH2 ヘッダーが付いていない場合や、ヘッダーでドメインが識別されていない場合であっても、プロパティー・ツリーに保管された入力ノードのプロパティーが、メッセージのドメインを示していれば、入力ノードのプロパティーが指定するパーサーが使用されます。 ユーザー定義のパーサーを指定できます。
  • 入力ノードのヘッダー値またはプロパティーによってメッセージ・ドメインが認識されない場合には、そのメッセージはバイナリー・オブジェクト (BLOB) として処理されます。BLOB パーサーがメッセージに関連付けられます。 BLOB は、16 進文字のストリングとして解釈することができ、ストリングのサブセットの位置を指定することによって、メッセージ・フロー内で変更したり調べたりすることができます。

メッセージ本体はパフォーマンス上の理由で構文解析されません。 メッセージ・フローの構成がメッセージ本体の構文解析を必要としないこともありえます。 メッセージ・フロー中にその内容に対して参照が行われる際のみ本体が構文解析されます。

例えば、Root.XML.Field (または Compute ノード内の InputRoot.XML.Field) または Root.MRM.Field を参照するときに、メッセージ本体が構文解析されます。 メッセージ・フロー内で取られるパスによっては、この構文解析は別の時点で行われることもあります。 この、最初に必要となるときに構文解析するアプローチは、部分構文解析とも呼ばれ、通常の処理ではメッセージ・フローの論理に影響を与えません。 ただし、エラー処理のシナリオに対して、いくらかの含意があります。そのことはメッセージ・フローのエラー処理で説明されています。

メッセージ・フローが複数のメッセージ・ドメインからメッセージを受け入れるようにするには、入力ノードがメッセージ・ドメインおよび関連したメッセージ定義情報 (セット、タイプ、および形式) を抽出するメッセージを MQRFH2 ヘッダーに含めることができます。

メッセージ・ヘッダーや入力ノード・プロパティーをセットアップして、ユーザー定義パーサーを指定する場合、メッセージを解釈し論理ツリーを構成する方法は、ここでの説明とは異なる場合があります。

WebSphere MQ Multicast TransportWebSphere MQ Real-time Transport、および WebSphere MQ Web Services Transport プロトコル
ご使用のアプリケーションがサポートされているプロトコルを介してブローカーと通信し、ご使用のメッセージ・フローには、対応する Real-timeInput、HTTPInput、または HTTPRequest ノードが組み込まれている場合には、受信するメッセージが特定のヘッダーを組み込んでいる必要はありません。 ご使用のアプリケーションに MQRFH2 ヘッダーを組み込んで、メッセージ関連情報 (パブリケーションおよびサブスクリプションなど) を提供することができます。 認識済みのヘッダーが組み込まれている場合には、他のサポートされているプロトコルに関して述べられているのと同様、入力ノードは適切なパーサーを呼び出してヘッダーを解釈し、メッセージ・ツリーの関連部分を構築します。

ヘッダーがない場合、または他のヘッダーがメッセージ本体のパーサーを指定していない場合には、入力ノード・プロパティーを設定してメッセージ本体パーサーを定義しなければなりません。 そのようにしない場合には、メッセージは BLOB として処理されます。ユーザー定義のパーサーを指定できます。

指定されたパーサーは (WebSphere MQ Enterprise TransportWebSphere MQ Mobile Transport、および WebSphere MQ Telemetry Transport プロトコルの場合と同様に) 入力ノードでメッセージ本体と関連付けられ、メッセージ本体は構文解析されません。

メッセージ・ヘッダーや入力ノード・プロパティーをセットアップして、ユーザー定義パーサーを指定する場合、メッセージを解釈し論理ツリーを構成する方法は、ここでの説明とは異なる場合があります。

他のすべてのプロトコル
WebSphere Message Broker が組み込みサポートを提供していないトランスポート・プロトコルからのメッセージをメッセージ・フローが受け入れるようにしたい場合や、メッセージの受信に関してメッセージ・フローが特定の処理を提供するようにしたい場合には、Java と C 言語プログラム・インターフェースのいずれかを使用して、新しいユーザー定義の入力ノードを作成します。

このインターフェースでは、メッセージのプロパティー・サブツリー (このサブツリーについては、メッセージ・ツリー構造で説明されています) が自動的に生成されるわけではありません。メッセージにプロパティー・サブツリーを含めることは要件ではありませんが、入力ノードに関係なく、プロパティー・フォルダーを作成して一貫したメッセージ・ツリー構造を用意すると便利かもしれません。 メッセージ・ツリーにプロパティー・サブツリーを作成する場合で、ユーザー定義の入力ノードを使用している場合、この作業は自分で行う必要があります。

定義されているどのメッセージ・ドメインにも準拠しないメッセージを処理する必要がある場合は、C 言語プログラミング・インターフェースを使用して新しいユーザー定義パーサーを作成することができます。

ノード・インターフェースがパーサーを使用する仕組みを理解し、ノード・インターフェースを構成してその動作を変更できるかどうかを確認するために、そのノード・インターフェースを参照します。 ノードでユーザー定義パーサーを使用している場合、メッセージ用に作成したツリー構造は、組み込みパーサー用に作成したツリー構造といくらか異なる場合があります。 ユーザー定義の入力ノードは、入力メッセージを完全に構文解析するか、または必要なときにのみメッセージ本体が構文解析される部分構文解析に加わることができます。

C または Java で、ユーザー独自の出力ノードやメッセージ処理ノードを作成することもできます。

関連概念
論理ツリー構造
メッセージ・ツリー構造
Environment ツリー構造
LocalEnvironment ツリー構造
ExceptionList ツリー構造
部分構文解析
相関名
関連タスク
メッセージ・フローのエラー処理
メッセージ・フローの作成
関連資料
組み込みノード
ユーザー定義のノード
MQRFH2 ヘッダー
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック
Copyright IBM Corporation 1999, 2006 最終更新: 08/21/2006
ac18520_