50のサプライヤーとのやり取りを作成し、夢中にならない方法

サプライヤーは異なります。 私たちのフォーマットに適応する準備ができている人もいれば、そうでない人もいます。 いくつかはSOAP'omを交換し、他はREST'omを交換します。 製品コードを扱うものもあれば、オファー識別子を扱うものもあります。 リクエストに応じてステータスを提供する準備ができているものもあれば、そうでないものもあります。 いくつかのディレクトリにはディレクトリがありますが、その要素は自分のものと一致させる必要がありますが、他のものにはありません。 一般的に、非常に異なっています。









サプライヤーとのコミュニケーションを自動化する必要があります。 21世紀の庭。 理想的な世界では、この業界のサプライヤーと消費者の会議（私の場合は自動車部品）を開催する必要があることは明らかです。そこでは、情報交換のための単一のフォーマットに同意する必要があります。 薬剤師はこれを持っています。 しかし、私たちは不完全な世界に住んでいます。



誰もが最初のアイデアを持っています。サプライヤは、ディレクトリの要素を提供する準備ができており、注文を受け入れる準備ができています。 しかし、すべてのサプライヤ、ビジネスプロセスには独自の特性があり、これによりサプライヤAPIに異なる初期要件が課せられ、それらを実装するさまざまなプログラマは、異なるサプライヤのAPIには初期のアイデア以外の共通の機能がないという状況をもたらします。



50のフォーマットで取引所を書く方法は？ 50件の交換を作成しますか？ 最良のケースでは、1つのサプライヤとの交換を1週間記述し、テストする必要があり、プログラマのレートは3000r /時間であると仮定しましょう。 乗算？ そして、私はまだこのすべての動物園のサポートと管理を覚えていませんでした。



他のオプションはありますか？ 私の答え：交換を1つ書いてください！



51番目のサプライヤを見つけて、彼とのやり取りを書かなければなりません。 私たちにとって、そして私たちのプロセスにとって理想的なサプライヤーでなければなりません。 このサプライヤには、詳細が異なるすべてのサプライヤに共通の機能が必要です。







「サプライヤーから」ではなく、「私たちから」と考え始めなければなりません。そして、状況はすぐに単純化されます。 ビジネスプロセスもプログラマも1つあり、私たちの意見で合理的な範囲を超えるものはすべて、特に興味深いものではありません。 そのようなアプローチは必然的に論理の「粗大化」につながり、ある種の「薄い」機能がナイフの下に行くことは明らかですが、これは単純さの代価です。



このような粗面化には、3つのタイプがあります。

• 一部のサプライヤーが提供する準備ができていない機能
• サプライヤーが提供する機能ですが、必要ではありません。
• サプライヤごとに根本​​的に異なる方法で実装される機能。

理想的なサプライヤを発明するにあたり、サプライヤのAPIに関するサプライヤのドキュメントを作成し、理想的なサプライヤのAPIを開発する4つの基本的な方法を開発しました。

方法1：一般化

一般化は、あらゆる種類の機能を開発する基本原則です。 サプライヤーとの交換も例外ではありません。



たとえば、あるサプライヤは、注文のステータスを「受け入れ済み」、「稼働中」、「出荷済み」、「拒否済み」として使用できます。 別の「管理者の作業中」、「倉庫の作業中」、「運送会社の作業中」、「正常に閉鎖」、「キャンセル」。 また、別のサプライヤーとの27の異なるステータスを見ました。 真剣に、私はそれらを具体的に数えました。 私たちのシステムでは、この動物園全体が必要ないことは明らかです。 ステータスを、「新規」、「仕入先の作業中」、「仕入先から出荷済み」、「問題」など、当社に必要な最小限のセットにまとめます。



次に、各サプライヤのディレクトリの各要素をディレクトリの要素と比較するだけです。

方法2：分離

すべてを一般化することはできません。 時々あなたは分離する必要があります。



たとえば、1つのサプライヤが注文全体（1つのXMLのすべての注文明細）を受け入れ、もう1つがオンラインストアバスケットの原則に従って（バスケットに商品を追加する-バスケットに商品を追加する-バスケットを注文する）場合、これを何らかの「一般的な」方法で書くことはできませんうまくいきます。



この場合、理想的な51番目のサプライヤーとの交換は分割されるべきです。 つまり 必要に応じて、どちらかの方法で注文を送信できる必要があります。 私にとってこれは「注文の送信方法」と呼ばれ、「完全に注文する」と「行ごとに」という2つの意味があります。

