メッセージ・ツリーには、メッセージ・フローの入力ノードによって最初にデータが取り込まれます。
入力ノードが入力メッセージを受け取ると、プロパティー・ツリー (メッセージ・ツリーの最初のサブツリー) が作成され、そこにメッセージ・フローで構成したノード・プロパティーが移植されます。 このツリーは入力メッセージのビット・ストリームの内容を調べ、メッセージ・ツリーの残りを作成してその内容を反映させます。 このプロセスはある程度、入力ノード自体に依存しており、メッセージを受信するトランスポートによって制御されます。
入力ノードはまず MQMD パーサーを起動し、そのヘッダーのサブツリーを作成します。
メッセージは追加のヘッダー全く持たないか、MQMD の後に相互にチェーニングされた追加のヘッダーを持つことができます。 追加のヘッダーを持つ場合、あるヘッダーの「形式」フィールドで、メッセージ本体の形式を定義する最後のヘッダーに至るまでの後続のヘッダーの形式を定義します。 チェーン内に MQRFH および MQRFH2 ヘッダーがある場合には、これら 2 つのヘッダーのいずれかの「名前/値」データにも、後続のデータの形式に関する情報を含めることができます。 「形式」で指定した値が認識済みパーサーで、「名前/値」データよりも常に優先されます。
ブローカーは適切なパーサーを呼び出し、メッセージ内のチェーンに従って、それぞれのヘッダーを解釈します。各ヘッダーは、個別に構文解析されます。 単一のヘッダー内のフィールドは、パーサーが定める順序で解析されます。 選択される順序を予測したり定めたりはできませんが、フィールドが構文解析される順序はヘッダー内にフィールドが現れる順序には影響しません。
メッセージ本体に先行するヘッダーの整合性の保守は、ブローカーが行います。 メッセージの各部分の形式は、直前のヘッダーの中の「形式」フィールド (続く部分が認識されている WebSphere MQ 形式の場合) か、MQRFH または MQRFH2 ヘッダー内で設定されている値によって定義されます。
この処理は、メッセージ本体に先行するヘッダーの数に必要な回数反復されます。 ユーザー自身がこれらのフィールドにデータを移植する必要はありません。 このシーケンスはブローカーが処理してくれます。
ブローカーは、この処理を完了し、ヘッダーの「形式」フィールド がメッセージの各部分を正確に識別するようにします。 ブローカーが正確に識別しない場合、WebSphere MQ ではメッセージを送達できない可能性があります。 メッセージ本体のパーサーが、認識された WebSphere MQ ヘッダー形式でないため、ブローカーはこの値を最終ヘッダーの「形式」フィールドで値 MQFMT_NONE に置き換えます。 そのフィールドの元の値は、MQRFH または MQRFH2 ヘッダー内の「ドメイン」 フィールドに保管され、メッセージ本体の内容についての情報が保存されます。 MQRFH や MQRFH2 がない場合、情報はプロパティー・ツリーに保管されます。
例えば、MQRFH2 ヘッダーのすぐ後にメッセージ本体が続く場合で、ヘッダーの「形式」フィールドが XML に設定されている (つまり、メッセージ本体は汎用の XML パーサーによって構文解析されなければならない) 場合、MQRFH2 の「ドメイン」フィールドは XML に設定され、「形式」 フィールドは MQFMT_NONE にリセットされます。
これらのアクションの結果、ESQL 式によって明示的に保管された情報がブローカーによって置き換えられることがあります。
すべてのヘッダーが構文解析され、対応するサブツリーがメッセージ・ツリーに作成された場合には、入力ノードは指定されたパーサーとメッセージ本体とを関連付けます。 メッセージ本体の内容と関連したパーサーを指定する必要があります。 このことは、メッセージのヘッダー、例えば MQRFH2 内の <mcd> フォルダー内 (一般に推奨)、または入力ノード・プロパティー内 (メッセージにヘッダーが組み込まれていない場合に推奨される) のいずれかで行うことができます。入力ノードは、下記のように関連付けを行います。
SCADAInput ノードは、TCP/IP ポート上でリスナーが受信する入力メッセージから、MQRFH2 ヘッダーを持つ WebSphere MQ フォーマット設定メッセージを作成します。
メッセージ本体はパフォーマンス上の理由で構文解析されません。 メッセージ・フローの構成がメッセージ本体の構文解析を必要としないこともありえます。 メッセージ・フロー中にその内容に対して参照が行われる際のみ本体が構文解析されます。
例えば、Root.XML.Field (または Compute ノード内の InputRoot.XML.Field) または Root.MRM.Field を参照するときに、メッセージ本体が構文解析されます。 メッセージ・フロー内で取られるパスによっては、この構文解析は別の時点で行われることもあります。 この、最初に必要となるときに構文解析するアプローチは、部分構文解析とも呼ばれ、通常の処理ではメッセージ・フローの論理に影響を与えません。 ただし、エラー処理のシナリオに対して、いくらかの含意があります。そのことはメッセージ・フローのエラー処理で説明されています。
メッセージ・フローが複数のメッセージ・ドメインからメッセージを受け入れるようにするには、入力ノードがメッセージ・ドメインおよび関連したメッセージ定義情報 (セット、タイプ、および形式) を抽出するメッセージを MQRFH2 ヘッダーに含めることができます。
メッセージ・ヘッダーや入力ノード・プロパティーをセットアップして、ユーザー定義パーサーを指定する場合、メッセージを解釈し論理ツリーを構成する方法は、ここでの説明とは異なる場合があります。
ヘッダーがない場合、または他のヘッダーがメッセージ本体のパーサーを指定していない場合には、入力ノード・プロパティーを設定してメッセージ本体パーサーを定義しなければなりません。 そのようにしない場合には、メッセージは BLOB として処理されます。ユーザー定義のパーサーを指定できます。
指定されたパーサーは (WebSphere MQ Enterprise Transport、WebSphere MQ Mobile Transport、および WebSphere MQ Telemetry Transport プロトコルの場合と同様に) 入力ノードでメッセージ本体と関連付けられ、メッセージ本体は構文解析されません。
メッセージ・ヘッダーや入力ノード・プロパティーをセットアップして、ユーザー定義パーサーを指定する場合、メッセージを解釈し論理ツリーを構成する方法は、ここでの説明とは異なる場合があります。
このインターフェースでは、メッセージのプロパティー・サブツリー (このサブツリーについては、メッセージ・ツリー構造で説明されています) が自動的に生成されるわけではありません。メッセージにプロパティー・サブツリーを含めることは要件ではありませんが、入力ノードに関係なく、プロパティー・フォルダーを作成して一貫したメッセージ・ツリー構造を用意すると便利かもしれません。 メッセージ・ツリーにプロパティー・サブツリーを作成する場合で、ユーザー定義の入力ノードを使用している場合、この作業は自分で行う必要があります。
定義されているどのメッセージ・ドメインにも準拠しないメッセージを処理する必要がある場合は、C 言語プログラミング・インターフェースを使用して新しいユーザー定義パーサーを作成することができます。
ノード・インターフェースがパーサーを使用する仕組みを理解し、ノード・インターフェースを構成してその動作を変更できるかどうかを確認するために、そのノード・インターフェースを参照します。 ノードでユーザー定義パーサーを使用している場合、メッセージ用に作成したツリー構造は、組み込みパーサー用に作成したツリー構造といくらか異なる場合があります。 ユーザー定義の入力ノードは、入力メッセージを完全に構文解析するか、または必要なときにのみメッセージ本体が構文解析される部分構文解析に加わることができます。
C または Java で、ユーザー独自の出力ノードやメッセージ処理ノードを作成することもできます。