1

現在、既存のアプリケーション (BizTalk 2004) を新しいバージョンの BizTalk に移植しています。現在のソリューションは、複数のタイプの EDI ドキュメントを受け取り、必要に応じて変更し、レガシー システムに送信してロードおよび処理します。

このプロセスは、受信ポート、パイプライン コンポーネント、送信ポートとマップ、スキーマおよびメッセージ キュー コンポーネントの組み合わせを使用して開発されます。このソリューションは、10 個の送受信ポートを使用して、個々のメッセージへの EDI のバースト、メッセージの変換、エラー処理、EDI 検証、EDI メッセージのバッチ処理など、プロセスのさまざまな側面を処理します。EDI のすべての変更は、メッセージ キュー コンポーネントを使用して行われます。

このソリューションは、オーケストレーションをまったく使用しません。現在のソリューションを BizTalk オーケストレーションとして実装することを検討しています。オーケストレーションについて少し読み、いくつかのサンプル アプリケーションを試しました。しかし、オーケストレーションを使用せずにソリューションを開発できる場合、オーケストレーションを使用する利点についてはまだ非常に混乱しています。ここで何かが欠けていると確信しています。オーケストレーションによって、現在のソリューションでは得られない追加のメリットは何ですか?

編集:...質問を明確にする必要があります...コンテンツベースのルーティングとマップを使用して、オーケストレーションを使用せずにこのアプリを実行できます。私の質問は、オーケストレーションを使用しないことで何か不足している場合は?

4

2 に答える 2

3

メッセージ ベースのルーティングを使用して手元のタスクを実行できる場合、オーケストレーションはやり過ぎです。
オーケストレーションは、ルールの呼び出しやトランザクションの処理に役立ちます。次の点は、オーケストレーションを使用するかどうかを決定するのに役立ちます。

  1. 取り扱いはTransactionalですか
  2. メッセージの順序は重要ですか
  3. ビジネスルールを使用してメッセージを処理しますか?
  4. 外部アセンブリを呼び出す必要がありますか

「Microsoft BizTalk Server パターン」より引用

オーケストレーションにはかなりのコストがかかります。これらのコストの多くは、メッセージボックスへのラウンドトリップとして現れます。つまり、プロセスの境界を越えて、データベース (メッセージボックス) への書き込みと読み取りを行うことを意味します。

オーケストレーションでは、同じプロセスに 2 倍の時間がかかる可能性があります。例: メッセージを受信して​​送信する単純なプロセスでは、メッセージング アプローチでは 2 回のメッセージ ホップが行われますが、オーケストレーションでは 4 回ホップされます。メッセージのみのソリューションの手順は次のとおりです。

  1. アダプター経由でメッセージを受信し、メッセージ ボックスに保存します
  2. 送信ポートのメッセージを取得する

対:

オーケストレーション アプローチの手順

  1. アダプタ経由でメッセージを受信し、メッセージ ボックスに保存します
  2. メッセージを取得してオーケストレーションを開始する
  3. 必要に応じてマッピングを行います
  4. 送信ポートのアイテムを再度取得します。

賢く選ぶ

于 2014-05-22T20:50:42.927 に答える
1

メッセージングのみのソリューションでソリューションを再実装でき、オーケストレーションは必要ないようです。よろしければ、メンテナンスが簡単で、一般的により効率的であるため、メッセージングのみをお勧めします。オーケストレーションは、複数のアクションのワークフローが必要な場合や、メッセージングのみのソリューションでは簡単に実行できない特別なエラー処理が必要な場合に役立ちます。

于 2014-05-22T20:49:34.567 に答える