1

信息：

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

问题：

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

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

一个肯定的ACK就足够了。

谢谢。

4

3 回答 3

1

回答您的具体问题：

HL7 ack 是 HL7 反汇编程序的特定功能。您必须创建自己的自定义 Disassembler 组件，在内部运行 ffdasm，并生成自己的 ack 来模拟 HL7 Disassembler 的行为。

不，我不知道有什么方法可以阻止 HL7 反汇编程序创建多部分消息。您可以轻松地重新组合在 Orchestration 中执行的 Map 中的段。

于 2013-12-03T15:41:46.847 回答
1

正如@boatseller 所说，您无法阻止 HL7 Disassembler 创建多部分消息。

对于您的另一个问题：您可以创建一个自定义管道组件来发送回 HL7 确认，然后只需使用您自己的平面文件模式（使用开箱即用的平面文件反汇编器管道组件）。

1. 使用双向接收端口。

这应该使用双向端口，即使使用 MLLP 适配器，但您需要验证和测试所有内容，并了解 Microsoft 可能支持也可能不支持在没有 HL7 2.X 反汇编程序管道的情况下使用 MLLP 适配器或在下面建议的方式。

2. 关联请求和响应。

您需要在接收位置的管道中使用自定义管道组件，以使 BizTalk 为响应创建订阅。使用管道组件向导开始创建组件。

在自定义管道组件类的Execute 方法中（通过实现IComponent 接口获得），编写类似于以下代码的内容。

public Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(Microsoft.BizTalk.Component.Interop.IPipelineContext pc, Microsoft.BizTalk.Message.Interop.IBaseMessage inmsg)
{
    const string sysPropertyNamespace = "http://schemas.microsoft.com/BizTalk/2003/system-properties";
    var epmToken = inmsg.Context.Read("EpmRRCorrelationToken", sysPropertyNamespace);
    var correlationToken = epmToken != null
                                    ? (string) epmToken
                                    : Guid.NewGuid().ToString();
    inmsg.Context.Promote("EpmRRCorrelationToken", sysPropertyNamespace, correlationToken);
    inmsg.Context.Promote("RouteDirectToTP", sysPropertyNamespace, true);
    return inmsg;
}

此 MSDN 博客文章中记录了在没有编排的情况下进行请求-响应消息处理的使用或EpmRRCorrelationToken和属性。RouteDirectToTP

3. 创建并发送确认

您可以在发送管道中使用另一个自定义管道组件来根据输入消息手动创建确认，可能还需要在运行时读取一些额外的管道组件配置。

与第一个自定义管道组件一样，您可以实现 IComponent 接口的 Execute 方法。像这样的代码应该可以工作：

public Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(Microsoft.BizTalk.Component.Interop.IPipelineContext pc, Microsoft.BizTalk.Message.Interop.IBaseMessage inmsg)
{
    string msgOut;
    var bodyPart = inmsg.BodyPart;
    if (bodyPart == null) 
        return inmsg; // Maybe throw an exception instead?
    var inboundStream = new ReadOnlySeekableStream(bodyPart.GetOriginalDataStream());
    inboundStream.Position = 0;

    using (var reader = new StreamReader(inboundStream))
    {
        var builder = new StringBuilder();
        // Read the input stream's first line - this should be the MSH segment:
        var firstLine = reader.ReadLine();
        // TODO: read search/replacement values from pipeline configuration
        // TODO: make a better ACK header than this
        builder.AppendLine(firstLine.Replace("ADT^A01", "ACK")); 
        // Construct your acknowledgement segment, preferably without hardcoding it here:
        builder.AppendLine("MSA|AA|ADT^A01");
        msgOut = builder.ToString();
    }

    // Write out the output
    var outputStream = new VirtualStream();
    var writer = new StreamWriter(outputStream, Encoding.Default);
    writer.Write(msgOut);
    writer.Flush();
    outputStream.Seek(0, SeekOrigin.Begin);

    inmsg.BodyPart.Data = outputStream;

    pc.ResourceTracker.AddResource(inboundStream);
    pc.ResourceTracker.AddResource(outputStream);

    return inmsg;
}

除了处理内联 TODO 和添加更多空值检查之外，这应该是一个相当完整的解决方案，尽管您的里程可能会有所不同，尤其是在返回有效的 HL7 确认消息时。

奖金。为什么不使用编排？

这是在对该问题的评论中提出的，以下是使用自定义管道组件而不是编排的几个原因：

  1. 编排很慢。Microsoft 在他们自己的Optimizing Orchestration Performance文章中说，您应该尽可能避免使用编排。业务流程会增加延迟和响应时间，因为它们需要额外往返 BizTalk MessageBox 数据库，并且在 BizTalk 服务器上启动额外的进程和线程。
  2. 确认返回更快。HL7 集成通常使用接受/收据确认。许多系统在最后发送的消息被确认之前不会发送额外的消息。因此，如果您必须等待编排启动、读取输入、构造 ACK 输出、将 ACK 返回到端口，然后将 ACK 发送回，您将大大减慢处理速度。是的，这类似于上面的#1，但理解这一点很重要。
  3. 编排使您的解决方案更容易失败。编排是另一个失败点。如果您必须使产生 ACK 的编排或其关联 的主机实例脱机，那么您将失去接收消息的能力。BizTalk 的一大好处是它能够隔离集成解决方案的不同部分，从而实现高可用性和更高的可靠性。当您的解耦接收端口的管道组件在简单地将入站消息发布到 BizTalk 消息框后返回确认时，即使您的内部系统/组件关闭，您也可以继续接收消息。
于 2013-12-16T21:10:13.970 回答
0

这里有几件事。

第 1 点 - 根据我的经验，HL7 的编排只应在极端情况下使用。我们的实现只有少数需要从单个入站消息中分离出多个消息。仅消息传递方法最适合 HL7。它们成本高昂且速度慢，并且与所说的相呼应，增加了额外的故障点。

第 2 点 - 所说的点点滴滴都是真实的，至少我是如何做到的。你可以绕过 DASM 的某些方面，我也这样做，因为它绝对不是完美的。所以我会包装它并包含您的自定义功能。DASM 向消息传递引擎返回一个队列，其中包括反汇编的消息和一个 ack，您可以处理 ACK 并将您自己的“静态”ack 加入队列。

DASM 以 xml 格式创建 ACK 并将其排队，以便发送管道上的 ASM 可以将其组合回原始 HL7 格式以及其他一些内容。因此，您可以在自定义管道组件中执行相同的操作，也可以找到一种方法来调用 DASM 中创建 ACK 的那些私有方法并让它为您完成这一切。

于 2015-12-31T19:22:03.120 回答