また、「ステータスチェック方法」の設定もあり、「注文によるリクエスト-注文による返品」、「注文によるリクエスト-行による返品」、「行によるリクエスト-行による返品」の3つのオプションが既にあります。



しかし、個々の断片化はシステムの複雑化につながるため、分離に関与することはあまり価値がありません。 そして、絶対にすべきでないことは、ツリーのような分離を許可することです。 すべてをフラットな設定に減らすようにしてください。 機能の断片化が別の基盤の断片化に依存する場合、設定を掘り下げ、エレガントなシンプルさの代わりに設定の地獄を取得します。

方法3：クリッピング

クリッピング方法は直感的であり、プロバイダーの機能が必要な機能を超える場合に適用されます。



たとえば、サプライヤは、特定のポイントまで（たとえば、セットに転送される前に）注文を編集する機能を提供できます。



しかし、これは私たちにとって特に興味深いものではなく、他のすべてのサプライヤーにはそのような機会がないので、この機会を利用しないと言う必要があります。

自動化の境界を明確に定義する必要があります。 それらの範囲を超えるものは考慮から除外されるべきです。 「これは追加の利便性です」という議論は無視してください。残りのサプライヤを省くことができれば、これを行うことができます。

方法4：デフォルト

デフォルトの方法は、クリッピング方法の逆極端です。 この場合、問題は自動化フロンティアにプロバイダーがサポートしていない機能が含まれていることです。 たとえば、注文のステータスを返す。 一部のベンダーはこれをサポートしていない場合があります。



この場合、サプライヤは返品方法を知らないため、後続のすべてのアルゴリズムで注文のステータスが最新であると見なされるか無視されるかを確認する価値はありません。 そのような注文を最後に成功したステータスに変換する「スタブ」を配置する方がはるかに簡単です。



したがって、ニーズと機能を分析することにより、自動化の境界を描くことができます。 これにより、理想的な51番目のプロバイダーのAPIの設計段階が完了します。 つまり、テクノロジーを使用する場合、システムにはまだ50のサプライヤーが存在しますが、データのアップロード/ダウンロードコードは同じであり、50のサプライヤーすべてに対して51番目のプロバイダー形式でXMLを生成します。



そのため、この記事では、取引所の最も可変で複雑な部分（少なくとも私にとって）のように注文のアンロードに焦点を当てましたが、書かれたものはすべて、注文データとマスターデータの両方のロードとアンロードに適用できます。他のもの。



次に、理想的な51番目のプロバイダー用にアップロードファイルを最適に配置する方法を検討する必要があります。

• まず、XMLである必要があります（理由-後で明らかになります）。
• 次に、この注文でのみアップロードできるデータの最大量を含める必要があります。 つまり この段階では、注文が最終的に予定されているサプライヤのVATレートを示す必要があるかどうかは関係ありません。必要なすべてをアンロードする必要があります。
• 第三に、変換可能な値を変換する必要があります。 つまり たとえば、理想的な51番目のサプライヤのXML形成の段階で、たとえば、注文が予定されているサプライヤの製品識別子を置き換える必要があります。 このためのすべてのデータは順序どおりであるため、これにより問題が発生することはありません。

したがって、サプライヤが注文を受け入れるために必要なすべてのデータを含むファイルを取得する必要がありますが、わずかに無効な形式です）

それでは、どのように機能しますか？

理論からビジネスへ、理想的なサプライヤから実際のサプライヤへと移行する時です。 興味のある人なら誰でも、私たちが手に入れたXMLは、1つの形式から50を得るために巧妙な方法で変換されるとすでに推測していると思います。

• XSLT
• フォーマットコンバーター

まず、データ構造自体を作成する必要があります。 XMLは、XMLドキュメントをあるビューから別のビューに変換できる強力なXMLドキュメント変換言語（XSLT-eXtensible Stylesheet Language Transformations）を備えているため、これに最適です。



言語は複雑ではなく、数日で基本的なレベルで習得でき、私のXSLTの99％がvalue-ofおよびfor-eachの2つの命令のみを必要とします。



さらに、作成された構造は、XML以外の形式に変換する必要がある場合があります。 この意味で、XML <-> JSON変換は最も難しいようです。そのような変換の例をレイアウトしました。 （ただし、UFOがInfostartへのリンクをここに挿入することを禁じているため、ここでは表示しません）XMLからGETリクエストパラメータへの変換もあります。 次のような行に？item = 12345＆qty = 4＆price = 19.50ですが、すでに非常に簡単です。 このステップの結果として、特定のサプライヤーに有効な交換テキストが表示されるはずです。



