メッセージがメッセージ・フローの入力ノードによって受け取られると、ノードは、メッセージが定義されるドメインを判別し、適切なパーサーを開始することによって、そのメッセージの解釈方法を検出します。
メッセージ・ドメイン情報を、以下の 2 つの方法のどちらかで入力ノードに提供できます。
- 組み込み入力ノードを構成することにより、メッセージ・ドメインを示し、したがって受け取る各メッセージごとに開始されるパーサーを示すことができます。
- この情報を指定する、入力メッセージ自体に値を設定できます。
メッセージ特性を定義するフォルダーを含む MQRFH2 ヘッダーを組み込みます。
これはより柔軟なアプローチです。それは入力ノードが、各メッセージの内容に基づいて該当するパーサーを開始できることを意味するからです。
入力メッセージが MRM ドメインで定義され、その結果 MRM パーサーで解釈される場合、以下の追加のプロパティーを指定することが必要になります。
- メッセージ・セット。この中でメッセージが定義される
- メッセージ・タイプ。メッセージ・モデルによって定義される
- メッセージ形式。メッセージの物理的特性を定義する
これらのプロパティーを設定する方法は、次のように、使用するメッセージのタイプ、つまりノードによって異なります。
- メッセージが WebSphere® MQ メッセージである場合、これらのプロパティーは、入力ノードか、または着信メッセージの MQRFH2 ヘッダーのどちらかで設定することができます。 プロパティーを両方で設定すると、MQRFH2 ヘッダーのプロパティーが優先されます。 プロパティーがノードまたは MQRFH2 ヘッダーのどちらでも見つからない場合、デフォルト値は空になり、BLOB パーサーが使用されます。
- メッセージが JMS メッセージである場合、ノードに設定したプロパティーが優先されます。
「メッセージ・ドメイン」が空の場合、デフォルトでは「メッセージ・ドメイン」は、事前定義されている優先順位の順序どおりの、特定の基準に従って導出されます。JMS メッセージのペイロードおよび適切なパーサーを参照してください。
- 入力メッセージが、パーサーの提供対象以外の「メッセージ・ドメイン」に所属する場合、それを処理するためのユーザー定義のパーサー、およびメッセージ・フローでそれを処理できるようにするためのユーザー定義のノードを提供する必要があります。
ユーザー定義のパーサーとノードに関する詳細については、提供されるマニュアルを調べてください。
- 「メッセージ・ドメイン」が TimeoutControl ノード内にある場合、空の「メッセージ・ドメイン」は、以下のいずれかの結果を生じます。
- 「保管されたメッセージのロケーション」プロパティーも空の場合、メッセージ全体が保管されます。 TimeoutNotification の時点でメッセージが返送されると、元のメッセージと同じやり方で解析されます。
- 「保管されたメッセージのロケーション」プロパティーが空でない場合、部分的なメッセージが保管されて、パーサーは関連付けられません。そのため、デフォルトでそれは BLOB として扱われます。
- 「メッセージ・ドメイン」が ResetContentDescriptor ノード内にある場合、空の「メッセージ・ドメイン」は、以下のいずれかの結果を生じます。
- 「メッセージ・ドメインのリセット」をクリアした場合、そのドメインはリセットされません。
- 「メッセージ・ドメインのリセット」を選択した場合、デフォルトは BLOB になります。
- 入力ノードがメッセージ特性を判別できない場合、デフォルト値は空であり、メッセージは BLOB ドメインにあると見なされ、BLOB パーサーが開始します。
以下のいずれかのサンプル、または「
メッセージ・セット」を使用する他のサンプルをインポートし、サンプルのメッセージ・フロー内の入力ノードの
「入力メッセージの構文解析」プロパティー・タブの値を調べます。
サンプルに関する情報は、WebSphere Message
Broker Toolkit に統合されているインフォメーション・センター、またはオンライン・インフォメーション・センターを使用する場合にのみ表示できます。 サンプルは、WebSphere Message
Broker Toolkit に統合されているインフォメーション・センターを使用する場合にのみ実行できます。