次の方法で共有

送信 EDI メッセージのアグリーメントの解決とスキーマの決定

  • [アーティクル]

取引先への EDI メッセージを生成するには、EDI 送信パイプラインは次の作業を行う必要があります。

  • メッセージの解決先となるアグリーメントを指定する。

  • メッセージの検証に使用するスキーマを指定する。

契約解決

EDI 送信パイプラインは、送信インターチェンジとアグリーメントのプロパティとの間に一致があるかどうかを判断する一連の手順を実行することで、アグリーメントの参照を実行します。 BizTalk Server契約が決定されると、インターチェンジに適用されるドキュメント スキーマが決定されます (以下を参照)。 一致するアグリーメントに関連付けられたプロパティと関連するスキーマを使用して、送信メッセージの生成と検証が行われます。

契約の解決を行うために、BizTalk Serverは次のように進みます。

  1. AgreementPartIDForSend コンテキスト プロパティを一方向アグリーメントの ID と照合してアグリーメントを解決します。 このプロパティは整数型にする必要があります。カスタム コンポーネントで設定できます。BizTalk Serverによって設定されません。

  2. 手順 1. で一致するものが見つからない場合は、3 つのコンテキスト プロパティ (AgreementNameForSend、SenderPartyNameForSend、および ReceiverPartyNameForSend) すべてをアグリーメントのプロパティと照合して、アグリーメントを解決します。 アグリーメントを正しく解決するには、3 つのプロパティがすべて設定されている必要があります。 これらのプロパティは、カスタム コンポーネントで設定できます。BizTalk Serverによって設定されません。

  3. 手順 2 が成功しない場合は、メッセージ コンテキスト プロパティのパーティ名を DestinationPartyName プロパティと照合して契約を解決します。このプロパティは、契約プロパティの [ 識別子 ] タブで追加のアグリーメント リゾルバーとして設定されます。

  4. 手順 3. で一致するものが見つからない場合は、メッセージのコンテキスト内の DestinationPartySenderIdentifier、DestinationPartySenderQualifier、DestinationPartyReceiverIdentifier、および DestinationPartyReceiverQualifier プロパティを、アグリーメントのプロパティと照合して、アグリーメントを解決します。 アグリーメントを正しく解決するには、4 つのプロパティがすべて設定されている必要があります。 これらのプロパティの設定は BizTalk Server によって行われるのではなく、カスタム コンポーネントで設定できます。 詳細については、以下を参照してください。

    Note

    上記のコンテキスト プロパティのセットのいずれかが昇格され、BizTalk Serverがそれらのコンテキスト プロパティに関連付けられているアグリーメントを見つけることができない場合、BizTalk Serverはメッセージを中断します。

    ユーザーが意図的にアグリーメント解決用のコンテキスト プロパティのセットを記述し、リゾルバーが OnewayAgreement を識別できない場合は、メッセージが中断されます。 コンテキスト プロパティのセットに基づいてアグリーメントを解決できない場合、そのことを示す警告メッセージが EventLog にスローされます。

  5. 手順 4 が成功しない場合、または上記のコンテキスト プロパティが昇格されていない場合、EDI メッセージは、メッセージをサブスクライブした送信ポートと契約に関連付けられている送信ポートを照合することで、アグリーメントに解決されます。

    Note

    1 つの送信ポートが複数のアグリーメントに関連付けられていると、BizTalk Server によってエラーが生成されます。

  6. 手順 1.、2.、3.、または 4. でアグリーメントが見つからない場合、送信パイプラインはフォールバック アグリーメント設定を使用して、送信メッセージを生成します。

    送信者と受信者のコンテキスト プロパティの照合による契約解決

    前の 2 番目の手順で、照合に使用されたコンテキスト プロパティは EDI.DestinationPartySenderIdentifier、EDI.DestinationPartySenderQualifier、EDI.DestinationPartyReceiverIdentifier、および EDI.DestinationPartyReceiverQualifier の 4 つです。 これらのコンテキスト プロパティの名前空間は です http://schemas.microsoft.com/Edi/PropertySchema。 BizTalk Serverは、これらの値を、一方向アグリーメント プロパティの関連する送信者と受信者の識別子と修飾子と照合しようとします。 X12 の場合、これらのフィールドは、[契約のプロパティ] ダイアログ ボックスの [一方向アグリーメント] タブの [識別子] ページの ISA05、ISA06、ISA07、および ISA08 です。EDIFACT の場合、これらのフィールドは、[契約のプロパティ] ダイアログ ボックスの [一方向アグリーメント] タブの [識別子] ページの UNB2.1、UNB2.2、UNB3.1、UNB3.2 です。

    送信者と受信者の識別子および修飾子の 4 つすべてを使用して送信側アグリーメントの解決を有効にするには、これらの 4 つのコンテキスト プロパティをすべて設定する必要があります。 この操作により、アグリーメントが一意に識別されます。 アグリーメント参照についてこの方法を使用することで、送信側の処理の柔軟性が高まります。 たとえば、この方法を使用すると、場合によっては複数の送信ポートを作成する必要がなくなり、送信ポート フィルターが複雑にならないようにすることができます。 また、必要に応じて、OneWayAgreementId プロパティの設定を回避できます。

    あるメッセージに 4 つのコンテキスト プロパティがすべて設定されている場合で、これらのコンテキスト プロパティとこのプロパティの間に一致が見られないときは、そのメッセージは中断されます。 アグリーメントは、4 つのすべてのコンテキスト プロパティが設定されていない場合にのみ、アグリーメントに関連付けられた送信ポートを使用して解決されます。

Note

EDI パイプライン内のメッセージは、有効な状態のアグリーメントに解決されるまで、アグリーメント解決における次の手順に進みます。 たとえば、メッセージがアグリーメント解決の最初の手順で解決されたとしても、アグリーメントが無効な状態の場合、メッセージは次の解決手順に進みます。

スキーマの決定

EDI 送信パイプラインは、各トランザクション セットの中間 XML ファイル (ドキュメントの種類情報またはルート ノード内) に含まれているスキーマ名とスキーマ名前空間から作成されるメッセージに適用するスキーマを決定します。

保存されているインターチェンジの場合、送信パイプラインは、中間 XML ファイルの個々のトランザクション セットにあるドキュメントの種類情報を使用して完全なインターチェンジを作成します。 エンベロープ セグメントの処理には、制御セグメントのスキーマが使用されます。

参照

BizTalk Server が EDI メッセージを送信する方法