1

これまでのプログラム: 複数のスキーマ、オーケストレーション、メッセージの送受信を含むプロセスがあります。

私たちの願い: 進行状況を SQL サーバー テーブルに記録するときに、プロセス全体をリンクする ID を持つこと。

これまでのところ、進行状況を記録するテーブルがありますが、複数のメッセージがある場合、Biztalk は特定のメッセージを順不同で処理することがあるため、読むのは非常に困難です。

たとえば、次のようにすることができます。

1 client1 の開始プロセス
2 client1 の 2 番目のアイテム
3 client1 の 3 番目のアイテム
4 client1 の最終項目

一度に更新されるクライアントが 1 つだけの場合は、簡単に追跡できます。一方、これはより可能性が高くなります。

1 client1 の開始プロセス
2 client2 の開始プロセス
3 client2 の 2 番目のアイテム
4 client2 の 3 番目の項目
5 client1 の 2 番目のアイテム
6 client1 の 3 番目の項目
7 client1 の最終項目
8 client2 の最終項目

最後のリストをこの ID フィールドで並べ替えることができるように、全体に ID があると便利です。

これを行うための最良および/または最速の方法は何ですか? 最初のオーケストレーションのトリガーの最初の瞬間から ID を追加し、その値をすべてのスキーマとその後のオーケストレーションに渡し続けることを考えていました。これは大変な作業のようで、すべてのスキーマを変更する必要があります。これは間違っているようです。

そのようなIDを持ちたいと思うべきでしょうか? 頭に浮かぶ他の解決策はありますか？

4

5 に答える 5

1

Biztalkは、メッセージコンテキストでさまざまな値を割り当てます。これらの値は、通常、そのメッセージの処理中は存続します。最初のMessageIdなど。それはあなたのために働きますか？

私たちのアプリケーションでは、外部から提供されたID（顧客から）を使用する必要があります。このIDが一部に含まれるマルチパートメッセージがあります。あなたもそれを考慮するかもしれません

于 2011-10-06T18:41:11.640 に答える
1

UniqueId と StepId を作成して、メッセージ コンテキストで渡すことができます。クライアントの新しいプロセスが開始されたら、UniqueId を Guid に設定し、StepId を 1 に設定します。次のプロセスに渡されると、StepId がインクリメントされます。

これにより、クライアント ID とイベントが発生した順序 (stepId) でグループ化されたイベントを照会できます。

于 2011-10-06T14:13:28.607 に答える
1

これは必ずしも最も簡単な方法ではないかもしれませんが、これを見たことがありますか?

http://blogs.msdn.com/b/appfabriccat/archive/2010/08/30/biztalk-application-tracing-made-easy-with-biztalk-cat-instrumentation-framework-controller.aspx

基本的には、パイプライン、マップ、orch などからイベントを発生させることができるインストルメンテーション フレームワークです。

イベントトレースに書き出すときは、あなたが言っているのと同様に、複数のイベントをチェーンで結び付ける「ビジネスキー」を使用できます。

ここから入手可能 http://btscatifcontroller.codeplex.com/

于 2011-10-05T16:04:41.100 に答える
1

BAM を参照してください。あなたが説明したことを正確に行うように設計されています:ビジネス活動監視の使用

この本には BAM に関する非常に優れた章があり、本の著者の 1 人によるこのツールは、BAM ソリューションの開発に役立ちます。そして最後に、素敵なBAM ポスター.

最初の複雑さで先延ばしにしないでください。BAM は、BizTalk の最も優れた機能の 1 つです。

お役に立てれば。幸運を。

于 2011-10-05T20:17:22.460 に答える
1

特定のセットアップのすべての詳細を完全に理解しているかどうかはわかりませんが、次のようになります。

同じクライアントからのメッセージを "長時間実行" オーケストレーション (同じクライアントからの後続のメッセージを待機する) に関連付けることができる場合、オーケストレーションには自動的に割り当てられた ServiceId Guid があり、オーケストレーション全体で保持されます。

あなたが言うように、相関の目的で、通常、既存の受信メッセージ スキーマ内で自然キーを使用して、後続のメッセージを実行中のオーケストレーションに関連付けます。この方法では、スキーマを変更する必要はありません。あなたの例では、同じクライアントが複数のメッセージ「セット」を同時に送信できない場合、ClientId は適切な相関関係になる可能性があります。(最悪の場合、新しい相関キーをスキーマに追加すると、オーケストレーションに関係するすべてのシステムを変更して、このキーを「記憶」して返す必要があります。) ここでも、ClientId を相関キーと仮定すると、この例では、2 つのオーケストレーションが同時に実行されます。1 つはクライアント 1 用、もう 1 つはクライアント 2 用です。

ただし、スケーラビリティとバージョン管理の理由から、(非常に) 長時間実行されるオーケストレーションは、絶対に必要でない限り (たとえば、4 つのクライアント メッセージがすべて受信された後にのみプロセスをトリガーできる場合を除き)、通常は避ける必要があります。各メッセージを個別のオーケストレーションとして保持するか、ポートにマップしてフィルター処理することにした場合、一連のメッセージを「追跡」する別の方法は、BAM を使用することです。継続を使用して、すべてのクライアント メッセージを結び付けることができます。報告の目的など。

于 2011-10-05T16:14:36.920 に答える