Service Broker的設計

Question

我希望推出SS服務代理，

我有一個遠程數據庫的訂單和本地處理數據庫，該數據庫的處理上的所有活動已按順序發生，這似乎是一個完美的工作Service Broker！

我已經建立了基礎架構，我可以發送和接收消息，現在我正在查看處理的設計。正如我所說的，一個訂單的所有流程都需要按順序完成，所以我會把它們放在一個對話中。

其中一個進程是對外部平面文件數據的請求，然後等待（可能有幾天），然後在返回時導入並處理該文件。我如何處理一半的任務，然後在處理另一半之前等待平面文件返回。

我有一些想法，但我敢肯定，我錯過了一招地方

1）寫入所有隊列中的項目，以一個狀態表和使用狀態值 - 似乎去掉一些SSSB的靈活性和添加任務

2）的另一層保留交易開放，直到我們得到的數據備份 - 不理想

3）具有平面文件導入任務不斷輪詢文件出現 - 這似乎效率不高

管理這個工作流程的最有效方式是什麼？ 在此先感謝

Answer 1

在我看來，它就像責任鏈。據我所知，我們有以下工作流程。

1.）消息處理。

2.）等待外部文件，現在這可能是一個繁忙的等待，或者如果外部數據爲您提供通知，那麼我們實際上可以非輪詢方式進行。

3.）一旦收到數據，然後處理數據。

所以我的建議是每個部分使用3個不同的隊列，一個完成後它會轉發或將新消息放入鏈接隊列中。

我假設，一個訂單處理不會中斷另一個訂單處理。

我想MSMQ與Windows Sequential工作流，也可能是這項任務的候選人。