请考虑 BizTalk 中的以下消息流。
我们有几个 MLLP 接收端口/位置设置在一个应用程序中接收 HL7v2 消息。这些端口各自接收略有不同的消息类型。
我们称它为 RP1
在另一个应用程序中，我们有订阅每个相应接收端口的发送端口。这些发送端口每个都有一个出站映射，用于转换 HL7v3 中的消息并将其提交给 WCF（请求/响应）服务。
我们称之为 SP1
然后 WCF 服务处理和验证 HL7v3 并发送回 HL7v3 ack 消息。SP1 发送端口具有自定义发送和接收管道组件。接收（来自 WCF 响应）只接收消息并提升某些字段，这些字段稍后将用于订阅。
然后还有两个发送端口。订阅肯定 ACK 的 SP2。SP3 到基于上面提到的领域的否定。正面的 ACK 会被消耗掉，而负面的 ACK 会通过电子邮件发送给支持人员。
问题是，在大约 10% 的消息中，我们看到以下 2 条错误消息中的 1 条弹出：
A response message for two-way receive port "SP.CDX.LAB_MICRO.SubmitCDA.WCFCustom" is being suspended as the messaging engine could not correlate the response to an existing request message. This usually happens when the host process has been recycled.
MessageId: {731623F3-995B-4C57-BD21-12865AD78717}
InstanceID: {084BD473-C857-4C5E-A49B-8A86EA2CAC39}
The following stored procedure call failed: " { call [dbo].[bts_UpdateMsgbox_BizTalkServerReceive]( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}". SQL Server returned error string: "The statement has been terminated.;Cannot insert duplicate key row in object 'dbo.InstancesSuspended' with unique index 'IX_InstancesSuspended_InstanceID'. The duplicate key value is (084bd473-c857-4c5e-a49b-8a86ea2cac39, afa466c7-3bd2-4cde-a293-3df3fb5d8543)."
通常在 Group 查看器中跟随一个暂停的服务实例：
The instance completed without consuming all of its messages. The instance and its unconsumed messages have been suspended
被挂起的实例的Service Name 是RP1 的。未消费消息的消息类型是来自 SP1 的 ACK（因此它是 WCF 响应）。这很奇怪，因为在我看来 RP1 永远不应该期待这个响应消息，并且有发送端口（SP2、SP3）订阅了响应消息类型。
我忘了说的另一点是，有 3 个接收端口，如 RP1，每个端口都有 3 个接收位置和 3 个发送端口订阅各自的接收端口。
BizTalk Server 安装在 2 个物理服务器上，共享 1 个 BizTalkMgmtDb/Messagebox
在此之前，我们输入了相同数量的消息，但它被合并（在发送端）到一个接收位置。旧的解决方案有多个编排，但从未遇到过这个问题。
那么为什么现在 WCF (HL7v3) 响应消息会丢失并在 RP1 (HL7v2) 的实例下被挂起？
这是它的外观的基本图像。
