5

バックグラウンド：

ここ (BizTalk 2009) で説明されているSeroter のラウンド ロビン手法と同様に、多くの集約、シングルトン、マルチトン オーケストレーションを利用しています。

これらのすべてのオーケストレーション タイプには、かなり任意の終了ポイントまたは継続ポイント (集約用) があり、通常はタイマーによって定義されます。つまり、Orch が X 分以内にそれ以上メッセージを受信しなかった場合はバッチ処理を続行し、さらに Y 分経過した場合はバッチ処理を続行します。経過し、メッセージがなくなったら終了します。(一定期間に多数のメッセージがシングルトンにサブスクライブされた後のパフォーマンスの低下に関する懸念から、シングル/N-トンも終了します)。

非同期にリファクタリングされたオーケストレーションで継続処理を開始するなど、ゾンビを軽減しようとしてきた限り、「適切な」タイミングのメッセージがゾンビを引き起こす可能性があるという弱点が常にあります。(つまり、オーケストレーションの「すでに完了している」形状に関連する着信メッセージをより多く受信する)、

メッセージがサブスクリプションの 1 つでゾンビを引き起こした場合、そのメッセージは他のサブスクライバーにも伝搬されないように見えます (つまり、「ゾンビを引き起こす」オーケストレーションから完全に切り離された orch)、つまり、ゾンビを引き起こしたメッセージは処理されません。

質問

したがって、オーケストレーションがこの相関メッセージに関心のあるポイントを超えて「進行」した後、プログラムまたはその他の方法で、実行中のオーケストレーションから相関サブスクリプションを明示的に削除する別の方法があるかどうかを確認することに非常に興味があります。(この新しいメッセージは、通常、独自の相関などを使用して新しいオーケストレーションを開始します)

この時点で、リフレクトされた BizTalk API 呼び出しや、MsgBoxDB に対する直接の SQL 削除などのハック ソリューションも検討します。

4

1 に答える 1

1

いいえ、Orchestration でサブスクリプションを明示的に削除することはできません。

オーケストレーションがそれ自体を解体しているため、サブスクリプションは削除されますが、その正確なインスタンスに到着したメッセージはオーケストレーションにルーティングされますが、オーケストレーションはそれを処理せずに終了します。それがあなたのゾンビです。

ゾンビに関するマイクロソフトの記事http://msdn.microsoft.com/en-us/library/bb203853.aspx

受信、デバッチ、集約、送信のパターンも必要でした。複数の送信者からエンベロープ メッセージを受信し、それらをデバッチし、目的の受信者別に集計します (2 つのルール、メッセージ数または時間遅延のいずれか早い方に基づく)。このシナリオはゾンビにとって機が熟していたので、ゾンビについて読んだときに、それが起こらないように設計しました。これは BizTalk 2004 用で、メッセージをデバッチし、データベースに挿入しました。受信ポートによってポーリングされるストアド プロシージャがありました。送信するバッチがあれば、そのメッセージを取得して動的にルーティングするオーケストレーションをトリガーする場合に機能します。どちらのオーケストレーションも別のメッセージを待つ必要がないため、正常に終了でき、ゾンビは発生しません。

于 2013-08-21T04:50:03.733 に答える