1

情報：

着信メッセージのタイプは HL7 です。私は受信パイプラインで「BTAHL7 2.x 逆アセンブラー」パイプライン コンポーネントではなく「Flafile-逆アセンブラー」を使用しています。これは、HL7 スキーマが少し変更されており、BTAHl7 逆アセンブラーがメッセージ (マルチパート メッセージ) を分割しているためです。したくない; また、オーケストレーションを使用したくありません。

質問:

「BTAHL7 逆アセンブラー」を使用せずに、BizTalk 2010 の受信パイプラインで受信確認を作成するにはどうすればよいですか (分割 --> マルチパート メッセージ アプローチを使用しません)。

または、BTAHL7 逆アセンブラー パイプライン コンポーネントでメッセージが分割されないようにすることは可能ですか?

肯定的な ACK で十分です。

ありがとう。

4

3 に答える 3

1

特定の質問に答えるには:

HL7 ack は、HL7 逆アセンブラーの特定の機能です。独自のカスタム 逆アセンブラー コンポーネントを作成し、内部で ffdasm を実行し、独自の ack を生成して HL7 逆アセンブラーの動作をシミュレートする必要があります。

いいえ、HL7 逆アセンブラーがマルチパート メッセージを作成しないようにする方法を知りません。オーケストレーションで実行されるマップ内のセグメントを簡単に再結合できます。

于 2013-12-03T15:41:46.847 に答える
1

@boatseller が言うように、HL7 逆アセンブラーがマルチパート メッセージを作成するのを防ぐことはできません。

他の質問について: カスタム パイプライン コンポーネントを作成して HL7 確認応答を送り返し、独自のフラット ファイル スキーマを使用することができます (すぐに使用できるフラットファイル逆アセンブラー パイプライン コンポーネントを使用)。

1. 双方向受信ポートを使用します。

これは、MLLP アダプターを使用した場合でも、双方向ポートを使用して機能するはずですが、すべてを検証およびテストし、Microsoft が HL7 2.X 逆アセンブラー パイプラインを使用せずに MLLP アダプターを使用したり、以下に提案する方法。

2. リクエストとレスポンスを関連付けます。

BizTalk で応答のサブスクリプションを作成するには、受信場所のパイプラインにカスタム パイプライン コンポーネントが必要です。Pipeline Component Wizardを使用して、コンポーネントの作成を開始します。

カスタム パイプライン コンポーネント クラス ( IComponent インターフェイスの実装から取得)のExecute メソッドで、次のコードに似たものを記述します。

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

インライン TODO を処理し、より多くの null チェックを追加すること以外は、かなり完全なソリューションになるはずですが、特に有効な HL7 確認メッセージを返す場合は、マイレージが異なる場合があります。

ボーナス。オーケストレーションを使用しないのはなぜですか?

これは質問へのコメントで尋ねられました。オーケストレーションの代わりにカスタム パイプライン コンポーネントを使用するいくつかの理由を次に示します。

  1. オーケストレーションが遅い。Microsoft は、独自のオーケストレーション パフォーマンスの最適化に関する記事で、可能であればオーケストレーションの使用を避けるべきだと述べています。オーケストレーションでは、BizTalk メッセージ ボックス データベースへの余分なラウンドトリップが必要になり、BizTalk サーバーで追加のプロセスとスレッドが起動されるため、待機時間と応答時間が長くなります。
  2. 確認応答がより速く返されます。HL7 統合では、通常、承認/受信確認を使用します。多くのシステムは、最後に送信されたメッセージが確認されるまで、追加のメッセージを送信しません。したがって、オーケストレーションがスピンアップするまで待機し、入力を読み取り、ACK 出力を作成し、ポートに ACK を返し、ACK を送り返す必要がある場合、処理が大幅に遅くなります。はい、これは上記の #1 と似ていますが、理解することが重要です。
  3. オーケストレーションにより、ソリューションがより失敗しやすくなります。オーケストレーションは、もう 1 つの障害点です。ACK を生成するオーケストレーションまたは関連する ホスト インスタンスをオフラインにする必要がある場合は、メッセージを受信できなくなります。BizTalk の大きな利点は、統合ソリューションのさまざまな部分を分離して、高可用性と信頼性の向上を実現できることです。分離された受信ポートのパイプライン コンポーネントが受信メッセージを BizTalk メッセージ ボックスに発行しただけで受信確認を返すと、内部システム/コンポーネントがダウンしていても、メッセージの受信を続行できます。
于 2013-12-16T21:10:13.970 に答える
0

ここにいくつかのことがあります。

番号 1 - 私の経験では、HL7 のオーケストレーションは極端な場合にのみ使用する必要があります。私たちの実装には、単一の受信メッセージから複数のメッセージをスピンアウトする必要がある場所がいくつかあります。メッセージングのみのアプローチは、HL7 に最適です。それらは費用がかかり、遅く、言われていることを反映して、追加の障害点を追加します.

番号 2 - 言われていることの断片は、少なくとも私がどのように行うかについて、真実であるべきです。DASM の特定の側面をバイパスすることはできますが、私もそうしています。これは完全ではないからです。だから私はそれをラップして、カスタム機能を含めます。DASM は、逆アセンブルされたメッセージと ACK を含むキューをメッセージング エンジンに返します。ACK を破棄して、独自の「静的」ACK をキューに入れることができます。

DASM は ACK を作成して xml 形式でキューに入れ、送信パイプライン上の ASM がそれを他のものと一緒に生の HL7 形式に組み立てることができるようにします。したがって、カスタム パイプライン コンポーネントで同じことを行うか、または ACK を作成する DASM でプライベート メソッドを呼び出してすべてを実行させる方法を見つけることができます。

于 2015-12-31T19:22:03.120 に答える