アダプターのメッセージ交換パターン
BizTalk アダプター フレームワークは、多くの強力なメッセージング シナリオでアダプターが使用できるメッセージ交換パターンの豊富なセットをサポートします。
一方向 (非同期)
ここでの主な概念は、メッセージが一方向に流れるということです。
このメッセージ交換パターンでは、メッセージはアダプターを介して一方向にBizTalk Serverされます。 メッセージング エンジンは、メッセージを MessageBox データベースに発行します。 オーケストレーションにこの種類のメッセージに対するアクティブなサブスクリプションがある場合は、メッセージはそのオーケストレーションにルーティングされます。
メッセージの処理の後に、オーケストレーションは、メッセージが特定のエンドポイントに送信されるアダプターにルーティングされる前に、メッセージをメッセージ ボックス データベースに公開します。
エンジンにメッセージが送信されるときに、応答は発生しません。 送信側では、メッセージが送信されるときに、応答は発生しません。 これは、通常、非同期メッセージングと呼ばれており、すべてのメッセージング シナリオでエンジンによってさまざまな形で使用される基本的なビルド ブロックです。
要求 - 応答形式のプロトコル (sync-on-async)
要求 - 応答シナリオは、要求メッセージの受信、その処理、および応答メッセージの送信で構成されています。 基になるBizTalk Server アーキテクチャはスケーラビリティ上の理由から非同期であるため、同期オン非同期 (sync-on-async) とも呼ばれます。 ただし、BizTalk メッセージング エンジンのアーキテクチャによって、これらの非同期の交換の上位で同期メッセージ交換パターンを公開できます。 これを行うために、エンジンは、同期インターフェイスを公開するために多数の非同期メッセージ交換をまとめてリンクすることによって、スケール アウトされたアーキテクチャにわたって要求メッセージおよび応答メッセージの関連付けの複雑なタスクを処理します。
たとえば、インベントリをチェックする Web ページは、BizTalk SOAP 受信アダプターに対して SOAP 呼び出しを行う場合があります。 BizTalk Server、情報を集計して 1 つの SOAP 応答で返す一連の Web サービスを調整します。 クライアントから見ると、これは同期 SOAP 呼び出しのように見えますが、実際にはエンジンによって多数の非同期メッセージ交換が結合されています。
送信請求 - 応答形式のプロトコル
このシナリオは、送信請求メッセージの送信によって開始され、応答メッセージの受信によって完了します。 これは、送信される最初のメッセージがエンドポイントに対する応答メッセージの送信請求であるため、送信請求 - 応答と呼ばれます。 このメッセージ交換パターンを使用するシナリオには、送信 HTTP 呼び出し (応答の送信請求) の作成および応答に対する待機を行うオーケストレーションが含まれることがあります。
要求 - 複数応答
このシナリオは、要求 - 応答シナリオに似ています。 ただし、このシナリオでは、指定した要求に対して複数の応答を返すことができます。 API によってタイムアウト値を指定でき、タイムアウト期間の間に受信されたすべての応答は受信アダプターに返されます。
Loop-Back
このシナリオは、要求 - 応答シナリオに似ています。 要求メッセージは通常どおり公開されますが、エンジンによって、要求メッセージを公開したアダプター インスタンスと同じアダプター インスタンスに応答メッセージが確実にルーティングされるようになります。 要求メッセージはメッセージ ボックス データベースに公開されるため、追跡インフラストラクチャによって、要求メッセージと応答メッセージの両方が確実に追跡されるようになります。 これは、メッセージを処理している送信パイプラインを呼び出し、すぐに出力メッセージを取得し、後続の処理のためにアダプターに返送する場合にも適した方法です。
このシナリオの例としては、メッセージに対する確認メッセージを要求するクライアントが挙げられます。 受信メッセージはメッセージ ボックス データベースに公開されます。 このメッセージと確認メッセージの両方は、同じバッチでアダプターに返されます。 この場合、受信メッセージは、クライアントに返されている 1 つのインスタンス、および通常の方法で処理されているもう 1 つのインスタンスを使用して、コピーされます。 この特定のシナリオでは、カスタム XML 逆アセンブラーも記述する必要があります。