メッセージ・ツリーには、メッセージ・フローの入力ノードによって最初にデータが取り込まれます。
入力ノードが入力メッセージを受け取ると、プロパティー・ツリー (メッセージ・ツリーの最初のサブツリー) を作成して完成します。 メッセージ・ツリー構造を参照してください。
このノードは入力メッセージのビット・ストリームの内容を調べ、メッセージ・ツリーの残りを作成してその内容を反映させます。 このプロセスはある程度、入力ノード自体に依存しており、メッセージを受信するトランスポートによって制御されます。
入力ノードはまず MQMD パーサーを起動し、そのヘッダーのサブツリーを作成します。
メッセージは追加のヘッダーをまったく持たないか、MQMD の後に追加のヘッダーを持つことができます。 これらのヘッダーは、相互にチェーニングされ、あるヘッダーの「形式」フィールドで、メッセージ本体の形式を定義する最後のヘッダーに至るまでの後続のヘッダーの形式を定義します。 チェーン内に MQRFH および MQRFH2 ヘッダーがある場合には、これら 2 つのヘッダーのいずれかの「名前と値」データに、後続のデータの形式に関する情報を含めることができます。 「形式」で指定した値が認識済みパーサーの場合は、この値は、「名前と値」データよりも常に優先されます。
ブローカーは適切なパーサーを呼び出し、メッセージ内のチェーンに従って、それぞれのヘッダーを解釈します。 各ヘッダーは、個別に構文解析されます。 単一のヘッダー内のフィールドは、パーサーが定める順序で解析されます。 選択される順序を予測することはできませんが、フィールドが構文解析される順序は、ヘッダー内にフィールドが表示される順序には影響しません。
メッセージ本体に先行するヘッダーの整合性の保守は、ブローカーが行います。 メッセージの各部分の形式は、直前のヘッダーの中の「形式」フィールド (続く部分が認識されている WebSphere MQ 形式の場合) か、MQRFH または MQRFH2 ヘッダー内で設定されている値によって定義されます。
この処理は、メッセージ本体に先行するヘッダーの数に必要な回数反復されます。 ユーザー自身がこれらのフィールドにデータを移植する必要はありません。 このシーケンスはブローカーが処理してくれます。
ブローカーは、この処理を完了し、ヘッダーの「形式」フィールドがメッセージの各部分を正確に識別するようにします。 ブローカーがこの処理を完了しない場合、WebSphere MQ ではメッセージを送達できない可能性があります。 メッセージ本体のパーサーが、認識された WebSphere MQ ヘッダー形式でないため、ブローカーはこの値を最終ヘッダーの「形式」フィールドで値 MQFMT_NONE に置き換えます。 そのフィールドの元の値は、MQRFH または MQRFH2 ヘッダー内の「ドメイン」フィールドに保管され、メッセージ本体の内容についての情報が保存されます。
例えば、MQRFH2 ヘッダーのすぐ後にメッセージ本体が続く場合で、ヘッダーの「形式」フィールドが XMLNSC に設定されている (つまり、メッセージ本体は XMLNSC パーサーによって構文解析されなければならない) 場合、MQRFH2 の「ドメイン」フィールドは XMLNSC に設定され、「形式」フィールドは MQFMT_NONE にリセットされます。
これらのアクションの結果、ESQL または Java™ 式によって明示的に保管された情報がブローカーによって置き換えられることがあります。
CodedCharSetId フィールドと Encoding フィールドには、Format フィールドと同じ方法ではデータが取り込まれません。 特に、メッセージ本体を使って値 CodedCharSetId および Encoding が判別されることはありません。 代わりに、これらの値はメッセージ本体の書き込み方法に影響を与えます。 このため、削除されるヘッダー値でチェーン内の前のヘッダーを更新しないまま、中間ヘッダー (例えば MQRFH2) が削除された場合、予期しない結果が生じることがあります。
すべてのヘッダーが構文解析され、対応するサブツリーがメッセージ・ツリーに作成された場合には、入力ノードは指定されたパーサーとメッセージ本体とを関連付けます。 メッセージのヘッダー (例えば MQRFH2 ヘッダー内の <mcd> フォルダー)、または入力ノード・プロパティー内 (メッセージにヘッダーが組み込まれていない場合) のいずれかでメッセージ本体の内容に関連付けられるパーサーを指定します。 入力ノードは、以下のリストに説明されているとおりに関連付けを行います。
デフォルトでは、メッセージ本体は、パフォーマンス上の理由からすぐには構文解析されません。 メッセージ本体は、メッセージ・フロー中に構文解析が不要の場合があります。 その内容に対して参照が行われる際のみ構文解析されます。
例えば、Root.XMLNSC.MyDoc.MyField といった、メッセージ本体内のフィールドを参照すると、メッセージ本体が解析されます。 メッセージ・フロー内のどのパスを通るかによって、さまざまな時点でこれが行われる可能性があります。 この「最初に必要になったときに構文解析する」手法は、「部分構文解析」または「オンデマンド解析」とも呼ばれますが、標準的な処理ではメッセージ・フローの論理に影響を与えません。 ただし、エラー処理のシナリオの場合には、特定の意味を持ちます。メッセージ・フローのエラー処理を参照してください。
メッセージ・フローが複数のメッセージ・ドメインからメッセージを受け入れるようにするには、入力ノードがメッセージ・ドメインおよび関連したメッセージ定義情報 (メッセージ・セット、メッセージ・タイプ、およびメッセージ形式) を抽出するメッセージに MQRFH2 ヘッダーを付けます。
メッセージ・ヘッダーや入力ノード・プロパティーをセットアップして、ユーザー定義のドメインおよびパーサーを指定する場合、メッセージを解釈し論理ツリーを構成する方法は、ここでの説明とは異なる場合があります。
ヘッダーがない場合、または他のヘッダーがメッセージ本体のパーサーを指定していない場合には、入力ノード・プロパティーを設定してメッセージ本体パーサーを定義します。 ノード・プロパティーをこのように設定しない場合には、メッセージは BLOB として処理されます。 ユーザー定義のパーサーを指定できます。
指定されたパーサーは (WebSphere MQ Enterprise Transport プロトコルの場合と同様に) 入力ノードでメッセージ本体と関連付けられ、デフォルトでは、メッセージ本体は即時には構文解析されません。
メッセージ・ヘッダーや入力ノード・プロパティーをセットアップして、ユーザー定義のドメインおよびパーサーを指定する場合、メッセージを解釈し論理ツリーを構成する方法は、ここでの説明とは異なる場合があります。
このインターフェースでは、メッセージのプロパティー・サブツリー (このサブツリーについては、メッセージ・ツリー構造で説明されています) が自動的に生成されるわけではありません。 メッセージにプロパティー・サブツリーを含める必要はありませんが、入力ノードに関係なく、プロパティー・フォルダーを作成して一貫したメッセージ・ツリー構造を用意すると便利かもしれません。 ユーザー定義の入力ノードを使用している場合は、自分でメッセージ・ツリーにプロパティー・サブツリーを作成する必要があります。
定義されているどのメッセージ・ドメインにも準拠しないメッセージを処理するには、C 言語プログラミング・インターフェースを使用して新しいユーザー定義パーサーを作成します。
ノード・インターフェースがパーサーを使用する仕組みを理解し、ノード・インターフェースを構成してその動作を変更できるかどうかを確認するために、そのノード・インターフェースを参照します。 ノードでユーザー定義パーサーを使用している場合、メッセージ用に作成したツリー構造は、組み込みパーサー用に作成したツリー構造といくらか異なる場合があります。 ユーザー定義の入力ノードは、入力メッセージを完全に構文解析するか、または必要なときにのみメッセージ本体が構文解析される部分構文解析に加わることができます。
C または Java で、ユーザー独自の出力ノードやメッセージ処理ノードを作成することもできます。
同一フィールドの場合にどちらのフォルダーが優先されるかという点で、Properties フォルダーと MQMD フォルダーの取り扱い方には相違があります。 その取り扱い方は、使用するトランスポート・タイプ (例えば、HTTP や WebSphere MQ) によって特徴が決まります。
メッセージ・フローのソースが MQInput ノードである場合、MQMD が解析の対象になります。 そのような場合、Properties フォルダーは MQMD 値をソースとするので、フォルダー間の値の伝搬という点で、Properties フォルダーよりも MQMD フォルダーが優先されます。 このシナリオは、例えば SET OutputRoot.MQMD.CorrelId といった ESQL を実行できることを意味し、このコマンドによって Properties フォルダーの値が更新されます。
メッセージ・フローが、MQInput ノードではない入力ノード (HTTPInput ノードまたはユーザー定義の入力ノード) をソースとする場合、MQMD はまったく解析されません。 このシナリオでは、Properties フォルダーは入力 MQMD をソースとしません。つまり、このフォルダーは、作成されてから、他のトランスポート固有のヘッダーから取られたトランスポート値が取り込まれます。 WebSphere MQ トランスポートをソースとしないメッセージ・フロー内で MQMD フォルダーを作成すると、WebSphere MQ トランスポートによってデータが Properties フォルダーに取り込まれることはないので、MQMD ヘッダーが Properties フォルダーより優先されることはありません。 したがって、そのような場合、Properties フォルダーは MQMD 内のすべて値を上書きします。
Properties フォルダーは、構成されると、トランスポートで受信されるメッセージを表します。 このシナリオでは、それぞれ異なる意味を持っているので Properties フォルダーの要件も異なる 2 つのまったく異なるトランスポートが使用されます。 HTTP ヘッダーが HTTPInput ノードをソースとする場合、同種フィールドの Properties フォルダーは HTTP ヘッダーの制御下に置かれます。 MQMD が MQInput ノードをソースとする場合、同種フィールドの Properties フォルダーは、MQMD の制御下に置かれます。
SET OutputRoot.Properties.ReplyIdentifier = X' ..... ';
この動作は、CorrelId から ReplyIdentifier のフィールドにのみ固有の動作ではありません。
これは、次のような、MQMD と Properties フォルダーの間のすべての同種フィールドにも当てはまります。SET OutputRoot.Properties = InputRoot.Properties;
SET OutputRoot.MQMD.Version = 2;
SET OutputRoot.MQMD.CorrelId = X'4d454e53414a453320202020202020202020202020202020';
SET OutputRoot.MQMD.Encoding = 785;
SET OutputRoot.MQMD.CodedCharSetId = 500;
SET OutputRoot.MQMD.Persistence = 1;
SET OutputRoot.MQMD.Expiry = 10000;
SET OutputRoot.MQMD.Priority = 9;
SET OutputRoot.BLOB.BLOB = X'01';
HTTPInput ノードがソースである場合、これらの変更が有効になることはなく、Compute ノードからの MQMD 出力は次のようになります。(0x01000000):MQMD = (
(0x03000000):Version = 2
(0x03000000):CorrelId = X'000000000000000000000000000000000000000000000000'
(0x03000000):Encoding = 546
(0x03000000):CodedCharSetId = 1208
(0x03000000):Persistence = FALSE
(0x03000000):Expiry = -1
(0x03000000):Priority = 0