消息响应僵尸出现错误代码 0xC0C01B4C 和 0xc0c016b5 无编排
Message Response Zombies occurring with errors Codes 0xC0C01B4C and 0xc0c016b5 no Orchestration
考虑 BizTalk 中的以下消息流。
我们有多个 MLLP 接收 ports/locations 设置在一个应用程序中接收 HL7v2 消息。这些端口各自接收略有不同的消息类型。
我们称这个为 RP1
在另一个应用程序中，我们有订阅每个相应接收端口的发送端口。这些发送端口每个都有一个出站映射，用于转换 HL7v3 中的消息并将其提交给 WCF (request/response) 服务。
我们称之为 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)."
通常在组查看器中跟一个挂起的服务实例：
The instance completed without consuming all of its messages. The instance and its unconsumed messages have been suspended
挂起实例的服务名称是RP1。未使用消息的消息类型是来自 SP1 的 ACK 类型（因此它是 WCF 响应）。这很奇怪，因为在我看来，RP1 永远不应期待此响应消息，并且有发送端口（SP2、SP3）订阅了响应消息类型。
另一点我忘了说，像 RP1 一样有 3 个接收端口，每个接收端口有 3 个接收位置和 3 个发送端口订阅它们各自的接收端口。
BizTalk Server 安装在共享 1 个的 2 台物理服务器上BizTalkMgmtDb/Messagebox
在此之前，我们有相同数量的消息馈送，但它被合并（在发送端）到一个接收位置。旧的解决方案有多个 Orchestrations，但从未遇到过这个问题。
那么为什么现在 WCF (HL7v3) 响应消息丢失并在 RP1 (HL7v2) 实例下被挂起？
这是它的外观的基本图片。
MLLP Receive Adapter Processing
Acknowledgments with the two-way MLLP receive adapter
When a two-way MLLP receive adapter receives a message, Microsoft BizTalk Accelerator for HL7 (BTAHL7) can generate the following types of ACKs:
HL7 Enhanced Commit ACK: In this scenario, BTAHL7 sends a Commit ACK on the same connection. It sends out an Application Accept ACK on a different send port.
Application Accept ACK: In this scenario, BTAHL7 sends an Application Accept ACK on the same connection.
Static ACK: In this scenario, BTAHL7 sends an ACK on the same connection.
The type of ACK generated depends on the BTAHL7 Configuration Explorer settings for the party sending the message. The value in fields MSH 15 and 16 of an individual message can override this setting. However, for applications expecting Static ACKs, the configuration can only be set through BTAHL7 Configuration Explorer.
根据阅读，我认为您需要将适配器配置为 HL7 增强提交 ACK
我能够通过更改 WCF 双重响应消息的上下文属性中 RouteDirectToTP 值的值来解决此问题。根据这些帖子中的信息：
https://jeremiedevillard.wordpress.com/2010/01/11/how-work-request-response-pattern-part-3/
https://bveldhoen.wordpress.com/2010/09/05/messaging-only-request-response-correlation/
显然，默认情况下，BizTalk 会尝试将 ACK 路由回原始接收端口。我刚刚在我的管道组件中做了这个：
msgReceived.Context.Promote("RouteDirectToTP", "http://schemas.microsoft.com/BizTalk/2003/system-properties", false);
至此问题已经解决。没有更多的僵尸，也没有更多关于存储过程失败的错误。
考虑 BizTalk 中的以下消息流。
我们有多个 MLLP 接收 ports/locations 设置在一个应用程序中接收 HL7v2 消息。这些端口各自接收略有不同的消息类型。
我们称这个为 RP1
在另一个应用程序中，我们有订阅每个相应接收端口的发送端口。这些发送端口每个都有一个出站映射，用于转换 HL7v3 中的消息并将其提交给 WCF (request/response) 服务。
我们称之为 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)."
通常在组查看器中跟一个挂起的服务实例：
The instance completed without consuming all of its messages. The instance and its unconsumed messages have been suspended
挂起实例的服务名称是RP1。未使用消息的消息类型是来自 SP1 的 ACK 类型（因此它是 WCF 响应）。这很奇怪，因为在我看来，RP1 永远不应期待此响应消息，并且有发送端口（SP2、SP3）订阅了响应消息类型。
另一点我忘了说，像 RP1 一样有 3 个接收端口，每个接收端口有 3 个接收位置和 3 个发送端口订阅它们各自的接收端口。
BizTalk Server 安装在共享 1 个的 2 台物理服务器上BizTalkMgmtDb/Messagebox
在此之前，我们有相同数量的消息馈送，但它被合并（在发送端）到一个接收位置。旧的解决方案有多个 Orchestrations，但从未遇到过这个问题。
那么为什么现在 WCF (HL7v3) 响应消息丢失并在 RP1 (HL7v2) 实例下被挂起？
这是它的外观的基本图片。
MLLP Receive Adapter Processing
Acknowledgments with the two-way MLLP receive adapter
When a two-way MLLP receive adapter receives a message, Microsoft BizTalk Accelerator for HL7 (BTAHL7) can generate the following types of ACKs:
HL7 Enhanced Commit ACK: In this scenario, BTAHL7 sends a Commit ACK on the same connection. It sends out an Application Accept ACK on a different send port.
Application Accept ACK: In this scenario, BTAHL7 sends an Application Accept ACK on the same connection.
Static ACK: In this scenario, BTAHL7 sends an ACK on the same connection.
The type of ACK generated depends on the BTAHL7 Configuration Explorer settings for the party sending the message. The value in fields MSH 15 and 16 of an individual message can override this setting. However, for applications expecting Static ACKs, the configuration can only be set through BTAHL7 Configuration Explorer.
根据阅读，我认为您需要将适配器配置为 HL7 增强提交 ACK
我能够通过更改 WCF 双重响应消息的上下文属性中 RouteDirectToTP 值的值来解决此问题。根据这些帖子中的信息：
https://jeremiedevillard.wordpress.com/2010/01/11/how-work-request-response-pattern-part-3/
https://bveldhoen.wordpress.com/2010/09/05/messaging-only-request-response-correlation/
显然，默认情况下，BizTalk 会尝试将 ACK 路由回原始接收端口。我刚刚在我的管道组件中做了这个：
msgReceived.Context.Promote("RouteDirectToTP", "http://schemas.microsoft.com/BizTalk/2003/system-properties", false);
至此问题已经解决。没有更多的僵尸，也没有更多关于存储过程失败的错误。