EDI標準。 技術レビュー

EDI標準（ Electronic Data Interchange ）は、古い確立されたシステムの一部です。 しかし、EDIが最新の標準としてどのように提示されるかを常に見ています。 そうですか？ 新しいプロジェクトの基礎となるテクノロジーとしてEDIを考慮する必要がありますか？

EDIを技術的な観点から見て、他のすべてを破棄しましょう。

EDIのデータ形式

EDIは区切りテキスト形式を使用します 。 テーブルなどのフラットなデータ構造に適しています。 階層的なデータ構造を表すにはあまり適していません。 ネストされたオブジェクトは、XMLやJSONなどのタグ付きフォーマットを使用して、より適切にシリアル化されます。

非常に奇妙ですが、EDIのドキュメント定義 言語は作成されませんでした。 EDIの登場から何年も経ち、EDIに多大な労力が費やされましたが、記述言語は作成されていません。 記述言語を使用すると、データの処理、つまり生成、検証、変換、シリアライゼーション、デシリアライゼーションを自動化できます。 比較のために、XMLデータを検証するために、データスキーム（XMLスキーマ、xsd）を使用し、パーサーはこのスキームへの準拠についてデータを自動的にチェックします。

ダイアグラムなしでも実行できますが、ドキュメントのマークアップが望ましいです。 データ自体にはデータ要素のタグ（名前）が含まれているため、XMLおよびJSONドキュメントはスキーマなしで逆シリアル化できます。 EDIには、セグメントのみのタグがあり、要素のタグはありません。 要素は、セグメント内の位置によって決まります。 文書にはデータ要素の名前または型が含まれていないため、 ユニバーサル EDIパーサーは文書をプリミティブコレクションにのみ解析できます。



詳細に行きましょう。



EDI標準は、2つの主要部分で構成されています。

• エンベロープ（バッチ？）形式（メッセージング標準の混合）
  
  
• ドキュメントの仕様（フォーマット）（産業（ドメイン）標準の混合物）
  
  

バッチ形式

EDIは、ドキュメントのセット、ドキュメントのグループ、ドキュメント/トランザクション自体のパッケージ（ 交換 、 グループ 、 トランザクション / ドキュメント）を定義します。 パッケージは、それぞれISA / IEA、GS / GE、ST / SEペアのセグメントに制限されています。

注：説明のために、北米で一般的な標準のEDI X12バージョンを使用しています。 標準のもう1つのバージョンであるEDIFACTは、ヨーロッパでは一般的であり、X12と根本的に違いはありません。

以下は、ISA、GS、STの3つのパッケージすべての最初のセグメントの例です。 以下に例を示します 。

ISA * 00 * * 00 * * ZZ *受信者* 12 *送信者* 100325 * 1113 * U * 00403 * 000011436 * 0 * T *>〜

GS * FA * RECEIVERID * SENDERID * 20100325 * 1113 * 24712 * X * 004030〜

ST * 997 * 1136〜

最初のセグメントには何が見えますか？

ISAセグメントの最後の3文字は区切り文字です。「*>〜」：「〜」はセグメント区切りの記号です。 '*'-セグメント内の要素を区切る記号。 '>'は、要素内のサブ要素を分離するための記号です。 これらの文字を変更することにより、パッケージとドキュメントの形式を本質的に変更します。 XMLおよびJSONでは、区切り文字は標準で指定されており、変更できません。 可変セパレーターは、Unicodeがまだ作成されていなかった時代の基本です。 しかし、当時であっても、セパレータを可変にすることは良い考えではありませんでした。 セパレータは非常に重要なキャラクターです。 セパレータとして任意の文字を使用できる場合、これはパケットを構成部分に解析するロジックに名前を付けるだけでなく、要素自体内のテキストを解析するロジックを大幅に複雑にします。

ISAセグメントでも、時間と日付の形式を定義する要素があります 。 ドキュメント内でカスタムの日付と時刻の形式を使用するのに役立ちます。 これは、日付と時刻をエンコードするときに数バイトを保存する必要があった70年代に意味がありました。 これらの要素は、「2000年」の問題を克服した後、時間を表現するための専門的で非常に詳細な標準が作成された後、今必要ですか？

私たちは送付者と受取人を定義するISAセグメントの要素を見ます 。 これは基本的にルーティング情報です。 つまり、パッケージング標準はアドレス指定標準と組み合わされます。 EDIを使用して、データ内で送信者と宛先を指定する必要があります。 ISAセグメントには、 承認要素もあります 。 この認証情報をメッセージ自体の内部に配置するという考えは、か​​つては非常に進歩的でしたが、今では少なくとも素朴で、さらには危険にさえ見えます。 承認情報は、値のペアよりもはるかに複雑であることがわかりました。 アドレス情報についても同じことが言えます。 EDI標準は、これらの要素を使用するように促しています。

