問題タブ [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 逆アセンブラー" 受信ポート: "my-receive-port-name " URI: "0.0.0.0:11001" 理由: ログストアを構成できません。

イベントの詳細タブを見ると、Binary Data in Bytes、サーバーの名前、マスターの順に表示されます。

考慮すべきいくつかの点:

• HL7 構成ツールで SQL Server のログを有効にしていません (イベント ログのみ)。
• my-BizTalk-HOST-accountは HL7 ログ用に構成されたアカウントではありませんが、なぜそれが使用されているのでしょうか?
• マスターデータベースにアクセスしようとしている理由がわかりません（それが実際にイベントログに表示されている場合）
• my-BizTalk-HOST-account のSQL ログイン/ユーザーは、適切な権限を持つ BizTalk データベースでセットアップされます
• 他の受信場所への送信は正常に動作します。BTAHL72xReceivePipeline を使用しているものだけです。

誰かがこれを説明したり、修正したりできますか?

CCR スキーマに対して検証する CCR メッセージを生成する既存の .NET アプリケーションがあります。CCD を生成する新しいアプリケーションを作成するのではなく、XSLT を使用して CCR スキーマから CCD スキーマにマップしたいと考えています。

BizTalk 2010 を使用して CCR メッセージを生成しています。

マップ用の XSLT を作成した経験があり、成功した人はいますか?

MLLP 要求/応答受信ポートを介して HL7v2 QRY メッセージを受信する BizTalk 2010 ソリューションを構築しています。オーケストレーションは受信ポートに直接バインドされ、カスタム ACK で Web サービスの呼び出しと応答を行います。

オーケストレーションが実行され、Web サービス呼び出しが行われ、ACK が正しく構築されています。送信シェイプがカスタム ACK を受信ポートの応答に返すと、中断された (再開できない) メッセージが表示され、次のようなエラーが表示されます。

応答 (送信) パイプラインの実行中にエラーが発生しました: "BTAHL72XPipelines.BTAHL72XSendPipeline, BTAHL72XPipelines, Version=1.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" ソース: "BTAHL7 2.X Assembler" 受信ポート: "RP.MyPort" URI: "0.0.0.0:1235" 理由: メッセージに MSHSegment という名前のパーツが含まれていません

サービスの詳細ダイアログの [メッセージ] タブを見ると、2 つのメッセージがあり、どちらもタイプ ACK_24_GLO_DEF です。

最初のメッセージには、「part」と呼ばれる 1 つの部分が含まれています。

2 番目のメッセージには 3 つの部分 (MSHSegment、BodySegments、および ZSegments) があります。

ACK に 3 つの部分が表示されているため、エラーは実際には、最初のメッセージの「Trailing delimiter found」に関連する二次的なエラーであると思われます。MLLP パイプラインが最初のメッセージを消費しようとしていると思います...その場合、末尾の区切り文字を許可するにはどうすればよいですか? 通常はこれをパーティに設定して送信ポートに関連付けますが、ここでは送信ポートを扱っていません。私の受信ポートのパーティでは、末尾の区切り文字が許可されています。

情報：

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

質問:

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

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

肯定的な 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 での次のメッセージ フローを検討してください。

1 つのアプリケーションで HL7v2 メッセージを受信する複数の MLLP 受信ポート/場所が設定されています。これらのポートはそれぞれ、わずかに異なるメッセージ タイプを受信します。

これをRP1としましょう

別のアプリケーションでは、それぞれの受信ポートにサブスクライブする送信ポートがあります。これらの送信ポートにはそれぞれ、HL7v3 でメッセージを変換し、WCF (要求/応答) サービスに送信するアウトバウンド マップがあります。

これをSP1としましょう

次に、WCF サービスは HL7v3 を処理して検証し、HL7v3 ack メッセージを返します。SP1 送信ポートには、カスタムの送信および受信パイプライン コンポーネントがあります。受信 (WCF 応答から) はメッセージを受け取り、後でサブスクリプションに使用される特定のフィールドを昇格させます。

さらに 2 つの送信ポートがあります。肯定的な ACK にサブスクライブする SP2。上記で促進されたフィールドに基づいて、SP3からネガティブに。肯定的な ACK は消費されるだけで、否定的な ACK はサポート スタッフに電子メールで送信されます。

問題は、メッセージの約 10% で、次の 2 つのエラー メッセージのうちの 1 つが表示されることです。

通常、グループ ビューアで一時停止されたサービス インスタンスが続きます。

中断されたインスタンスのサービス名は RP1 のサービス名です。非消費メッセージのメッセージ タイプは、SP1 からの ACK のメッセージ タイプです (つまり、WCF 応答です)。私の考えでは、RP1 はこの応答メッセージを期待するべきではなく、応答メッセージの種類にサブスクライブされた送信ポート (SP2、SP3) があるため、これは奇妙です。

忘れていたもう 1 つのポイントは、RP1 のような 3 つの受信ポートがあり、それぞれに 3 つの受信場所と 3 つの送信ポートがそれぞれの受信ポートにサブスクライブしていることです。

BizTalk Server は、1 つの BizTalkMgmtDb/Messagebox を共有する 2 つの物理サーバーにインストールされます。

これ以前は、同じ数のメッセージがフィードされていましたが、(送信側で) 1 つの受信場所に統合されていました。古いソリューションには複数のオーケストレーションがありましたが、この問題は発生しませんでした。

では、RP1 (HL7v2) のインスタンスで WCF (HL7v3) 応答メッセージが失われ、中断されているのはなぜでしょうか?

これがどのように見えるかの基本的なイメージです。