ステージ・ファイル処理を使用したインバウンドEDIバッチ・ファイルの処理
ステージ・ファイルおよびB2Bアクションを使用して、インバウンドEDIバッチ・ファイルを処理し、ファイルの機能確認を送信者に送り返すB2Bフローを作成する方法を学習します。
統合の設定の前提条件
インバウンドEDIバッチ・ファイルを処理するためにOracle IntegrationでB2Bフローを設定するための前提条件を確認します。
このフロー例の構成を開始する前に、次のことを行う必要があります:
- インバウンドEDIドキュメントおよびアウトバウンド機能確認(997)ドキュメントをホストする外部SFTPサーバーがあること。 SFTPサーバーに接続するためのFTP接続を作成します。 「FTPアダプタ接続の作成」を参照してください。
- Oracle Integrationで統合フローの作成、構成およびアクティブ化に精通してください。 基本的なB2Bフローを設定するためのステップ・バイ・ステップのガイドは、「B2B for Oracle Integrationを使用した単純な統合の作成」を参照してください。
- FTP起動操作および統合のステージ・ファイル・アクションの一般的な使用パターンに精通している必要があります。 「スケジュール済統合のステージ・ファイル処理によるファイルの処理」を参照してください。
ノート:
このユースケース例では、EDIバッチ・ファイル処理を実装するための一般的なガイドラインのみを示します。 外部SFTPサーバーがない場合は、FTPアダプタのかわりに他のアダプタを使用してEDIファイルをフェッチし、任意のアクションまたは構成を使用してユースケースにあわせて統合を構築できます。 たとえば、「インバウンドEDIメッセージの解析および変換」サンプルの「RESTアダプタ」トリガー接続で使用可能なstreamReference入力を入力ファイルとして使用できます。 その後、ステージ・ファイル・アクションおよびその他の処理ステップをそのファイルに適用できます。
EDIバッチ・ファイルを処理するための統合の構築
ここで説明する一般的なガイドラインに従って、統合フローの例を作成します。
- 受信したEDIバッチ・ファイルをOracle Integrationにダウンロードします。
FTPアダプタ起動接続を使用して、単一のファイルをダウンロードできます。 リモートSFTPサーバー上のディレクトリから複数のファイルを処理する場合は、2つのFTPアダプタ起動接続パターンを使用します。この場合、一方のFTPアダプタ起動接続でファイルのリストが取得され、もう一方のファイルがダウンロードされます。
- ステージ・ファイル・アクションを使用して、ダウンロードしたバッチ・ファイルからEDIドキュメントをデバッチします。 「EDIファイルをデバッチするためのステージ・ファイル・アクションの構成」を参照してください。
50のEDIオーダーのバッチを単一ファイルで受け取ったとします。 ステージ・ファイル・アクションでは、ファイルが50の個々のEDIオーダーに分割され、繰返し要素として提供されます。
- for-eachアクションを使用して、繰返し要素を反復処理し、一度に1つのEDI文書を処理します。
- B2Bアクションを使用して、EDIドキュメントを一度に解析します。
for-eachアクションが個々のEDIドキュメントに対して繰り返されると、B2Bアクションは元のバッチに50のEDIオーダーが含まれていることを追跡し、最後にバッチ内の最後のドキュメントに対して追加の処理を実行します。
- バッチ全体が解析された後、機能確認ドキュメントを元の送信者に送信します。 「EDI X12 997機能確認の送信」を参照してください。
B2Bアクションでは、バッチから処理する最後のEDIドキュメントに対してEDI X12 997 (機能確認)が生成されます。 この50個の文書の例では、B2B処理によって最初の49個のEDI購買オーダーが定期的に処理されますが、EDI X12 997 (Functional Acknowledgment)文書が50番目のEDI購買オーダーに含まれます。 この確認ドキュメントには、50のドキュメントのバッチ全体のステータス情報が含まれており、EDI X12標準に従って、バッチ全体が解析された後、このドキュメントを元の取引パートナに送り返す必要があります。 B2Bアクションで997ドキュメントが生成されている場合は、別のファイルに書き込み、「FTPアダプタ」起動の接続および書込みファイル操作を使用してファイルを取引パートナに送信します。
- B2Bアクションが正常に完了したかどうかを確認します。
これを行うには、
translation-statusがSuccessかWarningかを確認します。 いずれかのステータスの場合は、マップ・アクションを使用して、EDI-XMLをバックエンド・アプリケーション・メッセージに変換します。 最後に、適切なアダプタから起動接続を使用して、バックエンド・アプリケーションにメッセージを送信します。 - ファイルが処理された後、
.processedファイル拡張子を使用してファイル名を変更し、将来の実行で同じファイルが再度処理対象として選択されないようにします。
EDIファイルをデバッチするためのステージ・ファイル・アクションの構成
統合でステージ・ファイル・アクションを構成するために実行する必要がある主要なタスクのリストを次に示します。
- ステージ・ファイル・アーカイブの構成時に、構成ウィザードの「操作の構成」ページにある「ステージング・ファイル操作の選択」フィールドで「セグメント内のファイルの読み取り」を選択します。
- 「スキーマ・オプション」ページで、次の図に示すように、ファイル・コンテンツの構造を「EDIドキュメント」として指定します。 このオプションを指定すると、EDIバッチ・ファイルが個々のドキュメントにデバッチ処理されます。
- EDIドキュメント用に構成されたステージ・ファイル・アクションによって、次の出力構造が生成されます:
EDI文書の入力バッチから、デバッチされたEDI文書ごとに繰返し要素EDI-Document-Instanceが生成されます。 たとえば、入力が50のバッチの場合、50のEDI-Document-Instance要素があります。 入力に単一のEDI文書がある場合は、単一のEDI-Document-Instance要素のみが生成されます。
ノート:
統合で、for-eachアクションを使用して繰返し要素EDI-Document-Instanceを反復処理します。 - 「EDIへのマップ-変換」アクションを構成します。
このアクションは、ステージ・ファイル・アクションからEDI-Translateアクションにデータを転送するマップです。 データには、
edi-payloadおよびEDIバッチの状態を追跡するために必要なその他の要素が含まれるため、次の要素をマップする必要があります:edi-payloadtracking-infoedi-encodingrouting-info(各子要素をソースからターゲットにマップ)validation-errorsからpassthrough-errorsへ(各子要素をソースからターゲットにマップ)- (オプション)ターゲットからの
input-source-context。 「B2Bアクション入力および出力スキーマ・リファレンス」を参照してください。
ノート:
入力ファイルに単一のEDIドキュメント(バッチではない)がある場合、ステージ・ファイル・アクションは単に繰返し要素構造に単一のEDI-Document-Instanceを生成します。 このような場合、for-eachアクションは一度だけ繰り返されます。 したがって、EDIバッチを処理するように設計された統合は、単一のEDIドキュメント・ファイルに対しても機能します。 バッチが1つの特殊なケースです。
エラー処理
- EDI-Document-Instance > validation-errors > error > category = "FATAL"
このエラー・カテゴリは、入力EDIでクリティカル・エラーが見つかったため、EDIファイル全体が拒否されることを示します(入力ファイルに1つのX12交換が含まれているとします)。このエラーを取引先に自動的にレポートするためのX12 TA1ドキュメントは生成されません。 したがって、管理者に通知し、送信者取引パートナと協力して正しいことを確認し、ファイルを再送信する必要があります。 致命的エラーのあるメッセージは、B2Bアクションに転送しないでください。
エラー・シナリオの例: 交換/グループ管理番号がないか、ISAセグメントとIEAセグメントの交換管理番号が同じではありません。
- EDI-Document-Instance > validation-errors > error > category = "GROUP"
このエラー・カテゴリは、X12グループ全体が拒否される原因となったX12機能グループ・レベルのエラーを示します。 このタイプのエラーの場合は、これらのエラーを次のB2Bアクションに転送するだけで、グループが拒否されたことを示す適切なEDI X12 997機能確認を生成できます。 これは、後で説明するマップ・アクションを使用して行います。
エラー・シナリオの例: GSセグメントとGEセグメントのグループ管理番号が同じでない場合。
ノート:
EDIは通常コンピュータ生成であるため、前述の構造エラーは一般的ではありません。 ただし、統合にエラー処理を組み込むことをお薦めします。統合の次の部分には、Debatch-EDI-File-Scという名前のステージ・ファイル・アクション、For-Eachアクション、致命的エラーの有無をチェックするルートを含む切替えアクション、およびB2Bアクションやその他の関連アクションに移動する別のルートが示されています:
for-eachアクションFor-Each-EDI-Docuは、この例では反復変数$EDIRecを使用します。
統合では、致命的なエラーとともにEDI-Document-Instanceがルーティングされ、エラー処理のために送信されます。 致命的なエラーが存在する場合は、B2Bアクションを起動しないでください。
count($EDIRec > EDI-Document-Instance > validation-errors > error > category[(text() = "FATAL")]) > 0異種ドキュメントを含むEDIバッチ・ファイルの処理
EDI X12標準では、単一のEDIバッチ・ファイルに異なるタイプの複数のEDI文書を含めることができます。 たとえば、バッチ・ファイルには50のオーダーと10の請求書が含まれており、異機種間バッチになります。
統合内の様々なドキュメント・タイプを含むEDIバッチ・ファイルを処理する手順は、次のとおりです:
- 「EDIファイルをデバッチするためのステージ・ファイル・アクションの構成」に示されているフローで、for-eachアクションFor-Each-EDI-Docの後にswitchアクションを追加します。
- switchアクションで、
$EDIRec > EDI-Document-Instance > routing-info > document-type要素またはrouting-info要素内の他の子要素の値に基づいて、1つ以上のルートを追加します。 - 各ルートで、個別のB2BアクションEDI-Translateを追加し、特定のドキュメント・タイプを解析するように構成します。 EDIドキュメントが一致するB2Bアクションに正しくルーティングされていることを確認します。 これで、各B2Bアクションは異なるドキュメント・タイプを解析し、そのアクションに従うためのエラー処理、変換およびその他のステップを追加できます。
致命的エラーおよびEDI X12文書850、997および810を処理するルートを示す統合の例を次に示します。 Route 5は、以前にエラーとして明示的にルーティングされていないドキュメント・タイプを処理します。
「図edi_complete_int.pngの説明」
ステージ・ファイル・アクションでは、統合でスイッチ・ルートを制御できる次の要素がrouting-info要素の子要素として生成されます。
| 子要素 | 説明 |
|---|---|
| doc-standard |
X12など、ドキュメントに対して識別されるEDI標準。 |
| doc-type |
EDIドキュメント・タイプ; たとえば: 850、EDI X12オーダーを表します。 |
| doc-version |
EDIのバージョン(EDI X12バージョン4010など)。 |
| doc-definition |
使用されません。 |
| ic-sender-ID-qualifier |
交換ヘッダーに表示される交換送信者ID修飾子(X12の場合はISAセグメントのISA05要素の値)。 |
| ic-sender-ID |
交換ヘッダーに表示される交換送信者ID (X12の場合はISAセグメントのISA06要素の値)。 |
| ic-receiver-ID-qualifier |
交換ヘッダーに表示される交換レシーバID修飾子(X12の場合はISAセグメントのISA07要素の値)。 |
| ic-receiver-ID |
交換ヘッダーに表示される交換レシーバID (X12の場合はISAセグメントのISA08要素の値)。 |
| grp-identifier-code |
機能グループ・ヘッダーに表示される機能グループ識別子コード(X12の場合、GSセグメントのGS01要素の値)。 |
| grp-application-sender-code |
機能グループ・ヘッダーに表示される機能グループ・アプリケーション送信者コード(X12の場合、GSセグメントのGS02要素の値)。 |
| grp-application-receiver-code |
機能グループ・ヘッダーに表示される機能グループ・アプリケーション・レシーバ・コード(X12の場合、GSセグメントのGS03要素の値)。 |
EDI X12 997機能確認の送信
B2Bアクションでは、EDIバッチ・ドキュメント内の機能グループ(GS)ごとにEDI X12 997 (機能確認)が生成され、バッチから処理されます(バッチにドキュメントが1つしか含まれていない場合でも同様)。
バッチは、GSで始まりGEセグメントで終わるX12機能グループとして定義されます。 機能グループには1つ以上のEDI文書が含まれ、各文書はSTセグメントとSEセグメントのペアの間にエンベロープされます。 1つの機能グループに対して1つの997 (機能確認)が生成されます。 X12交換は、1つ以上の機能グループのコンテナです。 ステージ・ファイルとB2Bアクションを一緒に使用すると、これらのエンベロープ構造を理解し、X12交換内で発生する機能グループの数と同じ数の997 Acksを生成できます。
次の表に、50のEDI購買オーダーのバッチを解析した場合のB2B処理の出力を示します。 表の各行は、処理された個々のEDI文書を表します。
ここでは、出力として「インバウンドEDI用のTranslateOutputの要素」の関連フィールドがいくつか表示されていることに注意してください。
| EDI文書番号(バッチ50) | EDI変換出力 |
|---|---|
| 1 |
|
| 2 |
|
| ... |
... |
| 49 |
|
| 50 |
|
統合で、functional-ack-present要素を確認します。 値がtrueの場合は、(decodeBase64ToReference組込み関数を使用して) functional-ack要素の内容をファイルに書き込み、別のFTPアダプタ起動接続を使用して元の取引パートナにファイルを転送します。 functional-ack要素はBase64-encoded文字列として移入されることに注意してください。 したがって、EDI 997確認文書を抽出するには、マップ・アクションでdecode64関数またはそのバリアントを適用する必要があります。
統合の確認部分は、次の図のようになります:
