Azureサービスバスでトピックに送信中にBrokeredMessagesをデタッチします。

Question

Azureサービスバスで、メッセージ送信に失敗してサブスクリプションが定義されていません。私はEnableFilteringMessagesBeforePublishingをtrueに設定してこれを達成します。これは例外NoMatchingSubscriptionExceptionをスローします。

今、この例外を処理している間、私はそれをDeadLetterしたいと思います。私はBrokeredMessage.DeadLetter()を呼び出した場合、そのメッセージはそのを受信した際にのみ、送信されていないがDeadLetter'edすることができることを意味するメッセージ「ReceiveContext is null」

try 
{ 
    await topicClient.SendAsync(brokeredMessage); 
} 
catch (NoMatchingSubscriptionException ex) 
{ 
    // **throws exception** if message is attempted to move to DeadLetter queue 
    await brokeredMessage.DeadLetterAsync(); 
} 

でInvalidOperationをスローします。

上記の仮定は正しいですか？

いずれの場合でも、失敗したメッセージの送信を処理するための最良の戦略は何ですか。後で調査するために、送信中に失敗したメッセージがDeadLetterキューに残ることがありますか？

おかげ

Answer 1

Deadletterキュー（DLQ）は、メッセージが送信されたキューに関連付けられています。サブスクリプションがない場合（キュー）、関連するDLQもありません。戦略に関しては

、次の2つの質問持っている：

1. を任意の加入者はありますか？
2. 送信操作に失敗したメッセージを処理するにはどうすればよいですか？

最初の質問は、それらのアプリケーションを続行してはいけないと仮定した場合の詳細です。 2番目の質問は、アプリケーションの実行中に確実に起こるものであり、どのような補償処置を取るべきかを決定する必要があります。

個人的には、出版社がないことを絶対に知る必要がある場合を除き、個人的にはEnableFilteringMessagesBeforePublishing機能を有効にする必要はありません（質問1）。メッセージの送信に失敗したのはパブリッシャーがいないのではなく、エラーをキャプチャして、それを制御/レポート用の別のタイプのメッセージとして存在するキューに送信することをお勧めします確かに（つまり、あなたのアプリケーションはそれが存在することを保証します）。