工作流 ServiceHost 设计 - 从客户端恢复工作流
我正在掌握 WF4，目前正在尝试简单的费用审批系统的概念设计验证。我想使用 IIS 中托管的 WorkflowService 来启用 Web 客户端提交批准。我当前的设计如下（假设我们只是将费用ID和isApproved布尔值传递给接收活动）：
WF4 费用工作流程 http://i56.tinypic.com/esohno.jpg
我不清楚的一方面是，客户端需要确切地知道要调用哪个接收活动 下一个。为此，客户端需要确切地知道工作流位于何处（通过查询数据源）、打开某种状态标志并调用适当的接收活动。但这样做肯定会绕过使用持久工作流程的点吗？
可能我的设计是完全错误的，所以我欢迎任何关于如何最好地完成这项任务或改进设计的意见或指导。
I'm getting to grips with WF4, and am currently experimenting with a proof of concept design for a simple Expenses Approval system. I want to use WorkflowService hosted in IIS to enable a web client to submit approvals. My current design is as follows (assume we're just passing in an expenseID and a isApproved boolean to the Receive activities):
WF4 Expense Workflow http://i56.tinypic.com/esohno.jpg
One aspect I'm unclear about is that, the client would need to know exactly which Receive activity to call next. To do that the client would need to know exactly where the workflow is at (by querying a datasource), switching on some sort of state flag, and calling the appropriate Receive activity. But in doing this surely I'd be bypassing the point of using a persisted workflow?
It could just be that my design is plain wrong, so I'd welcome any input or guidance on how best to acheive this task or improve the design.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以实现此结果，但您应该在服务合同中提供 API 文档，以尝试向您的客户明确此行为。服务的 WSDL 本身不会明确这一点。
至于实现，实现这一点的唯一方法是在 WF 之外。这是因为，当客户端尝试调用根据工作流流程图规则不允许调用的服务方法时，您将在加载工作流时收到内容关联错误。
WF 服务主机将无法加载持久工作流实例，因此将引发错误，您需要在 WCF IErrorHandler 中捕获该错误。然后，您需要确定场景是什么，并将异常转换为客户端可以理解的服务故障。
我不久前写了一篇博文，提供了一个示例，说明其工作原理 - http://www.neovolve.com/post/2010/11/09/Managing-content-correlation-failures.aspx。
You can achieve this result, but you should provide API documentation with your service contract to attempt to make this behaviour clear to your clients. The WSDL of the service will not make this clear by itself.
With regard to the implementation, the only way to achieve this is outside WF. This is because you will get a content correlation error on loading the workflow when the client attempts to invoke a service method that it is not allowed to call according to the workflow flowchart rules.
The WF service host will not be able to load the persisted workflow instance and will therefore throw an error that you will need to catch in a WCF IErrorHandler. You will then need to determine what the scenario is and convert the exception into a service fault that can be understood by the client.
I wrote a blog post a while ago the provides an example of how this works - http://www.neovolve.com/post/2010/11/09/Managing-content-correlation-failures.aspx.