私はHL7メッセージを受信し、クライアントのサーバーにメッセージを渡すBizTalkインターフェイスを持っています。このインターフェースのために、私は双方向RPと応答SPを持っています。現在の動作では、双方向RPはメッセージを受信するとACKを生成します。 SPはそのメッセージをクライアントに送信し、クライアントはACKで応答します。 SPは、ackを受信したときにクライアントサーバから送信されたACKを消費します。私の質問は、SPからのACKがRPに伝搬され、同じRPソケットのソースに戻るようにBizTalkを設定する方法です。私はオーケストレーションを避けようとしています。これはカスタムパイプラインコンポーネントでなければなりませんか？BizTalk Ack伝播
ありがとうございます！
だから、多くのreasearchとトレイルとエラーの後。これはBizTalk 2013 R2のネイティブ機能であることが判明しました。 RPがRPの受信パイプラインで生成されたACK、具体的には逆アセンブラによって生成されたACKをピックアップしていたため、以前は動作していなかったのです。したがって、クライアントからのACKが返ってくると、どこに行き先がなくRPで中断されます。これは、パーティを作成し、ackルーティングをチェックしてAck TypeをNoneに設定することで対処できます。 
実装上の制限により、上記の方法を使用するパーティを作成できませんでした。 RPの受信パイプライン用のカスタムパイプラインコンポーネントをコーディングして、逆アセンブラからのACKを抑制する必要がありました。これは同様にうまくいった。
HL7パーティを使用し、肯定応答タブで肯定応答タイプを「なし」に設定することによって、あなたのアプローチを行うことができます。これにより、HL7逆アセンブラはメッセージの受信時に肯定応答を生成しません。受信側から受信確認を受け取った送信側では、元のメッセージコンテキストと同じEpmRRCorrelationTokenコンテキストプロパティを持っていることを確認してください。 ACKメッセージにこのコンテキストプロパティを書き込むには、送信ポート（受信側）でカスタムパイプラインコンポーネントを使用する必要があります。これにより、ACKメッセージがRCVポートに送られます。私は以前これをやったことはないが、うまくいくはずだ。
メッセージ送信システムは、BizTalkがメッセージを正常に送信し、メッセージ受信システムからの確認応答を受信できるようになるまで、確認応答を待機するため、設計の観点からは非常に良い考えではありません。受信システムに問題があり、メッセージを消費できない、または予定された停止時間があるケースを検討する必要があります。ほとんどの時間送信システムは肯定応答にタイムアウトを設定しており、その時間枠内で肯定応答が得られなかった場合は再試行するため、重複したメッセージの問題が発生します。
答えVikasに感謝します。私は明確にしたいのは、送信側で、ACKのEpmRRCorrelationTokenがRPで生成されたものと同じである必要があるということですか？ これは、クライアントからのACKを受け取るまで、次のメッセージを送信しないという要求元です。 – C4T3
はい、受信したメッセージには、そのコンテキストのプロパティが表示されます –
まず、オーケストレーションの使用に間違いはありません。 「パフォーマンス」を心配しないでください。
正しいBizTalk方法は、オーケストレーションを使用して、ダウンストリームシステムとの同期を管理することです。
保留中です！ 「実装上の制限」???あなたがたぶんすでに知っているが、そのような制限は間違っていてうまくいき、ばかげていると言うことができます。 BizTalkの機能を正しく使用できるように、実際の問題や制限を解決する手助けをしましょう。私はこれまでこのような "建築家"に取り組んできました。 –
@ Johns-305明確にするために、パーティを使用して受信ポートの受信パイプラインで逆アセンブラがACKを生成するのを防ぐのではなく、受信パイプラインの終わりにackを消費する小さなカスタムコンポーネントを追加したばかりです。残りの部分はすべてBizTalkによって処理されます。複数のソースからのMSH.3がすべてのメッセージで同じであるにもかかわらず、1つのソースだけがクライアントからの回答を望むため、パーティを使用することはできません。残りのソースはBizTalkによって生成されたackでOKであり、クライアントのackを気にしません。 – C4T3