2

私の会社はメッセージングインフラストラクチャにBizTalkを使用することを検討しており、それが良い候補になるかどうかだけ興味がありました。

まず、私たちは.NETショップであり、医療トランザクション処理を処理します。現在、すべての製品は、実際には共通のコードを使用せずに目的を達成するように作成されています。これらのトランザクションのほとんどは、標準のTCPソケットを介して行われます（モデルとしてMLLPを使用するHL7を考えてみてください）。次に、これらを処理し、ソケットを介して処理するために1つ以上のサードパーティに送信する場合があります。最後に、トランザクション応答をお客様に送り返します。このように動作するアプリケーションはかなりの数あり、統一されたプラットフォームに配置しようとしています。

これは、非常に高速に動作し（場合によっては6秒未満）、スケーリング中のフォールトトレラント性が非常に高いために必要です。これがBizTalkが優れているところだと言われています。

私の質問は、BizTalkの専門家ですが、これはBizTalkでうまくいくように聞こえますか？そして、このような移行のためにあなたが与えることができる他のアドバイスはありますか？

4

1 に答える 1

6

FWIW、私の見解：

お客様の要件に関する Biztalk の強み

  • メッセージのマッピングは簡単で、ビジュアル マッピングまたは xslt を選択できます。
  • 開発の均一性 - 開発チームが学習曲線を克服すると、ほとんどのタイプの EAI 作業に集中型プラットフォームが可能になります (つまり、既存のメッセージとプロセスを活用できる新しいアプリケーションを Biztalk サーバーに追加し続けることができます)。
  • トランザクションの信頼性 - BizTalk のプラグをほとんど抜くことができ、データを失うことなく状態を回復することができます。
  • プロトコルに依存しない - 内部的にはすべて XML から Biztalk へ。アプリを書き直すことなく、すぐに使用できる幅広いアダプターを使用して、「特別なニーズ」の顧客に対応できます。
  • メンテナンスの少ない操作 - アプリの展開とデバッグ、運用環境の調整、SQL と監視 (SCOM など) のメンテナンス タスクのセットアップが完了すると、BizTalk はアプライアンスのように動作します。
  • スケーラビリティ (有料) - BizTalk には、スケールアップのための多くのノブがあり、スケールアウトのために複数のサーバーを追加できます。ただし、ほとんどの場合、ボトルネックは基盤となる SQL Server であることがわかっています。

弱点

  • レイテンシー/最大処理時間を保証するには、いくつかの課題があります。たとえば、BizTalk が極端な負荷にさらされている場合は、メッセージのバックログがキューに入る原因となるスロットリング状態を回避するために、十分に考慮する必要があります。
  • 動的ルーティングは、特定のプロトコル/アダプターでは少し不安定です。フィルターを使用して多数の静的送信ポートを管理するのが面倒になる場合は、通常、独自のコードの一部をブレンドする必要があります。たとえば、100 のサード パーティの宛先 [たとえば資金] と 10 000 の顧客 [たとえば医師/病院] がある場合、資金から医師へのメッセージ フローのルーティングは面白くありません。「多」側から発信されたメッセージ フローを維持でき、同期プロトコルを使用できる場合は、ルーティングの問題を回避できます。

FWIW 私は医療環境で BizTalk を使用しましたが (ただし、スイッチではなく資金面で)、それほど多くの課題はありませんでした (つまり、3 つの異なるスイッチにルーティングするだけで済みました)。6秒未満の要件は、リアルタイムの薬局認証などのためだと思います。私が行うことの1つは、リアルタイム処理とバッチ処理（クレームバッチなど）を異なるプロセスホスト、または完全に異なるサーバーに分割することです。これにより、同じ低遅延要件を持たない可能性のある大きなバッチ (クレームなど) の到着によって引き起こされる同期処理 (薬局認証など) の遅延の可能性を回避できます。

于 2012-07-17T04:15:49.347 に答える