BizTalk Ack传播

Question

我有一个BizTalk接口接收HL7消息并将消息传递给客户机的服务器。对于这个界面，我有一个双向的RP和一个请求响应SP。当前的行为是双向RP会在接收到消息时生成ACK。然后SP将向客户端发送消息，客户端将使用ACK进行响应。当SP接收到ack时，SP将使用客户机服务器发送的ACK。我的问题是如何配置Biztalk，使来自SP的ACK被传播到RP，并在相同的RP套接字中返回到源？我试图避免编排，所以这必须是一个自定义管道组件吗？

谢谢!

Answer 1

所以，经过大量的研究和跟踪和错误。事实证明，这是BizTalk 2013 R2中的一个本机特性。它之前没有工作的原因是因为RP正在收集RP接收管道中生成的ACK，具体而言是反汇编程序生成的ACK。因此，当客户端的ACK返回时，它没有去处，在RP中被挂起。这可以通过创建一个当事方并将Ack设置为None并选中ack路由来解决。

​

由于执行方面的限制，我无法创建一个缔约方来利用上述方法。我不得不为RP的接收管道编写自定义管道组件，以从反汇编程序中抑制ACK。这也同样有效。

Answer 2

您可以通过在确认选项卡上使用HL7派对并将确认类型配置为“None”来实现您的方法。这将使HL7反汇编程序在接收消息时不生成确认。在发送端，一旦您从接收系统接收到确认，请确保您具有与原始消息上下文中相同的EpmRRCorrelationToken上下文属性。您可能需要在发送端口(接收端)上使用自定义管道组件在ACK消息上写入此上下文属性。这将允许ACK消息转到RCV端口。我以前从来没有这样做过，但应该会成功的。

从设计的角度来看，这不是一个好主意，因为消息发送系统将等待确认，直到BizTalk能够成功地发送消息并从消息接收系统接收确认。您需要考虑的情况是，您的接收系统有问题，无法使用消息或有计划的停机时间。大多数情况下，发送系统都设置了确认超时，如果在该时间框架内没有收到确认，则会重试，这会产生重复的消息问题。

Answer 3

首先，使用编排没有什么问题。不要担心“性能”。

因此，正确的BizTalk方法是使用业务流程管理与下游系统的同步。