在biztalk中请求响应问题 [英] Request response issues in biztalk

问题描述

在我们的一种解决方案(纯消息传递，无业务流程)中，我们使用MLLP适配器和HL7v2x管道在请求响应接收位置接收到一条消息.接收管道生成响应消息并将其发布，由于提升的属性，该消息通过请求/响应接收端口的发送管道路由到客户端.

然后，我们有一个双向发送端口，用于订阅接收到的消息，使用映射来转换消息，然后将发送到请求响应的WCF接收端口也位于同一BizTalk机器上.听起来很奇怪，但是我们有一些客户端通过Web服务发送其数据，有些通过HL7v2 MLLP发送，因此这就是我们这样做的原因.

WCF请求响应接收端口还通过发布消息并升级EpmRRCorrelationToken，CorrelationToken，ReqRespTransmitPipelineID，RouteDirectToTP，IsRequestResponse和ReceivePipelineResponseConfig属性来生成响应，该属性使响应作为SOAP响应通过发送管道进行路由./p>

我们订阅在WCF请求响应端口上收到的消息，并将其拖放到文件中.

从技术上讲，它可以正常工作.使用MLLP的客户端将收到确认响应.使用WCF SOAP Web服务的客户端将获得SOAP响应.文件系统包含所有已发送的消息.

因此，如果我考虑发布的消息，我想是通过MLLP收到了HL7v2消息(A)，而通过HL7v2响应收到了(B).然后，WCF接收到的已转换消息将接收端口(C)，并且它是响应(D).加上所附的.中显示的是WCF发送端口(E)接收到的WCF响应./p>

问题在于，由于消息传递引擎无法将响应与现有请求消息相关联，因此我们在BizTalk中获得了挂起消息，例如双向接收端口"xxx"的响应消息被挂起".当主机进程被回收时，就会发生这种情况."在这种情况下，该服务是MLLP接收端口，并且有3个挂起消息-HL7v2 ACK(B)，以及我怀疑的WCF服务(D)和(E)的响应消息的2个副本.

我们还看到了错误消息:该实例已完成，但不占用其所有消息.该实例及其未使用的消息已被挂起."

解决方案

使用MLLP适配器接收MLLP可能超时.您可以看的东西很少:

• 持久连接"属性应设置为"True"且接收超时"设置为0
• 由于您正在为通过MLLP发出的已发布的HL7消息调用WCF服务，所以我想知道您是否正在处理WCF服务响应.否则，将导致这些错误消息.您需要订阅服务响应或使用单向发送端口.
• 当通过MLLP接收到将消息发送到FILE位置的消息时，请考虑您的设计和调用本地WCF服务的需求.您可以直接跳过两者之间的所有WCF路由.

In one of our solutions (pure messaging, no orchestrations), we receive a message on a request response receive location, using the MLLP adaptor and HL7v2x pipelines. The receive pipeline generates the response message and publishes it, which due to promoted properties gets routed through the send pipeline of the request/response receive port, back to the client.

We then have a two way send port that subscribes to the received message, uses a map to translate the message and send to a request response WCF receive port that is also on the same BizTalk machine. It sounds odd but we have clients that send their data via web services, and some that send via HL7v2 MLLP so that's why we're doing it this way.

The WCF request response receive port also generates a response by publishing a message and promoting the EpmRRCorrelationToken, CorrelationToken, ReqRespTransmitPipelineID, RouteDirectToTP, IsRequestResponse and ReceivePipelineResponseConfig properties, which causes the response to get routed through the send pipeline as a SOAP response.

We subscribe to the messages received on the WCF request response port, and drop them to a file.

Technically it works. The client using MLLP gets an acknowledgement response. The client using WCF SOAP web services get a SOAP response. The file system contains all messages that were sent.

So if I think about the messages published I imagine there is the HL7v2 message received over MLLP (A), and the HL7v2 response (B). Then the translated messages received by the WCF receive port (C), and it's response (D). Plus the WCF response that was received by the WCF send port (E), as shown in the attached .

The problem is that we're getting suspended messages in BizTalk such as "A response message for two-way receive port "xxx" 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." In this case, the service is the MLLP receive port, and there are 3 suspended messages - the HL7v2 ACK (B), and 2 copies of the response message for the WCF service (D) and (E) I suspect.

We're also seeing errors "The instance completed without consuming all of its messages. The instance and its unconsumed messages have been suspended."

解决方案

With MLLP adapter Its possible that the Receive MLLP is timing out. There are few things you can look at:

• The Persistent Connection Property should be set to True with Receive Timeout Set to 0
• Since you are calling a WCF service for published HL7 message which come via MLLP, I am wondering if you are dealing with WCF service response. If not then it will cause these error messages. You need to subscribe to the service response or use a one way send port.
• Relook at your design and need of calling a local WCF service when a message is received via MLLP to send the message to a FILE location. You can do this directly skipping all the WCF route in between.

这篇关于在biztalk中请求响应问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！