BizTalk 2010-创建确认

信息：

输入消息的类型为HL7。我在接收管道中使用的是“Flafile反汇编程序”，而不是“BTAHL7 2.x反汇编程序”管道组件，因为HL7模式有点修改，BTAHL7反汇编程序拆分了消息（多部分消息），我们不需要；我们不想使用编排

问题：

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

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

积极的回应就足够了

---

谢谢。

要回答您的具体问题：

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

---

不，我不知道如何防止HL7反汇编程序创建多部分消息。您可以轻松地重新组合编排中执行的映射中的段。

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

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

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

2.将请求和响应关联起来。 接收位置的管道中需要一个自定义管道组件，以使BizTalk为响应创建订阅。使用以在创建组件时抢先一步

在自定义管道组件类（从实现中获得）中，编写类似于以下代码的代码

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

和

routeddirecttotp

属性

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确认消息时

奖金。为什么不使用编排呢？ 这是在对问题的评论中提出的，以下是使用自定义管道组件而不是编排的几个原因：

编排很慢。微软在他们自己的文章中说，如果可能，应该避免使用编排。业务流程会增加延迟和响应时间，因为它们需要到BizTalk MessageBox数据库的额外往返，并且需要在BizTalk server上启动额外的进程和线程

确认返回得更快。HL7集成通常使用。在确认最后发送的消息之前，许多系统不会发送其他消息。因此，如果您必须等待业务流程启动，读取输入，构造ACK输出，将ACK返回到端口，然后将ACK发送回，那么您将大大降低处理速度。是的，这类似于上面的#1，但理解这一点很重要

编排使您的解决方案更容易失败。编排是另一个失败点。如果您必须使生成ACK的业务流程或其脱机，则您已失去接收消息的能力。BizTalk的一大好处是它能够隔离集成解决方案的不同部分，从而实现高可用性和更高的可靠性。如果在将入站消息发布到BizTalk消息框后，解耦接收端口的管道组件返回确认信息，则即使内部系统/组件关闭，您也可以继续接收消息

这里有几件事

第一，根据我的经验，HL7的编排应该只在极端情况下使用。我们的实现只有少数需要从单个入站消息中提取多条消息的地方。只发送消息的方法最适合HL7。它们代价高昂，速度缓慢，而且与人们所说的话相呼应，增加了一个额外的失败点

第二，所说的每一点都是真实的，至少我是如何做到的。您可以绕过DASM的某些方面，我也可以，因为它绝对不是完美的。因此，我将包装它并包含您的自定义功能。DASM向消息传递引擎返回一个队列，该队列包括已分解的消息和一个ack，您可以处理该ack并将自己的“静态”ack排入队列

---

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

能否详细说明您不想使用编排的原因？这对于我们新的StackExchange it医疗保健网站来说是一个很好的问题：好的建议。你知道一些教程或者知道怎么做吗？我发现：MSDN永远是最重要的