使いやすいテクノロジーに直面して、なぜこの古風なフォーマットがまだ使用されているのですか？それは私が見ていないいくつかの利点を提供しますか？多くのベンダーは、XMLなどのより管理しやすく使いやすいものではなく、この形式でのみデータを提供しているようです。少なくとも、両方の形式を提供することは私には理にかなっています。
また、EDIを使用する以外に選択肢がない場合に、EDIを処理して利用するための良い方法は何ですか？BizTalkのようなものは、非常に高価であるため、問題外です。EDIの操作を容易にする無料/オープンソースアプリケーションはありますか？
EDIは、使用する区切り文字に慣れれば、それほど理解するのは難しくありません。なぜ誰もがCSVまたはタブ区切りのデータを使用しているのかを自問するかもしれません。
答えはおそらく、これらのフォーマットは委員会によって定義され、特定の業界で標準化された「ドメイン固有言語」であり、これらのフォーマットをサポートするためにすでに多くのお金が投資されているということです。それをすべて捨てるビジネスケースはどこにありますか？
一言、慣性。さまざまなアジェンダを持つさまざまな企業や組織の間で委員会によってEDI形式を開発することは、悪夢でした（私がそこにいたと言うのは悲しいことです）。
WebサービスAPI標準に同意する委員会のさらに別のラウンドでこれらを放棄するように依頼すると、さらに時間がかかります。ある電子形式を別の電子形式に置き換えるというアイデアを非技術委員会にどのように売りますか？それが彼らに与える可能性のあるビジネス上の利点は何ですか。もともと電子交換の利点は明らかでしたが、別のものと交換することはそうではありません。ここでは本当に大企業と話しています。
次のプロジェクトに興味があるかもしれません:
そして、XMLに切り替えると、何が得られますか？ラインフォーマットのデバッグが少し簡単になりますか？
通常、設定してそのままにしておきます。生のEDIフィードで遊ぶ必要はあまりありません。確かに、標準を放棄してやり直すには十分ではありません。
読みやすくすることができるFAXのような多くの標準がありますが、それらを変更する必要はありません。
これは、正式に確立された標準であるためです (実際には、非常に大規模で包括的な標準セットです)。これは、標準化によって主張されている利点の 1 つです。長い間、何も変更する必要はありません。
そして、それを変えるには、2 つ以上 (多くの場合、数千から数千以上) の取引パートナー (おそらくすべての競合相手を含む) の間で合意する必要があります。
EDI 形式の信号対雑音比ははるかに高くなります (これは、EDI が重要であると考えられていた時代に設計されたためです)。EDI を知っていて理解している人は、XML を見て、「牛肉 (データ) はどこにあるのか?」と言うでしょう。
独自のパーサーを作成する開発者はほとんどいません。多くの優れたマッパーが利用可能です (そして、多くのレガシー アプリやエンタープライズ アプリにはそれらが組み込まれています)。そのため、痛みを和らげる方法がたくさんあります (SourceForge の少なくとも 1 つのオープン ソース アプリを含む)。
興味のある方に少し情報を。EDI は基本的に委員会によるデータ交換フォーマットであり、データ フォーマット (XML など) のルールを設定するだけでなく、2 つの企業間で送信される可能性のある各ドキュメントを定義するために設定されています。そのため、企業間で交換される可能性のあるデータについて、これらの各ドキュメントに何が含まれるべきかを正確に定義しました。もちろん、2 つの企業が交換したいすべてのデータを予測できる人はいません。そのため、企業は 1 つのものに対して定義されたフィールドを使用し、別の情報に使用することになります。
あなたが最終的に得たものは、標準が説明していないカスタム情報を送信する必要があるため、それを使用する多くの人々が標準に従わない、非常に複雑なデータ形式です。したがって、最終的には、取引したい各企業と話をして、カスタム XML インターフェースを持っている人のところに行った場合と同じように、その実装の小さな特異性をすべて見つける必要があります。EDI の場合を除いて、形式を解析するのは難しく、適切に記述するのはさらに難しいため、カスタム XML ソリューションを使用して同様のことを考えると、ドキュメントを送信するためだけに大量の作業を行うことになります。何倍も問題が少なくなるでしょう。
「壊れていないなら直すな。」
これらの組織のほとんどは、EDI を使用して膨大な量のデータを処理しており、やむを得ない理由がない限り、より最新のものに変更しようとはしていません。そして、悲しいことに、サードパーティの開発者にとって物事を簡単にすることは、通常は資格がありません.
IMHO EDIFACT にはいくつかの問題があります。
要約すると、首の痛みです。
EDI は非常にコンパクトな形式であり、データ交換での帯域幅の使用をできるだけ小さく保つためによく使用されます。たとえば、ドイツの税関では、ATLAS システムでこれを使用して、毎日非常に大量のデータを交換しています。
解析も読み取りも困難ですが、結果として得られるデータのサイズが問題になる場合は、適切な選択であり、大規模なビジネス アプリケーションのほとんどでサポートされています。
EDIは多くの業界で多作です。すでに機能しているテクノロジーを新しいテクノロジーに置き換えるには、法外な費用がかかります。
これを考慮して、ウォルマートはEDIを使用してベンダー、店舗、流通チェーンなどと通信します。彼らは数万のベンダーと取引していると思います。それらのすべてがEDIテクノロジーに数千ドルを投じています。ウォルマートがXMLに切り替えることを決定した場合、その決定はウォルマートだけでなく、何千もの企業に影響を及ぼします。
これは、すべてのEDIユーザーに当てはまります。結局のところ、それはトレーディングパートナ間で使用される標準です。
私は同意します、EDIは一緒に働くのが苦痛です。しかし、「当時」、それが私たちが持っていたすべてです。
レガシーサポート
Edifact は、ドキュメント交換に関しては最高の標準の 1 つです。ほとんどの問題は、標準化されていないドキュメントを送信する取引パートナーから発生します。
はい、それは少し奇妙な形式であり、内外がわからない場合は作業が面倒ですが、それは XML にも当てはまります。
本当に Edifact よりも XML が必要ですか? peppol (汎ヨーロッパ公共調達オンライン) が取り組んでいる肥大化した読みにくい XML 標準を見てください。
はい、システムにエラーがなければ問題なく機能しています。フォーマットに慣れれば、UBL ドキュメントのトラブルシューティングよりも edifacts のトラブルシューティングの方がはるかに簡単です。
プロジェクトで使用する $0.00 があるとしますか? あなたの会社で行われている手作業の量を実際に調査する必要があり、EDI が提供できるコスト削減は、費用対効果の分析に非常に役立ちます。
費用はかかりますが、解決策の 1 つはADXのような会社に行くことです。この会社には、EDI 形式を CSV などのより使いやすい形式に変換するために使用できるツールがあります。行っている取引の量と種類にもよりますが、これは手頃な価格であり、ストレスも大幅に軽減されます。私は過去に彼らの製品を使用したことがあり、セットアップには少し手間がかかりますが、非常にうまく機能し、非常に安定しています. EDI の歴史により、同様のサービスを提供する企業は他にも何百とあるはずです。
EDIは、XML以前から存在しています。2つのパーティが両方で機能するEDI形式を事前にネゴシエートできるという事実とは別に、VAN（付加価値通信網）の一部も考慮する必要があります。
場合によっては、VANはメッセージの検証を実行したり、メッセージを読み取って、その内容に基づいて追加の関係者にメッセージをコピーするなどのアクションを実行したりします。
EDIを実際に使用する唯一の理由は、「それが常に行われている方法である」ためです。したがって、EDIをサポートするための既存のインフラストラクチャがたくさんあります。必要がないのになぜXMLに切り替えるのですか？そして、XMLがJSONに置き換えられず、JSONが他の何かに置き換えられるとはどういう意味ですか？
もう1つの理由は、注文などのビジネスメッセージであることです。請求書、貸方票など、取引には多くの金銭的価値があり、それらは安全である必要がありますが、おそらくもっと重要なことは、エンドツーエンドの検証と検証、および否認防止が必要です.
たとえば、私は 1/2 百万ユーロ相当の商品の注文をあなたに送り、あなたは私に商品を送ってくれました。その後、私は注文情報を「失い」、支払いをしていないと伝えます。標準と VANS の組み合わせにより、これはほとんど不可能になり、少なくとも問題を追跡できるほど多くの監査証跡が作成されます。これが、「EDIFACT と VANS の代わりに xml とインターネットを使用しよう」が失敗する傾向がある理由です。誰かが答えたように、慣性ですが、それは安定した効果的で、安全で、信頼性が高く、よく理解されたシステムに基づいた慣性です。
安価でそれを行うことは、常にオプションではありません。
1987 年に初めて EDI を実装したときの慰めになるとすれば、周りにはほとんどソフトウェアがなかったので、Interbridge テーブルを入手し、Cognos ソフトウェアと HP Mini を使用して英国の TRADACOMS 標準用に独自のパーサーを作成しましたが、問題なく動作しました。他の EDI パートナーと取引していると仮定すると、コストはおそらく VAN を使用する必要がある時点で発生します。
私もEDIを使用する必要があり、同意します。BizTalkを使用して、うまく機能するようにマップしました。多くのシステムはEDI（XMLよりかなり前）に基づいて構築されています。