非同期ビジネス イベントの追跡
非同期 (を使用 BufferedEventStream) - このモデルでは、パフォーマンスが大幅に向上します。 このモデルでは、同期モデルに似た API を使用します (使用するコンストラクターだけが異なります)。 BufferedEventStream は、データをプライマリ インポート データベースにプッシュするのではなく、イベント データをバイナリ形式でメモリに蓄積してから、そのデータを 1 つのテーブル レコードとして中間処理用のデータベース (メッセージ ボックス データベース) に挿入します。 イベント バス サービスは、BizTalk によってメッセージ ボックス データベースのキューに格納されたデータを読み取り、そのデータをプライマリ インポート データベースにインポートします。
非同期操作用に BAM を構成するには、イベント バス サービスと呼び出し元のアプリケーション (たとえば、オーケストレーション ホスト) を異なるコンピューター上で実行する必要があります。 これにより、呼び出し元のアプリケーションは、別のコンピューター上の CPU を使用して処理されるイベント データをすぐに削除できます。
この BAM トポロジには、トランザクションとしての一貫性もあります。 コミットされたデータをメッセージ ボックス データベースから読み取るのはイベント バス サービスだけなので、呼び出し元のアプリケーションにロールバックされたトランザクションの BAM データを取得することはありません。 コミットされたトランザクションの BAM データは、短い待機時間でクエリおよび集計に表示されます。
エラーが発生した場合、イベント バス サービスでは、数回の再試行、タイムアウトの使用、復旧ロジックのクラッシュなどが生じます。 ただし、データの形式が無効な場合、そのデータは最終的には特殊なテーブルに格納されます。 この状況を示すために、イベント ログにイベントが記録されます。 このように追加のエラーが発生すると、システムを管理するのが難しくなります。
通常、コードから非同期的な方法を使用することは、DirectEventStream を BufferedEventStream と置き換え、BAM プライマリ インポートではなくメッセージ ボックスに対してコンストラクターで接続文字列を渡すことと同様に単純な操作です。
コードでの非同期ビジネス イベントの追跡に関しては、次のガイドラインに従ってください。
アクティビティが複数のアプリケーションにまたがっていて、BAM に非同期にデータを送信するときは、すべてのコンポーネントに ActivityID を伝達する場合でも、必ず Continuation を使用します。 この場合、アプリケーションごとに一意の文字列 (アプリケーション名など) をプレフィックスとして付けることで、ActivityID を使い分けます。 複数のアプリケーションから BAM にランダムにデータが到着することがあり、BAM では、そのような場合にも正しいクエリと集計の結果を得るために、適切な順序になっていないイベントを管理する必要があります。このため、ID の使い分けが必要になります。
イベントを監視するための一般的な方法 (たとえば、COM+ 疎結合イベントや WMI イベント) は、イベント データがトランザクションに依存していないため、BAM には適用できません。 たとえば、受け取ったのは 1,000 ドルの注文書 1 件だけなのに、その注文書をデータベースに保存する処理に 10 回失敗したために、注文書を 10 件 (合計金額 10,000 ドル) を受け取ったように見える場合があります。