Sql Server Service Brokerの外部アクティベーションメカニズム（FeaturePackのServiceBroker External Activatorを介して）を使用する実際の本番アプリケーションを展開した人からのガイダンスが必要です。
現在の考え方：
私のスペックはかなり単純です（または少なくとも私はそう思います）ので、私は次の基本的なフローを考えています：
注文のようなエンティティは、状態が「確認済み」のTable_Ordersに挿入されます
SP_BeginOrderが実行され、次のことを行います。
- トランザクションを開始します
- Service_HandleOrderStateからService_PreprocessOrderへのDIALOGを開始します
- 会話ハンドル（今後はPreprocessingHandle ）をOrdersテーブル の特定の列に格納します
- PreprocessingHandleを使用して、注文IDを含むタイプMessage_PreprocessOrderのMESSAGEを送信します
- トランザクションを終了します
私は会話を終わらせないことに注意してください、私は「ファイアアンドフォーゲット」を望んでいません
Queue_PreprocessOrderのイベント通知は、次のことを行うPreprocessOrder.exeのインスタンス（最大同時実行数は1）をアクティブにします。
- SqlTransactionを開始します
- Queue_PreprocessOrderから上位1つのMESSAGEを受け取ります
- メッセージタイプがMessage_PreprocessOrder（フォーマットXML）の場合：
- メッセージ本文の注文IDを使用して、 Table_Ordersで注文状態を「前処理」に設定します
- n個のカルテシアン積を計算するデータのn個のコレクションをロードし（Linqを介して、これはT-SQLでは不可能です）、注文アイテムのコレクションを決定します
- 注文アイテムの行をTable_OrderItemsに挿入します
- PreprocessingHandleを使用して、同じ注文IDを含むタイプMessage_PreprocessingDoneのMESSAGEを送信します
- PreprocessingHandleに関連する会話を終了します
- SqlTransactionをコミットします
- Environment.Exit（0）で終了します
- Queue_HandleOrderStateの内部アクティベーションは、次のようなSP（最大同時実行数1）を実行します。
- トランザクションを開始します
- Queue_InitiatePreprocessOrderからトップ1のメッセージを受け取ります
- メッセージタイプがMessage_PreprocessingDoneの場合：
- メッセージ本文の注文IDを使用して、 Table_Ordersで注文状態を「処理中」に設定します
- Service_HandleOrderStateからService_ProcessOrderItemへのDIALOGを開始します
- 会話ハンドル（今後はProcessOrderItemsHandle）をTable_Ordersの特定の列に格納します
- Table_OrderItemsの現在の注文IDと
各行の行にカーソルを作成します。
- ProcessOrderItemsHandleを使用して、注文アイテムIDを含むタイプMessage_ProcessOrderItemのMESSAGEを送信します
- メッセージタイプがMessage_ProcessingDoneの場合：
- メッセージ本文の注文IDを使用して、 Table_Ordersで注文状態を「処理済み」に設定します
- メッセージタイプが
http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog（END DIALOG）の場合：- メッセージの会話ハンドルに関連する会話を終了します
- トランザクションを終了します
- Queue_ProcessOrderItemのイベント通知は、次のことを行うProcessOrderItem.exeのインスタンス（最大同時実行数は1）をアクティブにします。
- SqlTransactionを開始します
- Queue_ProcessOrderItemから上位1つのMESSAGEを受け取ります
- メッセージタイプがMessage_ProcessOrderItem（フォーマットXML）の場合：
- メッセージ本文の注文アイテムIDを使用して
、 Table_OrdersItemsで注文アイテムの状態を「処理中」に設定します。
- 注文アイテムパラメータのコレクションをロードします
- パラメータを使用してURLにHttpRequestを作成します
- HttpResponseをPDFとしてファイルシステムに保存します
- 上記のサブステップでエラーが発生した場合は、注文アイテムの状態を「エラー」に設定します。それ以外の場合は「OK」に設定します。
- Table_OrdersItemsでルックアップを実行して、すべての注文アイテムが処理されているかどうかを判断します（状態は「ok」または「error」）
- すべての注文アイテムが処理される場合：
- ProcessOrderItemsHandleを使用して、注文IDを含むタイプMessage_ProcessingDoneのMESSAGEを送信します
- ProcessOrderItemsHandleに関連する会話を終了します
- メッセージ本文の注文アイテムIDを使用して
、 Table_OrdersItemsで注文アイテムの状態を「処理中」に設定します。
- SqlTransactionをコミットします
- Environment.Exit（0）で終了します
ノート：
- 仕様では、2005年から2012年までのMSSQL互換性を指定しているため、次のようになります。
- 会話グループなし
- 会話の優先順位はありません
- POISON_MESSAGE_HANDLINGなし（ステータス=オフ）
- 私は速度ではなく、全体的な流れの完全性と連続性を達成するために努力しています
- テーブルとSPがDB1に存在し、Service Brokerオブジェクト（メッセージ、コントラクト、キュー、サービス）がDB2に存在する場合、DB2は信頼できるものになります。
質問：
- 説明されているアーキテクチャに大きな設計上の欠陥はありますか？
- 注文完了状態の追跡が正しくないようです。より良い方法はありますか？たぶんQUEUERETENTIONを使用していますか？
- 私の直感によると、アクティブ化された外部exeが0以外の終了コードで終了することは決してないので
try{..}catch(Exception e){..} finally{ Environment.Exit(0) }、Mainにあるはずです。この仮定は正しいですか？ - DBコードでエラー処理をどのように整理しますか？エラーログテーブルで十分ですか？
- 外部exeC＃コードでエラー処理をどのように整理しますか？同じエラーログテーブル？
- SQL Server Service Brokerの製品サンプルを見てきましたが、Service Broker Interfaceは、一見単純なケースではやり過ぎのようです。より単純なServiceBrokerオブジェクトモデルの代替手段はありますか？
- 少なくとも毒メッセージを排出できるServiceBroker用のクロスバージョンの「ポータブル」管理ツールはありますか？
- 上記のいずれかの適切なコードサンプルはありますか？