次の方法で共有

受信アダプターの交換パターン

  • [アーティクル]

受信アダプターは、"ワイヤ" からデータを受信し、メッセージとしてBizTalk Serverに送信します。 この送信プロセスには、一方向または双方向のメッセージ交換パターンが可能です。

一方向の送信

受信アダプターから BizTalk メッセージング エンジンにメッセージを送信するには、まず受信アダプターで新しい BizTalk メッセージを作成する必要があります。 IBaseMessage のトピックのコード例では、この方法を示しています。 アダプターがメッセージ本文として設定するストリームは通常、順方向専用のストリームである必要があります。つまり、このストリームで以前メモリに読み込んだデータを、再度ストリームにキャッシュすることはできません。

アダプターは、メッセージをエンジンに送信する前に、システム名前空間の InboundTransportLocation メッセージ コンテキスト プロパティを BizTalk メッセージに書き込む必要があります。 次のコードはこの処理を示すものです。

Assembly References:

Microsoft.XLANGs.BaseTypes.dll

Microsoft.BizTalk.Pipeline.dll

Microsoft.BizTalk.GlobalPropertySchemas.dll

using Microsoft.BizTalk.Message.Interop;  
using Microsoft.XLANGs.BaseTypes;  
  
private static readonly PropertyBase InboundTransportLocationProp =   
new BTS.InboundTransportLocation();  
  
private void StampMsgCtxProps(  
IBaseMessage msg, string uri, string adapterType)  
{  
msg.Context.Write(  
 InboundTransportLocationProp.Name.Name,   
 InboundTransportLocationProperty.Name.Namespace,   
  uri);  
}

アダプターではさらに、独自のプロパティ スキーマを定義して、メッセージを受信したエンドポイントのメッセージ コンテキスト プロパティを書き込む場合もあります。 たとえば、HTTP アダプターではメッセージ コンテキストに HTTP ヘッダーを書き込む場合があり、SMTP レシーバーではメッセージ コンテキストにメールの件名を書き込む場合があります。 この情報は、パイプライン コンポーネント、オーケストレーション スケジュール、送信アダプターなどの下流コンポーネントで役立ちます。

メッセージを作成したら、メッセージング エンジンに送信できます。 一方向受信アダプターがエンジンにメッセージを送信する方法については、コード サンプル SubmitDirect (BizTalk Server サンプル) を参照してください。

Request-Response

通常、双方向の受信アダプターは、一方向または双方向の受信ポートで使用します。 アダプターは、サービスを提供している受信場所が、BizTalk Server構成プロパティ バッグを調べることによって、一方向または双方向のポートであるかどうかを判断します。 このプロセスについては、UI ガイダンスと開発者 API 名前空間リファレンスの IBTTransportConfig.AddReceiveEndpoint メソッド (COM) で説明されています。

下の図に、オブジェクト間の対話処理における要求 - 応答のメッセージ交換の実行手順を示します。 アダプターは、トランスポート プロキシから新しいバッチを要求し、SubmitRequestMessage メソッドを介して IBTTransmitter インターフェイスへの参照を渡します。 メッセージング エンジンは、 TransmitMessage メソッドを使用して、このインターフェイスで応答メッセージを配信します。

メッセージング エンジンはメッセージを非同期的に処理します。したがって、次の問題が発生する可能性があります。

  • BatchComplete コールバックは、Done が返される前に発生する可能性があります。

  • TransmitMessage の呼び出しが、BatchComplete や、場合によっては Done より前に行われる。

    どちらも発生の可能性は低いものですが、アダプターではこのような問題への対策を用意しておく必要があります。

    応答メッセージは、非同期の非ブロッキング呼び出しを使用して送信することをお勧めします。

    BaseAdapter プロジェクトには、このトピックで説明する要求/応答セマンティクスをカプセル化するユーティリティ クラス StandardRequestResponseHandler があります。

要求 - 応答メッセージのタイムアウト

アダプターが要求要求メッセージを送信する場合は、UI ガイダンスと開発者 API 名前空間リファレンスの IBTTransportBatch.SubmitRequestMessage メソッド (COM) API で要求メッセージのタイムアウトを指定する必要があります。 指定したタイムアウトまでの間は応答メッセージが配信され、 タイムアウトに達すると、応答メッセージの代わりに否定受信確認応答 (NACK) がアダプターに配信されます。 アダプターでタイムアウト値を指定していない場合、エンジンでは既定値の 20 分が使用されます。

要求 - 応答メッセージのタイムアウトの既定値は、レジストリ キーを使用して設定できます。インプロセス受信アダプター用のレジストリ キーは次の場所にあります。

DWORD

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc{Host Guid}\MessagingReqRespTTL

分離受信アダプター用のレジストリ キーは次の場所にあります。

DWORD

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc.3.0\MessagingReqRespTTL

NACK (否定受信確認応答) は SOAP エラーとなります。これは 2 つの方法で処理できます。 通常は、アダプターからクライアントに NACK を返し、クライアントで NACK を処理します。 または、応答メッセージを処理する送信パイプラインで、マップまたはカスタム パイプライン コンポーネントを使用して、応答メッセージのコンテンツを変更するよう構成することもできます。