问题标签 [btahl7]

我最近在我的开发机器上安装了 BizTalk 2013 HL7 适配器​​。在安装过程中，它会询问我提供并成功添加的日志帐户，并且安装顺利完成。

但是，当我尝试将消息提交到配置为使用 HL7 管道的接收端口时，我总是收到相同的错误

首先有一个“信息”事件日志说明：

用户“ my-BizTalk-HOST-account ”登录失败。原因：无法打开明确指定的数据库。[客户：1.2.3.4]

然后紧接着有：

执行接收管道失败：“BTAHL72XPipelines.BTAHL72XReceivePipeline, BTAHL72XPipelines, Version=1.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” 来源：“BTAHL7 2.X Disassembler” 接收端口：“my-receive-port-name " URI: "0.0.0.0:11001" 原因：无法配置日志存储。

如果我查看事件中的详细信息选项卡，它会显示在以字节为单位的二进制数据中，即我的服务器名称，后跟 master。

需要考虑的几点：

• 我们没有在 HL7 配置工具中启用 SQL Server 日志记录（只是事件日志）
• my-BizTalk-HOST-account无论如何都不是为 HL7 日志记录配置的帐户，那么为什么要使用它呢？
• 我不确定它为什么要访问主数据库（如果这确实是事件日志告诉我的）
• my-BizTalk-HOST-account的SQL 登录名/用户在具有适当权限的 BizTalk 数据库中设置
• 发送到任何其他接收位置都很好，只是那些使用 BTAHL72xReceivePipeline

任何人都可以解释这个或有一个修复？

我有一个 BizTalk 应用程序，它设置为在 MLLP 接收位置接收 HL7v2 消息。

我已经设置各方以便基于发送应用程序 (MSH.3) 进行解析，并将我们的本地模式应用于传入消息类型，即 ORU_R03_23_GLO_DEF。

因此，该党应该将架构从

至

但是，每当消息到达端口时，似乎该方没有得到解决，因为我们收到了这样的错误

其次是另一个错误：

消息引擎无法处理适配器提交的消息：MLLP Source URL:0.0.0.0:11001。详细信息：无法路由已发布的消息，因为找不到订阅者。如果尚未征用订阅编排或发送端口，或者未提升订阅评估所需的某些消息属性，则会发生此错误。请使用 Biztalk 管理控制台解决此故障。

第二个错误是基于第一个错误，因为不，没有订阅的端口来查找类型的消息http://microsoft.com/HealthCare/HL7/2X#ORU_R03_23_GLO_DEF

有订阅的端口http://mynamespace/HL7/2X#ORU_R03_23_GLO_DEF

有没有办法确定党是否真的在阅读传入的消息？

有没有人在 BizTalk 聚会上遇到过这种情况？如果是这样，它是如何解决的？

在开发机器上，我们将 BizTalk 2010 服务器升级到 BizTalk 2013。我们正在将 HL72 消息从另一台机器发送到这台机器，并收到未找到架构的错误：

备用错误号：301 备用错误说明：未找到架构http://microsoft.com/HealthCare/HL7/2X#ORU_R01_23_GLO_DEF备用编码系统：HL7-BTA

该消息将“LAB”指定为发送应用程序，并且我们有一个名为“LAB”的方将“”指定http://mycompany/myapplication/HL7/2X/2.3/ORU/v1为模式命名空间，因此我们无法弄清楚它为什么要在默认的微软命名空间中寻找 ORU R01 2.3 模式.

我们的消息如下所示：

有人有我们应该尝试的想法吗？

我有一个现有的 .NET 应用程序，它生成一个 CCR 消息，该消息验证 CCR 模式。而是创建一个新的应用程序来生成 CCD，我想使用 XSLT 从我的 CCR 模式映射到我的 CCD 模式。

我正在使用 BizTalk 2010 生成 CCR 消息。

有没有人有为地图创建 XSLT 的经验和成功？

我正在构建一个 BizTalk 2010 解决方案，我们通过 MLLP 请求/响应接收端口接收 HL7v2 QRY 消息。编排直接绑定到接收端口，使用自定义 ACK 进行 Web 服务调用和响应。

编排正在执行并进行 Web 服务调用并正确构建 ACK。当发送形状将自定义 ACK 返回到接收端口响应时，我看到一条挂起（不可恢复）的消息，其中显示以下错误：

执行响应（发送）管道失败：“BTAHL72XPipelines.BTAHL72XSendPipeline，BTAHL72XPipelines，版本=1.3.0.0，文化=中性，PublicKeyToken=31bf3856ad364e35”来源：“BTAHL7 2.X 汇编程序”接收端口：“RP.MyPort” URI：“0.0.0.0:1235” 原因：消息不包含名称为 MSHSegment 的部分

如果我查看服务详细信息对话框中的消息选项卡，我会看到两条消息，均类型为 ACK_24_GLO_DEF。

第一条消息包含一个称为“部分”的部分：

第二条消息有 3 个部分（MSHSegment、BodySegments 和 ZSegments）：

