3

Id をログに書き込むことができるように、ハンドラー内で msmq メッセージの Id を取得する必要があります。

メッセージがエラー キューに送信されると、失敗したメッセージを通知する電子メールが送信されます。メッセージの原因となったエラーが解決されたら、'ReturnToSourceQueue' NServiceBus ツールを使用してそのメッセージを再試行する必要があります。その Id をログに記録しないと、メッセージ キューを調べたときにどのメッセージがどれであるかを追跡するのが難しくなります。

ComputerManagement->Services and Applications->Message Queuing->[Some Queue]->Queue のキューを見ると、Bus.CurrentMessageContext.Id がメッセージ ID 列にあるのと同じ Id を提供することがわかりました。メッセージ。ただし、これらの ID は同じではないようです。

私は何が欠けていますか？

4

2 に答える 2

3

MMC プラグインまたはキュー エクスプローラーで表示されるメッセージ ID が異なる理由は、メッセージがエラー キューに "移動" されると、実際には同じ本文とヘッダーを持つ新しい MSMQ メッセージが作成され、エラー待ち行列に送られます。

また、メッセージの処理が失敗した場合、NServiceBus は既にこれをログに記録し、メッセージの ID を含めているため、既に完了しています。

ログに記録された ID を取得して ReturnToSourceQueue ツールに渡すと、すべてが機能します。

パズルの最後のピースは、メッセージが失敗したときにメールを送信することです。データベースがオフラインになったり、サードパーティの Web サービスが応答しなくなったりすると、運用チームにスパムを送信する可能性があるため、これが最も賢明なアイデアであるかどうかはわかりません。それでも、それがあなたのやりたいことなら、エラーがログに記録されたときにメールアペンダーを使用することをお勧めします。

最後に、この種の通知機能をNServiceBus 周辺の特定のサービス プラットフォームに組み込む過程にあることをお伝えします。エラーを表示し、メッセージを再処理できるようにする UI は、2013 年 11 月にベータ版として提供されます。通知機能は、おそらく年末に向けて準備が整う予定です。

待つか、自分で構築するかは本当に問題です。

于 2013-10-05T09:28:06.647 に答える
0

ハンドラーでバスのインスタンスを作成するだけです。

public IBus Bus { get; set; }

次に、それを使用してメッセージ ID を取得します。

this.Bus.CurrentMessageContext.Id

Bus インスタンスは、ハンドラーが呼び出されたときに挿入されます。

編集

実際に質問を読んだ今...

CurrentMessageContext.Id は、メッセージ ヘッダーの CorrId フィールドの下にあるものを返します。これは、Server Management の [ラベル] 列で確認できます。

MessagId 列に表示されるメッセージ ID は、送信側コンピューターに存在していたメッセージ ID です。CurrentMessageContext からこの値にアクセスする方法はわかりませんが、ローカル メッセージを見つけるためにこれを行う必要はありません。

于 2013-10-04T08:10:02.630 に答える