7

最近、配信通知に関する非常に奇妙な問題に遭遇しました。シナリオは次のとおりです。

  • 配信通知 = Transmitted で構成された一方向の送信ポートにメッセージを送信するオーケストレーションがあります (ところで、送信ポートは FTP アダプターを使用しますが、アダプターが何であるかは関係ないと思います)。

  • メッセージング エラーが発生すると、エラーはオーケストレーションによってトラップされ (したがって、配信通知メカニズムが期待どおりに機能したことを意味します)、ログが記録されてから、プログラムによって終了します (Terminate シェイプ)。メッセージング インスタンスは引き続き存在し、一時停止され、再開可能です。

  • メッセージング エラーの原因となった問題を解決した後、中断されたメッセージング インスタンスを再開します。

この時点で、2 つの非常に疑わしいメッセージング インスタンスを取得します。ACK のルーティング エラーと、メッセージング インスタンスがまだアクティブです (しかし、何もしていません...)。ルーティング エラー インスタンスは、アクティブなメッセージング インスタンスに関連する配信通知であると確信しています。これらのインスタンスは同じ CorrelationToken を持っているからです。もう 1 つ詳細: アクティブなインスタンスを終了すると、インスタンスは中断され (再開できなくなります)、エラー メッセージには、すべてのメッセージを消費することなくインスタンスが完了したことが示されます。

最後になりましたが、この問題は特定の環境でのみ発生します...

更新: BizTalk 2006 R2 SP1 を実行する BizTalk ボックスで問題が発生するようです。SP1 なしで BizTalk 2006 R2 を実行するボックスでは発生しませんでした。私はこれをできるだけ早く確認しようとします

更新 2 : 前回の更新では正しかったようです: SP1 CU1 のインストール後に問題が発生します...次のステップ: 次の CU のいずれかで問題が修正されるかどうかを確認します。

4

1 に答える 1

1

実際には、説明されている問題を修正する CU はありません。しかし、それ以上のものがあります: すべての新しい BizTalk バージョンが関係しているようです: すべての CU を使用する BizTalk 2009 とすべての CU を使用する BizTalk 2010 でテストを行いましたが、問題はまだ存在します!!!

私が見つけた唯一の解決策は、すべての配信通知をサブスクライブするオーケストレーションを作成することでした...あまりきれいではありませんが、少なくともほとんどの場合、うまくいきます。

実際のところ、配信通知を使用して失敗したメッセージのルーティングを有効にすると、さらに 1 つの問題が特定されました。AckRequired プロパティと相関トークンが、ルーティングされた失敗したメッセージにコピーされます。つまり、この失敗したメッセージが送信ポート (例: ESB 例外送信ポート) によって消費され、この ACK がまだ実行中の場合、元のオーケストレーションにルーティングできること。その場合、オーケストレーションはこの ACK を消費しないため、典型的なゾンビ メッセージの状況で終了します。さて、あなたの開発者が責められるべきではないことをクライアントに説明してみてください... :p

于 2013-04-03T14:11:23.427 に答える