消息响应发生错误代码为0xC0C01B4C和0xc0c016b5的僵尸 [英] Message Response Zombies occurring with errors Codes 0xC0C01B4C and 0xc0c016b5 no Orchestration

问题描述

请考虑BizTalk中的以下消息流.

Consider the following message flow in BizTalk.

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

We have several MLLP receive ports/locations setup receiving HL7v2 messages in one application. These ports each receive slightly different message types.

我们称它为RP1

在另一个应用程序中，我们有发送端口，它们分别预订每个接收端口.每个发送端口都有一个出站映射，可以转换HL7v3中的消息并将其提交给WCF(请求/响应)服务.

In another application we have send ports that subscribe to each respective receive port. These send ports each have an outbound map that transforms the messages in HL7v3 and submits it to a WCF (request/response) service.

我们将此称为SP1

然后，WCF服务处理并验证HL7v3，并发送回HL7v3 ack消息. SP1发送端口具有自定义的发送和接收管道组件. (来自WCF响应的)接收仅接收消息并提升某些字段，这些字段将在以后用于订阅.

The WCF service then processes and validates the HL7v3 and sends back an HL7v3 ack message. The SP1 send port has custom send and receive pipeline components. The receive (from the WCF response) just takes the message and promotes certain fields which will be used later for subscriptions.

然后有另外两个发送端口.订阅肯定的ACK的SP2.基于上面提到的字段，将SP3改为负面.正确认已被消耗掉，负确认已通过电子邮件发送给支持人员.

There are then two more Send ports. SP2 that subscribes to positive ACKs. SP3 to the Negative based on the fields promoted above. The positive ACKs are just consumed and the negative ACKs are emailed off to support staff.

问题在于，在大约10％的消息中，我们看到这2条错误消息中有1条弹出:

The issue is that in about 10% of messages we are seeing 1 of these 2 error messages popping up:

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)."

通常在组查看器中后跟一个已暂停的服务实例:

Usually followed by a suspended service instance in the Group viewer:

 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).

The Service Name of the suspended instance is that of RP1. The Message type of the non-consumed message is that of the ACK from SP1 (so it's the WCF response). This is weird because in my mind RP1 should never be expecting this response message AND there are send ports (SP2, SP3) subscribed to the response message types.

我要忘记的另一点是，有3个接收端口，例如RP1，每个都有3个接收位置和3个发送端口，分别订阅了各自的接收端口.

The other point I forgot to make is, there are 3 Receive Ports like RP1, each with 3 Receive Locations and 3 Send Ports subscribing to their respective Receive Ports.

BizTalk Server安装在共享1个BizTalkMgmtDb/Messagebox的2台物理服务器上

The BizTalk Server is installed across 2 physical servers sharing 1 BizTalkMgmtDb/Messagebox

在此之前，我们输入了相同数量的消息，但是将其合并(在发送端)到一个接收位置.旧的解决方案具有多个业务流程，但从未遇到过此问题.

Previous to this we had the same number of messages feeding in, but it was consolidated (at the sending end) to one single Receive Location. The old solution had multiple Orchestrations, but never experienced this issue.

那么，为什么现在WCF(HL7v3)响应消息丢失并在RP1(HL7v2)实例下挂起?

这是它的基本图像.

推荐答案

我能够通过更改WCF两响应消息的上下文属性中的RouteDirectToTP值来解决此问题.根据这些帖子中的信息:

I was able to fix this by changing the value of the RouteDirectToTP value in the Context Properties of the WCF two-response message. Based on information in these posts:

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路由回默认的原始接收端口.我只是在管道组件中做到了这一点:

Apparently by default, BizTalk tries to route an ACK back to the original receive port by default. I just did this in my pipeline component:

 msgReceived.Context.Promote("RouteDirectToTP", "http://schemas.microsoft.com/BizTalk/2003/system-properties", false);

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

and so far the problem has stopped. No more Zombies and no more errors regarding the stored procedure failing.

这篇关于消息响应发生错误代码为0xC0C01B4C和0xc0c016b5的僵尸的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！