3 年以上前に、急務として顧客向けの EDI ソリューションの開発を依頼されました。
彼らは、ソリューションの完全な IP/制御などを望んでおり、無料のオープン ソース ソリューションを使用したり、BizTalk などに多額の費用を支払ったり、VAN に定期的な料金を支払ったりすることを望んでいませんでした。
当時、いくつかの調査を行いましたが、実際には EDI 形式や解析などに関する多くの情報が見つかりませんでした。そのため、2 人の開発チームがすぐに飛び込んで、C#/ASP.Net でソリューションを開発しました。発生する EDI メッセージ トランザクションの数が少ないため (1 日 100 程度)、解析、検証、およびデータベースへの挿入に RegEx プロセスを採用しました。これは、数分ごとに実行され、クライアントのさまざまなプロバイダー FTP、AS2、EBMX 通信に接続し、データをダウンロードし、アウトバウンド EDI メッセージをアップロードするようにスケジュールされた別の C# アプリを介して行われました。
次に、クライアントのスタッフがさまざまな収益レポートを含むデータに完全にアクセスできるようにする Web フロントエンドを開発し、データを制御し、一部のクライアント エージェントがログインしてデータと対話し、請求書のトランザクションを開始できるようにしました。それも。
クライアントは、ビジネスの別の道のために、さらに EDI 作業を行うことを望んでいますが、今度は edi メッセージ トランザクションが 1000 に跳ね上がります。私たちの開発チームの懸念は、正規表現の使用です。私は最近、EDI 解析に RegEx を使用するとオーバーヘッドが大きくなり、避けるべきであると読みました。
そもそも採用した唯一の理由は、何が最適なのか分からないという経験不足でした。とはいえ、RegEx により、テンプレート内の検証を含め、edi メッセージ テンプレートの管理が簡単になりました。クライアントはさらにいくつかのプロバイダーを本に追加し、数分で新しいメッセージ テンプレートを (カスタムの変更を加えて) 追加することができました。
最近さらに多くの調査を行った結果、ほとんどのソリューションが EDI ファイルを XML に解析することがわかりました。これには理由がありますか？これは、より一般的な形式を採用したり、データベースへのアクセスを回避したりするためのものですか? フラット ファイルの EDI メッセージで XML を解析する方が速いですか?
EDI ファイルのデータ要素をデータベースに入れたいですか? 代わりに XML ファイルを解析するだけでよいでしょうか。これは、回避できる処理のもう 1 つのステップではないでしょうか。
質問が一般的で申し訳ありませんが、答えを見つけるのに苦労しています。
お時間をいただきありがとうございました。
注: 当社の開発チームは Microsoft 製品のみを使用しているため、フィードバックを送信する際はこの点を考慮してください。