前の職場では防弾少年団をかなり使っていました。しかし、管理者はしばしばそれを間違った目的で使用したいと考えており、開発者はそれを採用することをためらっていることに気付きました。
それで、BTS はどのように使われているのでしょうか。理論ではなく経験を投稿してください。ありがとう!
私はヨーロッパ最大の石油/エネルギー会社のコンサルタントとして働いていましたが、基本的にすべてのメッセージング/統合に BizTalk を使用しています。例としては、さまざまな形式でパートナーとの間で送信される請求書 (電子請求書)、独自のユーザー名データベースを維持する AD とサードパーティ ソフトウェア間のジョブの同期、サポート システムと外部顧客との電子メールによる統合などがあります。そのため、彼らは BizTalk をかなり幅広く採用しており、5 台のサーバーのクラスターを使用しています。
BizTalk を使用して、サード パーティの注文システムに接続しています。これはおそらく、BizTalk が提供しているように思われる膨大な機能を使用するための、有用でありながら初心者向けのアプローチであると分類できます。これは、機能の一部しか使用していないことを意味します。次のようになります。
このソリューションは最終的にかなりうまく機能し、数年前から運用されています。それはうまくいくものの1つです。
私が注意すべきことの 1 つは、これを開発している間、Mapper ツールを使用して翻訳部分を支援しようとしたことです。私たちの翻訳は非常に複雑で、ツール自体を使用するのは非常に面倒でした。私たちは xslt に慣れていたので、グラフィカルな Mapper ツールを使用せずに、独自に作成することになりました。Mapper ツールは単純な翻訳には非常に便利なようですが、少数の要素を超えるものはメンテナンスの悪夢 (IMHO) になり始めます。
対話する必要があるアプリケーションが数十あります。システム間のメッセージの受け渡しを制御する単一の Web サービス ベースのアプリケーションがあります。他のシステムは、BizTalk オーケストレーションなどを介して、それと対話し、そこからメッセージを受信します。
私の会社では、BizTalkを大規模なドキュメント翻訳エンジンとして使用しています。サプライチェーンドキュメントのEDI、XML、フラットファイル処理を行います。私たちはドキュメントブローカーのシナリオで行動しており、BTを使用して任意の形式のドキュメントを受信し、それらを他の形式に変換して、任意の取引先にルーティングします。
そのため、2つのトレーディングパートナの各ペアがEDIオンボーディング演習を行う代わりに、各トレーディングパートナを仕様に合わせてオンボーディングし、翻訳エンジンを使用して、静的な形式でドキュメントを送受信できるようにします。内部的には、それらのフォーマットを正規のスキーマにマッピングしてから、相互にトレーディングパートナをプラグアンドプレイします。ハブアンドスポークドキュメントネットワークについて考えてみてください。
BizTalk 2006 を使用して、さまざまなソースおよびさまざまな種類 (CSV、固定幅、XML) から大小のデータ ファイルをインポートします。BizTalk の優れた機能の 1 つは、フラット ファイル逆アセンブラーだと思います。ウィザードを使用してフラット ファイルの構成を記述することができ、この表現は XML スキーマ定義 (.XSD) として保存されます。ウィザードを使用すると、行自体のインジケーターに基づいて、さまざまなタイプ (したがって長さ) の行を含む可能性のある単一のファイルを解読することもできます。クール。
-クリップ
過去に、B2B 環境で e コマースの目的 (注文、注文確認、配送通知など) に BT (2004) を使用しましたが、非常にうまく機能しました。これはおそらく、組織内で BT が座る最も明白な場所であるという点で、BT の主力です。
最近、私は完全に社内の BT プロジェクトに (ほぼ) 関与しています。このプロジェクトは、最初はレガシー システムから新しいアプリへの大量のデータ ロードを処理し、今後は別のレガシー アプリと同じ新しいシステム間のメッセージングを処理します。おそらく最も効率的なテクノロジの使用方法ではありませんが、「ビジネスの救世主」と見なされる Enterprise Service Bus タイプのアーキテクチャを実装するためのインフラストラクチャが整っています。しかし、私はまだその考えに納得していません。:S
現在、当社では BizTalk 2006 を使用して、Commerce Server 2007 インスタンスと、すべて Dynamics RMS を実行している多数の店舗からの注文をメインの ERP である Dynamics NAV に伝達しています。BizTalk は確かに強力なソリューションですが、学習曲線がかなり急勾配であると考えており、Microsoft が作成したサーバーの中で最も複雑であると述べている StackOverflow の他のユーザーに同意します。
それが何をするかについては、それは堅実であり、システムに問題があった場合、それはチェーンの一方の端または他方の端にありましたが、BizTalk では決してありませんでした.
個人的に開発したもの:
調達: 病院のさまざまな製造会社への購入要求を処理します。これらの企業は、さまざまな xml 要求をさまざまな企業に送信し、各メーカーは独自のスタイルを持っています。その後、すべての購入は、何がどの価格で購入されたかを示す html/xslt レポート (社内レシート) にも作成されました。
HL7: 一度に処理される膨大な量の HL7 ファイルを処理し (一度に 4 つ処理するように設定されていると考えてください)、処理してその日の新しいフォルダーに配置します。
HL7 アクセラレータを使用していくつかの Hl7 ソリューションを開発し、請求申請システムのワークフローを管理し、メッセージ ルーティングの一般的なアプローチを使用して異種システム間の統合を行いました。
とても楽しく、たくさんの仕事をしています... ;-D