BizTalk 2010 -创建确认

Question

信息：

incomming消息的类型为HL7。我在接收管道中使用的是“Flafile-反汇编器”，而不是"BTAHL7 2.x反汇编程序“管道组件，因为HL7-Schema有一点修改，BTAHl7反汇编程序拆分了消息(多部分消息)，我们不想使用编排。

问题：

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

或者，是否可以防止在BTAHL7反汇编程序管道组件中拆分消息？

一个积极的ACK就足够了。

谢谢。

Answer 1

正如@boatseller所说，您不能阻止HL7反汇编程序创建多部分消息。

对于另一个问题:您可以创建一个自定义管道组件来发送HL7确认，然后只使用您自己的平面文件模式(带有开箱即用的平面文件反汇编程序管道组件)。

1.使用双向接收端口。

这应该使用双向端口，即使是使用MLLP适配器，但您需要验证和测试所有内容，并理解微软可能支持也可能不支持使用HL7 2.X反汇编程序管道或使用BizTalk的方式。

2.将请求与答复联系起来。

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

在定制管道组件类的执行方法中(您从实现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;
}

在没有编排的情况下，用于请求响应消息处理的EpmRRCorrelationToken和RouteDirectToTP属性记录在这篇MSDN博客文章中。

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;
}

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

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

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

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

Answer 2

要回答你的具体问题：

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

不，我不知道如何阻止HL7反汇编程序创建多部分消息。您可以轻松地重新组合在业务流程中执行的Map中的段。

Answer 3

这里有几件事。

第一，在我的经验中，HL7的编排只能在极端情况下使用。我们的实现只有少数需要从单个入站消息中派生出多条消息的地方。仅消息传递方法最适合于HL7。他们是昂贵和缓慢的，并呼应说，增加一个额外的失败点。

第二，人们所说的一切都是真的，至少我是如何做到的。您可以绕过DASM的某些方面，我可以这样做，因为它绝对不是完美的。所以我会包装它并包括您的自定义功能。DASM将一个队列返回给消息传递引擎，其中包括已分解的消息和一个ack，您可以释放ack并对自己的“静态”ACK进行排队。

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