Brokerのメッセージキューにメッセージを書き込むストアドプロシージャがあります。問題が発生してメッセージがメッセージキューに格納されない場合は、ストアドプロシージャからエラーメッセージを返す必要があります。Brokerはメッセージをターゲットキューに入れません。sys.transmission_queue)に入れられます。SENDがコミットされた後、メッセージはバックグラウンドトランスミッタによってピックアップされ、ルーティングは解決され、メッセージはその宛先に配信されます。宛先が同じインスタンス内にある場合は、SENDステートメント自体の実行中にショートカット配信パスが試行されます。この場合、メッセージは宛先キューに直接配置されます。エンキューが失敗すると、メッセージは返送されて通常の配信パスに配置されます。sys.trasnmission_queuに入れてください。transmission_status`を持ちます。システムは自動的にこれらのメッセージを再試行します。SENDがエラーを返すことができるのは、メッセージが_sent_になることができないときだけです。sys.transmission_queue`に受け入れられないようにするブローカ以外のエラー(データベースの読み取り専用、ログフル、メモリ不足など)がある場合です。ローカル配信が非同期で疎結合である場合でも、このようなマッキングの動作は意図的であり、宛先キューがローカルの場合と宛先キューがリモートの場合は同じ動作をすることでアプリケーションを支援するように設計されています。Brokerでエラーを処理する方法は、応答について自分のキューを確認することです。目的地サービスがあなたのメッセージを積極的に拒絶するならば(すなわち。アクセスが拒否された、またはXML形式が不正であった、またはサービス契約違反が発生した場合、エラーで会話が終了し、エラーメッセージが自分のキューに返されます。メッセージを単純に配信できない場合は、メッセージが期限切れになるまで送信キューに留まり、その後会話はエラーで終了し、再びエラーメッセージが自分のキューに入れられます。CONVERSATION`で指定された有効期限が切れるとメッセージはタイムアウトします。そのため、ブローカーを無効にしても、メッセージは受け入れられますが配信されません。それは変換キューに入れられます。データベースでブローカーを有効にするとすぐに、そのメッセージがピックアップされて配信されます。この振る舞いは、配信の信頼性が主な関心事である場合には、アプリケーション作成をはるかに簡単にします。目的地が利用できないとしても、アプリは単にメッセージ_will_がそこに到着することを知っているだけで送信します。メッセージの配信に数時間、数日、または数週間かかる場合でも、サービスのメンテナンスのために停止されます。配信のタイミングにも関係するアプリケーションの場合は、会話の有効期間を指定する必要があります。システムはこの有効期間内にメッセージを配信しようとするか、あきらめます。あきらめた場合は、エラーメッセージ(会話タイムアウトエラー)をエンキューすることによって送信者に通知します。アプリケーションは応答を待つべきではありません。COMMIT`そして続けるべきであり、_イベントドリブン_です。ターゲットが応答を送り返したとき、または基盤となるインフラストラクチャがエラーを通知したとき、アプリケーションは自身のキューにメッセージを取得し、そのメッセージに_反応するはずです。