交換用の有効なテキストを受信した後、送信するだけです。 このタスクには、条件付きでユニバーサルダイヤラーと呼ぶ機能が関与しています。 彼女は、設定SOAPまたはRESTサービスを呼び出して、コンバーターの結果を転送できます。 ダイヤラーは非常に異なるシナリオを提供する必要があります。データをパラメーターとして、要求本体、POSTメソッドおよびGETメソッドとして、基本的な権限とそれほど権限のない権限で送信する準備ができている必要があります。



理論的には、少なくともExcelの読み取り/書き込みをダイヤラに結び付け、ニーズに合わせて特定の「コネクタ」を選択できます。



原則として、理想的な51番目のプロバイダーのフォーマットでデータを取得する機能、XSL変換、フォーマットコンバーター、ダイヤラーは、この機能を既存のシステムにリンクせずに、別のインスタンスに取り出すことができます。 これをInterface Converterと呼びます。



Interface Converterコードは300行に収まります。 基本設定（XSLTテキスト、変換および呼び出し設定）はデータとして保存されます。 その結果、サプライヤに注文を送信するプロセスは次のとおりです。

• ERPは注文を生成し、51番目のサプライヤの形式でInterface Converterに送信します
• コンバーターは、51番目のプロバイダーの形式でXMLテストを受け取り、それを強化します
• 要求を送信するプロバイダーを（条件付きで、インターフェイスコードによって）決定します-オンザフライでXSL変換と形式変換を実行します
• 変換されたリクエストをすぐにサプライヤに送信します
• サプライヤーからの応答を受け取ります
• 応答本体から逆順で、形式変換、エンリッチメント、そして理想的なプロバイダーの応答形式へのXSL変換を実行します
• ERPへの理想的なプロバイダーの応答を返します

これはすべて「オンザフライ」で発生します。 同期的に、すなわち ERPは、何かが間違っていることに気付かずに、便利な1つの形式ですべてのサプライヤーと交換していると考えています。 もちろん、このアプローチは、比較的小さなデータパケットの送信にのみ適用できます。 1 GBの価格表がある場合、このストーリー全体に非同期を固定する方法を検討する必要があります。

濃縮チップ

ほとんどすべての交換には、単にハードコーディングされた値があります。 これは、一部にはサプライヤの機能が多すぎるためである可能性があります。たとえば、パラメーター「追加の調整なしで商品の価格を引き上げることができる割合」などです。一部は、これらは「for you it always always」のような値です。 4000とは何ですか？ なぜ4000 わずか4000とそれだけです。 このような「デッド」値をERPに保存しないようにするために、コンバーターは他のXMLでERPデータを強化する機能を備えています。 つまり インターフェイスコンバーターデータベースに格納されるのは、任意のXMLです。



各インターフェイス（プロバイダー）には独自のXMLがあります。 共通タグ内のラッパーを使用した単純な接着の原則に従って、追加の強化が行われます。次に例を示します。

<body>   <ERPData>     ...<i>  ERP</i>...   </ERPData>   <AdditionalData>     ...<i>  </i>...   </AdditionalData> </body>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、このような強化されたXMLは、XSLTエンジンの入力に送られ、ERPから送信されたデータと静的データの両方が利用可能になります。

その結果、何が得られますか？

理由もなくこの庭全体をフェンスで囲み始めたのではなく、サプライヤーとの接続時間を短縮したかったからです。 新しいプロバイダー接続は次のとおりです。

• APIドキュメントの探索
• ERPでの適切なプロバイダーの作成とその構成（約10個のチェックマーク）。
• XSLT Exchangeテキスト変換の説明
• フォーマット変換の説明（必要な場合）
• 発信接続設定（さらに10個のチェックマーク）。

実際には、これらすべてのアクションには最大3時間かかります。 サプライヤが何かを「ある種」考えていることは明らかですが、95％のケースで2〜3時間以内に会うことができます。 （この文章を間違えて、「サプライヤー」の代わりに「代理」と書いた。偶然か？..）



当然、詳細とニュアンスはまだたくさんありますが、レビュー記事のフレームワークでは語ることはできませんが、記事の目的は、マルチフォーマット交換アーキテクチャの設計に対する可能なアプローチの1つを示すことであると思います。