biztalk中的请求响应问题

Question

在我们的解决方案中(纯消息传递，没有编排)，我们使用MLLP适配器和HL7v2x管道在请求响应接收位置接收消息。接收管道生成并发布响应消息，由于提升的属性，响应消息将通过请求/响应接收端口的发送管道路由到客户端。

然后，我们有一个双向发送端口，它订阅接收到的消息，使用一个映射来翻译消息，并发送到同一个BizTalk机器上的请求响应WCF接收端口。这听起来很奇怪，但是我们有通过web服务发送数据的客户端，也有通过HL7v2 MLLP发送数据的客户端，这就是为什么我们要这样做的原因。

WCF请求响应接收端口还通过发布消息并提升EpmRRCorrelationToken、CorrelationToken、ReqRespTransmitPipelineID、RouteDirectToTP、IsRequestResponse和ReceivePipelineResponseConfig属性来生成响应，这将导致响应作为SOAP响应通过发送管道路由。

我们订阅在WCF请求响应端口上收到的消息，并将它们放到一个文件中。

从技术上讲是可行的。使用MLLP的客户端获得一个确认响应。使用WCF SOAP服务的客户端获得SOAP响应。文件系统包含已发送的所有消息。

因此，如果我想到发布的消息，我就会想到通过MLLP (A)接收到的HL7v2消息，以及HL7v2响应(B)。然后，WCF接收端口(C)接收到的被翻译的消息，以及它的响应(D)。加上WCF发送端口(E)接收到的WCF响应，如附件所示

。

问题是，我们在BizTalk中得到了挂起的消息，例如“双向接收端口的响应消息”"xxx“被挂起，因为消息传递引擎无法将响应与现有的请求消息关联起来。这通常发生在主机进程已被回收时。在这种情况下，服务是MLLP接收端口，有3条挂起的消息-- HL7v2 ACK (B)，以及WCF服务(D)和(E)响应消息的两个副本。

我们还看到错误“在没有使用其所有消息的情况下完成了实例，该实例及其未使用的消息已被挂起。”

Answer 1

有了MLLP适配器，接收MLLP就有可能超时。有几件事你能看得到：

• 持久连接属性应设置为True，接收超时设置为0
• 由于您正在为通过MLLP发布的HL7消息调用WCF服务，所以我想知道您是否正在处理WCF服务响应。否则，它将导致这些错误消息。您需要订阅服务响应或使用单向发送端口。
• 当通过MLLP接收消息以将消息发送到文件位置时，请重新查看您的设计和调用本地WCF服务的需要。您可以直接跳过中间的所有WCF路由。