このシナリオで示すのは、ドメインとして MIME を使用して、WebSphere MQ が使用可能なアプリケーションへのインターフェースを提供する Web サービスです。このシナリオのメッセージ・フローと、結果のメッセージ・ツリーを以下に示します。
MIME メッセージが メッセージ・フロー に入力されると、メッセージの最上位の Content-Type が HTTPInputHeader ツリーおよび MIME 論理メッセージ・ツリーに保管されます。ブローカーはまた、メッセージの Content-Type のコピーを、Properties サブツリーの ContentType 値として保管します。以下の図は、メッセージが HTTPInput ノードを離れた後のメッセージ・ツリーを示しています。
SET OutputRoot.XML.X.rid = CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS CHARACTER);以下の図は、Compute1 を離れた後のメッセージ・ツリーを示しています。
MQ メッセージを受信するアプリケーションが MIME フォーマットのメッセージを要求する場合、MIME ツリーが必要です。 Compute1 は、新規の MIME ツリーを作成するか、既存の MIME ツリーを変更して伝搬するかのいずれかによって、これを提供できます。メッセージの Content-Type を変更するには、ブローカー ContentType プロパティーを使用する必要があります。ブローカー ContentType プロパティーを変更すると、MIME ツリーの Content-Type プロパティーは自動更新されます。
SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier = CAST(InputRoot.XML.X.rid AS BLOB);Compute2 は明示の HTTPReplyHeader もセットアップできます。
出力ドメインが MIME の場合、メッセージを出力するために MIME ツリーを作成する必要があります。Compute2 は、新規の MIME メッセージを作成するか、または出力メッセージ作成の必要に応じて入力 MIME メッセージを変更および伝搬します。以下の図は、Compute2 を通過した後のメッセージ・ツリーを示しています。
このシナリオは、いろいろ変動することが考えられます。 例えば、MQInput ノードの代わりに MQGet ノードを使用して単一フローが作成された場合、HTTP 相関関係子を保管する必要がありません。 ただし、これは潜在的にあまりスケーラブルではありません。Coordinated Request Reply サンプル のサンプルに、MQGet ノードの使用に関する詳しい情報があります。