確認要求要素も表示されます。 つまり、ドキュメントの作成者は、確認をドキュメント内で直接使用するための戦略を設定します。 これはいいアイデアですか？ さまざまなシナリオでドキュメントを使用できます。 それらの一部では、アプリケーションレベルで確認が使用され、その他では、信頼性を高めるために他のプロトコルが使用されます。 信頼性は、データ転送のかなり複雑なトピックであり、通信の多くの参加者によって決定されるため、信頼性ポリシーはデータ自体の内部では定義されません。

パケットセグメント内には、 コントロール番号が表示されます。 一連のドキュメントを受け取るシナリオでは必要ですが、途中でセットの一部が失われたり歪められたりするため、できるだけ多くのデータを回復しようとしています。 同様の信頼性の問題は通常、通信プロトコルの下位レベルで解決されるため、このシナリオは長い間使用されていません。 アプリケーションレベルでの通信の信頼性は組み込まれていませんよね？

ISAセグメントのもう1つの要素は、 EDIバージョン （ 標準識別子 ）です。 これは、シリアル化標準でよく知られているバージョン管理サポートに似ています。

GSセグメントには、 ドキュメントの タイプ （ Type of Document ）を定義する要素があります。 たとえば、これは注文または請求書です。 ドキュメント自体の内部でドキュメントのタイプを設定する方が簡単ですが、これについてそれほど悪いことはありません。



ご覧のように、バッチセグメント内のほとんどすべての要素は役に立たないか、標準に従って使用する場合はさらに危険です。

認証とアドレス指定にパケットセグメントからのデータを使用しないでください。

EDIは、この情報をパッケージに入れることが唯一のオプションであったときに作成されました。 現在、インターネットを介してドキュメントを転送し、パッケージング、アドレス指定、認証、承認、信頼性、コーディング、シリアル化、セグメンテーションなどにさまざまな標準とプロトコルを使用しています。 プロトコル固有の情報はデータパス全体で追加および削除され、この情報はデータ自体とは無関係です。

EDIはデータ形式の標準またはプロトコルですか？

EDIはプロトコルになろうとしているため、これらのアドレス指定、承認、および確認要求の要素が見られます。 この情報をOSIプロトコルレイヤーモデルと比較する方法はわかりません。

それでも、EDI標準のほとんどはデータ形式専用です。

ドキュメント形式

パッケージ内には、ドキュメント自体が表示されます。 しかし、普遍的で一般化されたドキュメントの標準は見つかりません。 この規格は、注文、請求書、在庫の説明など、さまざまな種類のドキュメントの多数のフォーマットを定義しています... ここでは、標準化されたドキュメントの膨大なリストから小さな部分を見つけることができます。

EDIは有名な神話に従います。「どこかで、スクリプトの世界のすべてを記述する理想的なフォーマットがあります。 この形式は間違いなく見つかります。 新しいスクリプトを追加し、古いスクリプトを微調整するだけです。」

その結果、EDIの標準文書（仕様）は非常に複雑です。

たとえば、小さな地元の書店の請求書が必要です。 適切な標準仕様、EDI 850、発注書が見つかりました。 一見、あまりにも詳細に見えます。 食品、石炭、穀物、液体食品、危険な食品、医薬品は購入しません。 国際住所は必要ありません。 速達サービスは使用しません。 EDI仕様では、これらの可能なオプションをすべて説明していますが、使用するフィールドが多すぎて使用できません。 単純なドキュメントには複雑すぎます。

一種の知識のリポジトリとして使用される多くの業界（ドメイン）標準があります。 ただし、これらの標準はデータ転送標準としては使用されません。 （業界標準の問題について説明しているこの記事を参照してください。）

ドキュメント内のループ

個々のドキュメントの構造は非常に単純です。 ドキュメントは、ドキュメントデータが配置される一連のセグメントで構成されます。

しかし、セグメントはグループまたは繰り返しグループ、いわゆるループに結合できることがわかりました 。 奇妙な点は、これらのサイクルがドキュメントで絶対に強調されていないことです。 この特定のドキュメントの仕様には、サイクルの存在について読むことができます。 （同じタグを持つ）同じタイプのセグメントは、独立して、またはループ内に配置できます。 ループを認識するパーサーを作成することは（繰り返しますが、ドキュメント内でマークされていません）、かなり重要なタスクです。

XMLとJSONにはこのような問題はありません;階層オブジェクトまたはネストレベルのオブジェクトのコレクションは、名前付きまたは名前なしの開始タグと終了タグを使用して非常に簡単に設定できます。

