0

在我的场景中，客户端通过 MLLP 将 HL7 发送到我的 BizTalk 双向接收端口。BizTalk 对外部服务进行 Web 服务调用，接收响应，将其转换为 HL7 ACK 并将其返回给客户端，所有这些都在同步事务中进行。

为了实现这一点，我有一个直接绑定到消息框的编排，并且 BTAHL7 方配置设置为不将 ACK 路由到请求-响应接收端口上的发送管道。基本上我会关闭默认的 ACK 生成并从我的编排中生成自定义 ACK。我还在我的业务流程接收形状 BTAHL7Schemas.ParseError == false 中添加了一个额外的过滤器，以便业务流程不会收到错误消息，以防收到的消息与架构不匹配。

一切都很好。在我的测试中，我故意发送错误的 HL7 消息。在这种情况下，我收到一个挂起的路由错误报告，因为没有找到订阅者。

这种行为的原因很清楚——我没有订阅有解析错误的消息。如果出现解析错误，我希望错误 ACK 回到客户端。我可以允许我的编排订阅带有解析错误的消息，并且只是制定一个错误 ACK，但我没有任何方法可以在 ACK 中返回实际的解析错误。

通常，在异步架构中，我会打开“路由 ACK 以在请求-响应接收端口上发送管道”并让 BTAHL72X 接收/发送管道处理它。然后客户端将收到包含错误详细信息的错误 ACK。

所以我的问题是，有没有办法让接收管道原始 ACK 并从我的编排中返回它？

4

1 回答 1

1

是的，你想要的肯定是可行的。我现在没有 HL7 项目，所以我的记忆可能不准确，但类似于：

  1. 取消选中“重新路由 ACK 以发送管道...”
  2. 您将需要一个自定义管道组件来提升反汇编程序输出上的 BTS.InterchangeID。
  3. 在您的编排中，实现与 BTS.InterchageID 相关的 Convoy。
  4. 然后，Orchestration 将获取 HL7 消息和自动生成的 ACK。
  5. 你正常处理吗。
  6. 决定返回哪个 ACK​​，你的还是生成的。
  7. 将 ACK 返回到 TwoWay 端口。

*非定制管道解决方案：*

在 BTAHL7 配置浏览器确认选项卡中：

  1. 将确认类型设置为增强
  2. 将MSH15（接受确认类型）设置为NE。
  3. 将 MSH16（应用程序确认类型设置为 ER
  4. 打开 Route ACK 以在 request-response 上发送管道，

它似乎得到了我想要的行为。管道不会生成成功 ACK，让我的编排处理它，但会生成应用程序 ACK 错误（AR - 应用程序拒绝），并路由到发送管道。

于 2013-12-18T14:27:39.007 回答