的BizTalk殭屍 - 任何方式從BizTalk業務流程內顯式刪除訂閱

Question

背景：

我們利用了大量的聚集，單和多例的業務流程中，類似於這裏描述Seroter's Round Robin技術（的BizTalk 2009） 。

所有這些編排類型都具有相當任意的出口或延續點（對於聚合），通常由定時器定義 - 即如果Orch在X分鐘內沒有收到任何更多消息，則繼續進行批處理，如果在經過了更多的分鐘後，沒有更多的消息，然後退出。 （由於對degraded performance after large numbers of messages的關注，我們也退出了我們的單/ N噸）。

儘管我們試圖減輕對殭屍的攻擊，通過開始異步重構編排中的任何延續處理，總是有一個弱點，一個「好」的時間消息可能導致殭屍。 （即接收更多與「已完成」編排形狀相關的傳入消息），

如果消息導致其中​​一個訂閱上出現殭屍，則該消息似乎不會傳播給其他訂閱者（即orchs完全與'造成殭屍'編排）分離，即殭屍原因消息沒有處理。

問題

所以我會在看到如果有人有另外一種方法，編程或以其他方式，從運行的業務流程明確刪除相關認購非常感興趣，一旦業務流程已經「進步」超越的地步它對這個相關的消息感興趣。 （這個新的消息將隨後通常會開始有自己的相關性等新的業務流程）

在這一點上，我們會考慮甚至是黑客的解決方案，如反映的BizTalk API調用或直接在SQL中刪除對MsgBoxDB。

Answer 1

不，您不能顯式刪除業務流程中的預訂。

當Orchestration自行關閉時，訂閱將被刪除，但到達該確切實例的消息將被路由到編排，但編排將在沒有處理的情況下結束，這就是您的殭屍。

關於殭屍http://msdn.microsoft.com/en-us/library/bb203853.aspx

Microsoft文章我也曾經有一個接收debatch，彙總，發送模式。接收來自多個發件人的封裝消息，對其進行辯論，由預期收件人進行彙總（基於兩條規則，消息數量或時間延遲，以先發生者爲準）。 這個場景對於殭屍來說已經成熟了，當我讀到它們時，我設計了它，所以它不會發生。這是爲BizTalk 2004 我debat消息，並將它們插入到數據庫中。我有一個存儲過程被一個接收端口輪詢，如果有一個批處理髮送，那麼會觸發一個Orcherstration，它會動態地發送該消息並將其路由。 由於Orchestrations不得不等待另一條消息，他們可以優雅地結束，並且不會有殭屍。