工作流程ServiceHost設計 - 從客戶端恢復工作流程

我正在處理WF4，目前正在試驗一個簡單的費用審批系統的概念設計證明。我想使用IIS中託管的WorkflowService來使Web客戶端能夠提交批准。我當前的設計如下（假設我們只是傳遞一個expenseID和isApproved boolean值以接收活動）：工作流程ServiceHost設計 - 從客戶端恢復工作流程

WF4 Expense Workflow http://i56.tinypic.com/esohno.jpg

一個方面，我不清楚的是，客戶端需要準確知道接下來要調用的接收活動。爲此，客戶端需要確切知道工作流在哪裏（通過查詢數據源），切換某種狀態標誌並調用適當的接收活動。但是這樣做肯定會繞過使用持久化工作流的重點。

這可能只是因爲我的設計顯然是錯誤的，所以我很樂意提供任何有關如何最好地實現此任務或改進設計的意見或指導。

來源

2011-07-19 Marcus K

您可以達到此結果，但您應該提供API文檔和您的服務合同，以嘗試將此行爲明確給您的客戶。服務的WSDL本身不會使這一點變得清晰。

關於實施，實現這一目標的唯一方法是在WF之外。這是因爲當客戶端嘗試調用不允許根據工作流程流程圖規則調用的服務方法時，加載工作流程時會出現內容關聯錯誤。

WF服務主機將無法加載持久化的工作流實例，因此會拋出一個錯誤，您需要捕獲WCF IErrorHandler。然後，您需要確定場景是什麼，並將異常轉換爲客戶可以理解的服務故障。

我前一段時間寫了一篇博文，提供了一個如何工作的例子 - http://www.neovolve.com/post/2010/11/09/Managing-content-correlation-failures.aspx。

來源

2011-07-20 00:46:06

嗯，你會說這個例子不適合WF嗎？聽起來像WF可能更適合進入特定工作流程的單一入口點？ –

我實際上會說相反。 WF對此非常完美，但您需要明白，WCF本身並不通過服務合約的描述向WCF客戶端展示狀態轉換。在一天結束的時候，如果您很高興讓客戶閱讀一份寫得很好的API文檔，該文檔定義瞭如何使用像這樣的服務，或者讓他們在業務驗證規則方面遇到困難，閱讀手冊，那麼這將工作得很好。它的種類取決於什麼類型的服務設計/開發人員體驗是適合的。 –

我認爲第一步是明確界定你的客戶是誰。如果是公衆，那麼您可能需要重新設計您的服務合同，以便操作明確定義流程（您可能已經對現狀感到滿意）。或者，如果客戶端集合受到限制，那麼採用這種服務設計會更容易。 –

工作流程ServiceHost設計 - 從客戶端恢復工作流程

回答

相關問題