因为我可以看到 ACK 中的 3 个部分，所以我怀疑该错误实际上是次要错误，它与第一条消息中的“发现尾随分隔符”有关。我在想 MLLP 管道正在尝试使用第一条消息......如果是这种情况，我该如何允许尾随分隔符？通常我会在一个聚会中设置它并将其与发送端口相关联，但我在这里不处理发送端口。我的接收端口的一方确实允许尾随分隔符。

信息：

传入消息的类型为 HL7。我在接收管道中使用“Flafile-Disassembler”而不是“BTAHL7 2.x Disassembler”管道组件，因为 HL7-Schema 进行了一些修改，并且 BTAHl7 反汇编器拆分了消息（多部分消息），我们不想；而且我们不想使用编排。

问题：

如何在 BizTalk 2010 的接收管道中创建确认，而不使用“BTAHL7 反汇编程序”（不拆分 --> 多部分消息方法）？

或者，可以防止在 BTAHL7 Disassembler 管道组件中拆分消息？

一个肯定的ACK就足够了。

谢谢。

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

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

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

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

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

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

我对处理 HL7 非常陌生，我的公司最近开始了一个非常大的项目，我们将在其中接收 HL7 v2.4 规范中的各种 ADT 消息。我们已经在这里广泛使用了 BizTalk，并且计划利用 BizTalk 2010 的 BTAHL7 加速器来接受这些消息。

我的问题是，我们从贸易​​伙伴收到的 ADT 消息与我们收到的几乎所有消息的 HL7 v2.4 规范都不匹配（即使 MSH 段适用于 V2.4 并且他们已经告知我们是他们将发送文件的版本）。

例如，他们向我们发送 A04 消息，并且在 PV1-3 字段中，规范要求 9 个子组件（由标准 ^ 分隔符分隔）。他们在该字段中发送的是 11 个子组件。

示例：F1^F2^F3^F4^F5^F6^F7^F8^F9^F10^F11 代替这个（这将符合规范）：F1^F2^F3^F4^F5^F6^F7^F8^ F9

PV1-42 字段也会发生这种情况。

在搜索互联网后，我找不到任何帮助使用加速器在 BizTalk 中处理这种情况。在我看来，人们可以自定义消息中的数据，这种情况经常发生（例如发送规范要求 int 的字符串），但在处理 HL7 和 BizTalk 时无法更改实际布局（我在上面列出的情况） . 即使我没有设置 BizTalk 来验证正文段或自定义数据类型，这些消息也会失败（这对我来说很有意义并且是意料之中的，因为它们没有发送仍然符合规范布局的奇怪数据，但是而是完全不同的布局）。

我的问题是这个。有没有办法利用加速器功能来处理这个问题，而不必在将文件发送到加速器管道之前编写自定义代码来“修复”文件？据我们的贸易伙伴称，这正是他们的产品 (Cloverleaf) 发送数据的方式，并且他们已经在使用这种格式与其他各种贸易伙伴合作。

我们最近在开发环境中安装了 BizTalk Server 2010 CU 6 进行测试。

安装后，当通过 MLLP 适配器将 HL7 消息提交到使用 BTAHL7ReceivePipeline 接收管道和 BTAHL7SendPipeline 发送管道的请求响应接收位置时，会生成以下错误。

这些管道在 BTAHL7 中提供，尚未定制。我们在具有当前状态 BizTalk Server 2010 CU5 和 BizTalk Adapter Pack 2010 CU2 的环境中应用了更新，并与 BizTalk Server 2010 CU5、BizTalk Adapter Pack 2010 CU3 和 BTAHL7 加速器修补程序 2564013、2607536、2702143、2713884、2732905、 2758524。

在这两种情况下，都遇到了同样的错误，Windows 更新截至 2014 年 10 月 25 日是最新的。还有其他人遇到过这个问题吗？

- - 编辑 - -

这最终成为 Microsoft 的 Biztalk CU 6 中的一个错误。我们能够使用所有基本信息复制它，并创建了一个新的 CU 来解决这个问题。

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

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

我们称它为 RP1

在另一个应用程序中，我们有订阅每个相应接收端口的发送端口。这些发送端口每个都有一个出站映射，用于转换 HL7v3 中的消息并将其提交给 WCF（请求/响应）服务。

我们称之为 SP1

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

然后还有两个发送端口。订阅肯定 ACK 的 SP2。SP3 到基于上面提到的领域的否定。正面的 ACK 会被消耗掉，而负面的 ACK 会通过电子邮件发送给支持人员。

问题是，在大约 10% 的消息中，我们看到以下 2 条错误消息中的 1 条弹出：

通常在 Group 查看器中跟随一个暂停的服务实例：

被挂起的实例的Service Name 是RP1 的。未消费消息的消息类型是来自 SP1 的 ACK（因此它是 WCF 响应）。这很奇怪，因为在我看来 RP1 永远不应该期待这个响应消息，并且有发送端口（SP2、SP3）订阅了响应消息类型。

我忘了说的另一点是，有 3 个接收端口，如 RP1，每个端口都有 3 个接收位置和 3 个发送端口订阅各自的接收端口。

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

在此之前，我们输入了相同数量的消息，但它被合并（在发送端）到一个接收位置。旧的解决方案有多个编排，但从未遇到过这个问题。

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

这是它的外观的基本图像。