受信した EDI メッセージのアグリーメントの解決、スキーマ探索、および認証
BizTalk Serverが EDI メッセージを受信すると、EDI 受信パイプラインは取引先契約の検索、スキーマ検出、および承認プロセスを実行して、メッセージの処理方法を決定します。
契約解決
EDI 受信パイプラインによって実行される取引先アグリーメント解決とは、メッセージのヘッダー フィールドに一致するプロパティを持つアグリーメント定義を見つけるための一連の手順を実行することです。 BizTalk Server契約が決定されると、インターチェンジに適用されるドキュメント スキーマが決定されます (以下を参照)。 一致するアグリーメントに関連付けられたプロパティおよび関連するスキーマを使用して、受信したメッセージが検証され、処理されます。
契約の解決を行うために、BizTalk Serverは次のように進みます。
アグリーメントを解決するために、インターチェンジ ヘッダーの中の送信者の修飾子と識別子および受信者の修飾子と識別子をアグリーメントのプロパティと照合して、一致するアグリーメントを見つけます。
手順 1. で一致するものが見つからない場合は、インターチェンジ ヘッダーの中の送信者の修飾子と識別子だけをアグリーメントのプロパティと照合して、一致するアグリーメントを見つけます。 また、最初の手順が成功しなかったため、BizTalk Serverがメッセージを受信すると想定しても問題ありません。 そのため、BizTalk Serverは受信側の修飾子と識別子と次の一致を試みます。
値 "BT" および "HostX12Recvr" (X12 でエンコードされたメッセージの場合)
値 "BT" および "HostEdifactRecvr" (EDIFACT でエンコードされたメッセージの場合)
重要
- BizTalk Server 2013 R2、2013、および 2010: ISA5、ISA6、ISA7、ISA8、UNB2.1、UNB2.2、UNB3.1、および UNB3.2 フィールドは、契約設定で必須です。
- BizTalk Server 2009 および 2006 R2: ISA7、ISA8、UNB3.1、UNB3.2 の各フィールドは、パーティ設定では必須ではありません。 これらのフィールドを空白のままにすると、EDI エンジンでは ISA5、ISA6、UNB2.1、UNB2.2 の値に基づいて解決が実行されます。
- BizTalk Server 2009 および BizTalk Server 2006 R2 以降のバージョンによる解決をサポートするために、ハード コードされた ID (HostX12Recvr および HostEdifactRecvr) と修飾子 (BT) が導入されています。
- EDIFACT メッセージは、メッセージの構文と規則に関 する UNECE ガイドライン に従う必要があります。
手順 2. で一致するものが見つからない場合は、フォールバック アグリーメントのプロパティを使用します。
最初の手順では、X12 の場合、BizTalk Serverは次の値を使用して一致させます。
ISA05 (送信者の修飾子)
ISA06 (送信者の識別子)
ISA07 (受信者の修飾子)
ISA08 (受信者の識別子)
EDIFACT の場合、BizTalk Serverは次の値を使用して一致させます。
UNB2.1 (送信者の識別子)
UNB2.2 (送信者の修飾子)
UNB3.1 (受信者の識別子)
UNB3.2 (受信者の修飾子)
一致に使用される契約プロパティは、[契約のプロパティ] ダイアログ ボックスの [方向固有の契約] タブの [識別子] ページで定義されます。
この 4 つの受信側と送信側のプロパティによって、取引先アグリーメントが一意に識別されます。 4 つのプロパティを使用することで、受信側の処理の柔軟性が向上します。 たとえば、このアグリーメント解決方法ならば、受信確認の送信先のパーティが複数の場合も、送信ポートを複数作成する必要はありません。
BizTalk Serverは、4 つの送信者と受信者の修飾子と識別子をすべて使用して契約を解決できない場合、送信者修飾子と識別子のみを使用して契約の解決を試みます。 X12 の場合のこれらのフィールドは、ISA05 と ISA06 です。EDIFACT の場合は、UNB2.1 と UNB2.2 です。 送信者と受信者のプロパティの一致と同様に、BizTalk Serverはインターチェンジ ヘッダーの値と、[契約のプロパティ] ダイアログ ボックスの [方向固有の契約] タブの [識別子] ページで定義されている契約プロパティと一致します。 契約の解決に送信者修飾子と識別子のみを使用する場合は、[契約の プロパティ ] ダイアログ ボックスの [双方向アグリーメント] タブで受信者の修飾子と識別子を未定義にする必要があります。
契約が見つからない場合、ポート設定で認証が必要な場合を除き、BizTalk Serverはフォールバック 取引先契約を使用します。 ポート設定で認証が必要な場合 ([認証が失敗した場合にメッセージを削除する] または [受信ポートのプロパティ] の [全般] ページで [認証が失敗した場合はメッセージを保持する] が選択されている場合)、受信ポートで受信するすべてのインターチェンジにアグリーメントが必要です。 この場合は、インターチェンジ ヘッダーとアグリーメント プロパティの照合によるアグリーメント解決が不可能ならば、フォールバック アグリーメント プロパティを使用してアグリーメントを特定することは許可されません。 アグリーメントが見つからない場合は、インターチェンジは認証に失敗したものと見なされて、中断状態となります。
Note
EDI パイプライン内のメッセージは、有効な状態のアグリーメントに解決されるまで、アグリーメント解決における次の手順に進みます。 たとえば、メッセージがアグリーメント解決の最初の手順で解決されたとしても、アグリーメントが無効な状態の場合、メッセージは次の解決手順に進みます。
スキーマ探索
BizTalk Serverがメッセージに解決する契約を決定したら、メッセージの検証と処理に使用するスキーマを決定する必要があります。 これは、[契約のプロパティ] ダイアログ ボックスの一方向 (送信側) 契約タブの [ ローカル ホスト設定] ページで識別される プロパティ を使用して行います。
スキーマを決定するために、BizTalk Server は、最初にスキーマの名前空間を決定する必要があります。 EDI 逆アセンブラーは、BizTalk Serverに付属する標準スキーマに既定の名前空間を使用するか、カスタム スキーマに使用する名前空間を決定します。
[契約のプロパティ] ダイアログ ボックスの [一方向アグリーメント] タブの [ローカル ホスト設定] ページでは、値のグリッドを設定してカスタム名前空間を決定できます。 そのグリッドに一致するものが見つからない場合、EDI 逆アセンブラーでは、既定の行に対してマークされた [ ターゲット名前空間 ] フィールドの既定の名前空間が使用されます。
X12 スキーマ探索
X12 エンコード メッセージの場合、BizTalk Server は、受信したインターチェンジのヘッダーからアプリケーション送信者の識別子 (GS02) とトランザクション セット ID (ST01) を使用して、カスタムの名前空間を決定します。 [契約のプロパティ] ダイアログ ボックスの [双方向アグリーメント] タブの [ローカル ホスト設定] ページ ([トランザクション セットの設定] の下) の [ターゲット名前空間のカスタマイズ] グリッドで、これらの値と GS02 プロパティと ST01 プロパティの値の一致を検索しようとします。 一致するものが見つかった場合は、グリッドの同じ行で識別されたターゲット名前空間を使用して、メッセージを検証して処理するスキーマを決定します。 ターゲットの名前空間が決定されない場合は、既定のターゲットの名前空間が使用されます。 既定の行に対してマークされた [ターゲット名前空間] フィールドで名前空間が識別されない場合、BizTalk Serverは X12 でエンコードされたメッセージのフォールバック アグリーメント プロパティで識別されるターゲット名前空間を使用します。既定では ですhttp://schemas.microsoft.com/BizTalk/Edi/X12/2006。
X12 インターチェンジの場合、ターゲット名前空間が検出された後、BizTalk Serverは次の情報を使用してスキーマを決定します。
検出されたターゲットの名前空間
ST03 の最初の 5 文字のバージョン/リリース (GS07 == X - Accredited Standards Committee X12 の場合)。 ST03 が存在しないか無効である場合、またはスキーマを決定できない場合は、GS08 または ISA12 (GS07 != X の場合) の最初の 5 文字でバージョンが決定されます。
ST01 の DocType
EDI 逆アセンブラーは、エンコードの種類、バージョン/リリース、および DocType を連結して、スキーマ名 ("X12_00401_864" など) を決定します。 次に、ターゲット名前空間とスキーマ名を連結します (例:
http://schemas.microsoft.com/BizTalk/Edi/X12/2006/X12#X12_00401_864)。着信 HIPAA 837 インターチェンジの場合、BizTalk Serverでは 3 つの HIPAA 837 スキーマがサポートされます。
| 837 スキーマ | GS08 の値 (Version 4010) | GS08/ST03 の値 (Version 5010) |
|---|---|---|
| Claim-Dental_837D | 004010X097A1 | 005010X224A1 |
| Claim-Institutional_837I | 004010X096A1 | 005010X223A1 |
| Claim-Professional_837P | 004010X098A1 | 005010X222 |
Note
HIPAA の各バージョンのトランザクション セット 278 (Health Care Services Review) については、GS08 および ST01 の値は要求と応答のどちらのペアも同じです。 BHT02 フィールドのトリガー値に応じて、バージョン 5010 の 278 要求/応答を区別できます。
- BHT02 の値が 01、13、36 のいずれかならば、Health Care Services Review Request
2. BHT02 の 11 は、医療サービスのレビュー対応を示しています
EDIFACT スキーマ探索
EDIFACT エンコード メッセージの場合、BizTalk Server は、受信したインターチェンジのヘッダーからメッセージの種類 (UNH2.1)、メッセージのバージョン番号 (UNH2.2)、メッセージのリリース番号 (UNH2.3)、割り当てコード (UNH2.5)、機能グループ ID (UNG2.1)、およびアプリケーション送信コードの修飾子 (UNG2.2) を使用して、カスタムの名前空間を決定します。 次に、[契約のプロパティ] ダイアログ ボックスの [ターゲット名前空間のカスタマイズ] グリッド ([トランザクション セットの設定] の下) で、これらの値と UNH2.1、UNH2.2、UNH2.3、UNH2.5、UNG2.2 プロパティの値との一致を見つけようとします。 一致するものが見つかった場合は、グリッドの同じ行で指定されたターゲットの名前空間が使用されて、メッセージの検証および処理のためのスキーマが決定されます。 ターゲットの名前空間が決定されない場合は、既定のターゲットの名前空間が使用されます。 既定の行に対してマークされた [ターゲット名前空間] フィールドで名前空間が識別されない場合、BizTalk Serverは、EDIFACT でエンコードされたメッセージのフォールバック アグリーメント プロパティで識別されるターゲット名前空間を使用します。既定では ですhttp://schemas.microsoft.com/BizTalk/Edi/EDIFACT/2006。
EDIFACT インターチェンジの場合、ターゲットの名前空間が検出されると、BizTalk Server は、次の情報を使用してスキーマを決定します。
検出されたターゲットの名前空間。
メッセージ バージョン番号 (UNH2.2)。
メッセージ リリース番号 (UNH2.3)。
メッセージの種類 (UNH2.1)。
割り当てコード (UNH2.5)。
EDI 逆アセンブラーは、エンコードの種類、バージョン、リリース、およびメッセージの種類を連結して、スキーマ名 ("EFACT_D94A_CONTEN" など) を決定します。 次に、ターゲット名前空間とスキーマ名を連結します (例:
http://schemas.microsoft.com/BizTalk/Edi/Edifact/2006/EFACT#EFACT_D94A_CONTEN)。メッセージ内に UNH2.5 が存在する場合は、UNH2.5 の値が名前に含まれるスキーマ (たとえば "EFACT_D94A_CONTEN_TEST") の検出が試行されます。 一致するスキーマが見つからない場合は、UNH2.5 の値を使用せずにスキーマの検出が試行されます。
承認
BizTalk Serverは、契約に対して定義されている承認フィールドとセキュリティ フィールドの値をメッセージ内のフィールドと共にチェックします。 一致しない場合、BizTalk Server はインターチェンジを中断します。 EDIFACT エンコード メッセージの場合のこれらのフィールドは、受信者の参照パスワード (UNB6.1 および UNB6.2) です。 X12 エンコード メッセージの場合のこれらのフィールドは、認証修飾子および認証情報 ([ISA1] ～ [ISA2]) とセキュリティ修飾子およびセキュリティ情報 ([ISA3] ～ [ISA4]) です。