消息响应僵尸出现错误代码0xC0C01B4C和0xc0c016b5 no Orchestration

Question

考虑BizTalk中的以下消息流。

我们有几个MLLP接收端口/位置设置在一个应用程序中接收HL7v2消息。这些端口每个接收的消息类型略有不同。

我们称之为RP1

在另一个应用程序中，我们发送了订阅每个相应接收端口的端口。这些发送端口每个都有一个出站映射，用于转换HL7v3中的消息并将其提交给WCF（请求/响应）服务。

我们称之为SP1

然后，WCF服务处理并验证HL7v3并发回HL7v3确认消息。 SP1发送端口具有自定义发送和接收管道组件。接收（来自WCF响应）只接收消息并提升某些字段，稍后将用于订阅。

还有两个发送端口。订阅肯定ACK的SP2。根据上面提到的字段，SP3为负数。只消耗了肯定的ACK，并通过电子邮件将负面的ACK发送给支持人员。

问题是，在大约10％的消息中，我们看到这两条错误消息中有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）订阅了响应消息类型。

我忘了做的另一点是，有3个接收端口，如RP1，每个接收端口有3个接收位置和3个发送端口，用于订阅各自的接收端口。

BizTalk Server安装在共享1个BizTalkMgmtDb / Messagebox

的2个物理服务器上

在此之前，我们有相同数量的消息，但它被合并（在发送端）到一个接收位置。旧解决方案有多个Orchestration，但从未遇到过这个问题。

那么为什么现在WCF（HL7v3）响应消息丢失并在RP1（HL7v2）实例下被暂停？

以下是它的外观基本图像。

Answer 1

我能够通过更改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);

到目前为止，问题已经停止。没有更多的僵尸，也没有关于存储过程失败的错误。

Answer 2

MLLP Receive Adapter Processing

  

使用双向MLLP接收适配器的致谢

     

当双向MLLP接收适配器收到消息时，Microsoft BizTalk Accelerator for HL7（BTAHL7）可以生成以下类型的ACK：

     

  

• HL7增强型提交ACK：在这种情况下，BTAHL7在同一连接上发送提交ACK。它在不同的发送端口上发出应用程序接受ACK。

  

• 应用程序接受ACK：在这种情况下，BTAHL7在同一连接上发送应用程序接受ACK。

  

• 静态ACK：在这种情况下，BTAHL7在同一连接上发送ACK。

  

• 生成的ACK类型取决于发送消息的一方的BTAHL7 Configuration Explorer设置。单个消息的字段MSH 15和16中的值可以覆盖此设置。但是，对于需要静态ACK的应用程序，只能通过BTAHL7 Configuration Explorer设置配置。

  

从阅读中我认为您需要将适配器配置为HL7增强型提交确认