EDIは2つの椅子に座ろうとしました。 一方では、そのドキュメント形式はcsv形式に似ており、表形式のデータを表示するのに便利です。 一方、彼は階層オブジェクトを記述しようとしましたが、この試みは非常に納得がいかずに終わりました。 もちろん、目の前にJSONがある場合、これを理解しています。 ただし、EDIは表形式のデータを送信するためではなく、階層構造のドキュメントを転送するために作成されたことを思い出してください。

EDIの非技術的な見方

全体像については、EDIの非技術的な機能の一部を引き続きリストします。

• EDI標準は無料ではありません 。 これは、他の標準と比較するとかなり奇妙に見えます。
  
  
• EDI標準仕様は非常に詳細です。 EDI仕様は非常に複雑であるため、企業は特定の仕様に精通した専門家を雇う必要があります。 これらのスペシャリストは、特別なEDI用語を使用して通信します。これは、ビジネスに関連しないほとんどEDI言語です。 企業間のEDI契約を見てください。 これらの契約には、EDI規格で定義された特定の要件が多数ありますが、ビジネス要件とはほど遠いものです。
  
  
• EDI規格は安定していません 。 特別委員会は、EDI規格の修正を6か月ごとに発行します。 これらの各バージョンでは、新しい改良が導入されています。 標準の開発はユーザーの要求に従うのではなく、単にスケジュールに従うだけです。 おそらくこれは規格に対する非常に高い要件によるものではなく、委員会がその作業の結果を示す必要があるためです。
  
  
• EDIは、ビットを節約し、ドキュメントをできるだけコンパクトにするために作成されました。 この要件は依然として存在しますが、ドキュメントの送信にはほとんど使用されません。 現在、すべての子供がギガバイトのビデオを転送する電話を所有しています。 ヤードはもはやメインフレームやテレタイプの時代ではありません。 また、紙のワークフローからEDIへの移行によるリソースの節約について完全に真剣に議論しているレポートを読むのはかなり奇妙です。
  
  
• メモリを節約するために、EDIはコードを使用して可能な限りデータを表します。 その結果、ドキュメントは暗号化されているように見え、コードテーブルの交換で追加の問題が発生します。
  
  
• EDI標準は、通信とコンピューターが高価で低速だったため、ドキュメントのバッチを送信するために作成されました。 それ以来、多くが変化し、通信とコンピューターは高速で安価になりました。 データは小さなメッセージまたはストリームで送信されるようになりました。これらの小さなメッセージは分散システムの基盤です。 ドキュメントセットはまだ使用されていますが、低速の機器ではなく、ビジネスプロセスで必要です。
  
  
• EDI記述言語の標準はありません。 これは、EDIドキュメントを処理するためのユニバーサルパーサーを作成できないことを意味します。 パーサーには、何千もの既存のEDI仕様の詳細と詳細な記述が含まれている必要があります。 （たとえば、MicrosoftはBizTalk Serverの一部としてEDIドキュメント用に約7,000のXMLスキーマを提供しています。）既存のEDIパーサーは高価です。 EDIドキュメントを操作するには、EDIドキュメントをXML形式に変換し、XMLスキーマとXMLパーサーを使用してEDIドキュメントを処理する必要があります（検証、変換、シリアル化、逆シリアル化、作成）。 これはBizTalk Serverで行われます。
  
  
• 標準のEDI記述言語がないため、ドキュメントは...複数ページの指示を使用して記述されます。 EDIパーサーの開発者はこれらの命令を異なる方法で解釈し、このため、異なるEDIパーサーは互換性がありません 。
  
  
• EDI標準は、プログラム、プロトコル、およびデータ形式の開発に非常に費用がかかり、非常に長い時間がかかったときに作成されました。 ユニバーサルドキュメント形式の標準を作成することが正当化されました。 現在、データ形式はオンザフライで生成されており、プログラムは通常、普遍的な標準を使用しませんが、特定のケースに対して異なる形式を作成します。 EDI仕様には、すべてのユーザーを満足させるためにできるだけ多くのパーツが含まれています。 最新のプログラムには、必要なデータのみが送信データの仕様に含まれています。 特定の場合に不要なEDI仕様の要素の数は、常に非常に多くなります。
  
  
• EDIは 、通信の標準とビジネスデータのフォーマットの標準という2種類の標準を組み合わせています。 現在の傾向はまったく逆です。標準は互いに独立している必要があり（直交）、任意の組み合わせで標準を混在させることができます。
  
  

ご覧のとおり、EDI規格は技術的な観点から考慮すると、ほぼすべての面で時代遅れです。 現在使用する合理的な技術的理由はほとんどありません。 しかし、それにもかかわらず、EDIは依然として広く使用されています。

次のパートでは、この理由を見つけようとします。 ほとんどの場合、それらは技術的な性質のものではありません。