工作流程基礎：從未完成延遲活動

讓我們有一個工作流程，包括接收活動和延遲活動。接收活動有CanCreateInstance = true 並且還提供了查詢（消息）關聯。工作流託管在工作流服務中，並在閒置時立即保存到數據庫中。工作流程基礎：從未完成延遲活動

WorkflowService service = new WorkflowService 
{ 
    Name = "MyWorkflow", 
    Body = new MyWorkflow(), 
    Endpoints = 
    { 
    new Endpoint 
    { 
     ServiceContractName = "IMyWorkflow", 
     AddressUri = new Uri("http://localhost:1234/MyWorkflow"), 
     Binding = new BasicHttpBinding() 
    } 
    } 
}; 

WorkflowServiceHost host = new WorkflowServiceHost(service); 
string conn = "Data Source=...;Initial Catalog=..."; 
host.DurableInstancingOptions.InstanceStore = new SqlWorkflowInstanceStore(conn); 
host.Open();

現在我將消息發送到工作流和運行時創建的第一個工作流實例。相關密鑰當然包含在消息中。工作流繼續延遲活動並保存到數據庫並卸載。

我們假設延遲時間足夠長，然後我將發送下一條消息，並使用完全相同的相關密鑰。怎麼了？這兩種工作流程都不會從延遲中醒來，也從未完成。

我該怎麼做？爲什麼工作流運行時不能保護我免受此影響？有什麼辦法可以拯救這兩個工作流程實例嗎？

感謝您的幫助！

來源

2010-06-04 Petr Felzmann

如果使用消息關聯，消息中的鍵值必須與單個活動工作流匹配。如果您嘗試使用相同的密鑰啓動第二個工作流程，您將在嘗試啓動新實例時收到異常。現在，如果您僅使用沒有SendReply的接收，則您正在創建單向消息傳送方案，並且無法將SOAP錯誤發送回客戶端。所以客戶可能不知道這個錯誤。如果您在服務中啓用跟蹤並檢查日誌文件，仍然可以看到這一點。然而，更簡單的選擇是包含一個SendReply，即使你沒有正常的響應，因爲這會產生一個可以包含錯誤消息的響應消息。

來源

2010-06-04 08:10:16 Maurice

好的，明白，謝謝！目前還不清楚我該如何拯救這些工作流程。我可以看到這兩個工作流都保存在數據庫中。有沒有什麼辦法可以從代碼中訪問這些工作流程並做些事情，例如刪除它們能否再次正確使用相關鍵？ – 2010-06-04 10:13:05

或者，也許我的解決方案是不立即設置工作流程持久性，但延遲活動啓動時。然後，工作流向我發送異常，但不會自行保留。你能確認我說得對嗎？ – 2010-06-04 10:27:16

消息關聯與持久性無關。第一種是將消息路由到特定的工作流實例，第二種是關於保存狀態並能夠從內存中刪除工作流。消息關聯將與內存中的工作流實例完全一樣。 – Maurice 2010-06-04 11:45:14

工作流程基礎：從未完成延遲活動

回答

相關問題