EDI とは、承認済みの国家標準または業界標準で情報を変換および交換することに同意した仕事関係者間で ビジネス情報をネットワーク経由で伝送する手段のことです。WebSphere Partner Gateway は、以下の EDI 標準に対してエンベロープ解除、変換、およびエンベロープを実施する機能を備えています。
以下のセクションでは、X12、EDIFACT、および UCS 標準に準拠した EDI 交換と、それぞれの EDI 交換に含まれるト ランザクションおよびグループについて概説します。また、XML 文書、ROD 文書、および EDI 交換がどのように変換されるのかについても説明します。
EDI 交換には、1 つ以上のビジネス・トランザクションが含まれています。X12 およびその関連する標準では、ビジネス・トランザクションはトランザクション集合 と 呼ばれています。EDIFACT およびその関連する標準では、ビジネス・トランザクションはメッセージと呼ば れています。本書では、通常、X12 または UCS のトランザクション集合や EDIFACT メッセージのことを トランザクション またはビジネス・トランザクション と呼びます。
EDI 交換はいくつかのセグメントで構成されており、各セグメントにはデータ・エレメントが含まれています。データ・エレメントとは、具体的には名前、数量、日付、時間などのことです。 セグメントとは、関連するデータ・エレメントが 1 つにまとめられたグループのことです。セグメントは、その先頭に表示されるセグメント名またはセグメント・タグで識別されます。(データ・エレメントは、名前では識別されません。その代わり、区切ることを目的として予約された特殊な区切り文字で区切られています。)
トランザクション内の詳細またはデータ・セグメントを管理目的用に使用するその他のセグメントと区別すると、便利な場合 があります。 管理目的のセグメントは、X12 では制御セグメントと 呼ばれ、EDIFACT ではサービス・セグメントと呼ばれています。EDI 交換の境界を区切るエンベロープ・セグメントは、こうした制御セグメントやサービス・セグメ ントの一例です。
EDI 交換に含まれるセグメントには、3 つのレベルがあります。どのレベルでも、先頭にはヘッダー・セグメントがあり、末尾にはトレーラー・セグメントがあります。
どの交換にも、交換ヘッダー・セグメントと、交換トレーラー・セグメントがあります。
交換には、1 つ以上のグループを含めることができます。各グループには、1 つ以上の関連するトランザクションが含まれています。グループにもレベルがあり、EDIFACT ではオプションですが、X12 およびその関連する標準では必須です。複数のグループが含まれている場合、それぞれのグループごとにグループ・ヘッダーとグループ・トレーラー・セグメントがあります。
グループ (グループが存在しない場合には交換) には、1 つ以上のトランザクションが含まれています。各トランザクションには、トランザクション集合ヘッダーおよびトランザクション集合トレーラーがあります。
トランザクションは、購入注文などのビジネス・ド キュメントになります。ビジネス・ドキュメントの内容は、トランザクション集合ヘッダー・セグメントとトランザクション集合トレーラー・セグメント の間にある明細セグメントで示されます。
各 EDI 標準では、交換内にデータを表示する方法をそれぞれ独自に規定しています。以下の表は、サポートされている 3 つの EDI 標準のセグメントを示しています。
標準のセグメント | X12 | UCS | EDIFACT |
---|---|---|---|
交換開始 | ISA | BG | UNB |
交換終了 | IEA | EG | UNZ |
グループ開始 | GS | GS | UNG |
グループ終了 | GE | GE | UNE |
トランザクション開始 | ST | ST | UNH |
トランザクション終了 | SE | SE | UNT |
図 22 では、X12 交換とそれを構成するセグメントの例を紹介しています。
Data Interchange Services クライアントのマッピング担当者が、形式の異なる 文書間の変換方法を記述した変換マップを作成します。例えば、X12 トランザクションを EDIFACT メッセージに 変更する変換マップなどがあります。また、EDI トランザクションを XML 文書またはレコード単位データ文書に変換することもできます。
変換マップでは、1 つの文書から複数の文書を作成することもできます。このタイプのマップでは、マップ・チェーニング を使用して、単一トランザクションから複数の出力 を生成します。マップ・チェーニングでは、ソース文書が正常にターゲット文書に変換された後、後続のマップを使用して再度そのソース文書が別のターゲット文書を生成するために変換されます。これを何度も繰り返して、必要な数だけの文書を生成できます。
変換マップのほかに、機能肯定応答マップと検証マップも使用できます。機能肯定応答マップは、機能肯定応答の生成方法に関する指示を記載したものです (機能肯定応答は、EDI 文書が相手に届いたこ とを送信側に通知するものです)。WebSphere Partner Gateway をインストールすると、EDI 標準の機能肯定応答マップがいくつかインストールされます。この各マップのリストについては、機能肯定応答を参照してください。Data Interchange Services クライアントのマッピング担当者は、このほかに別の機能肯定応答マップを作成することもできます。WebSphere Partner Gateway は、EDI トランザクションが検証されたときに、EDI トランザクションに関連する機能肯定応答マップがあれば、機能肯定応答を生成します。ソース文書は、EDI 文書でなければなりません。
WebSphere Partner Gateway では、標準レベルの検証で EDI 文書が検証されます。機能肯定応答を生成しようとすると、EDI 文書の検証結果が保管されます。EDI 文書に対してさらに検証を行うには、検証マップを作成します。機能肯定応答の生成時には、機能肯定応答マップと EDI 文書の検証結果が使用されます。機能肯定応答マップにはマッピング・コマンドが記載されており、特定の機能肯定応答を作成するために検証結果をどのように使用するかを示します。検証プロセスが文書を変換対象として承認すると、適切なデータ変換マップを使用してソース文書が変換されます。