1

我想使用 Windows Workflow Foundation 4.5 并通过 web api 触发工作流。既然 MS 将终止 AppFabric 支持，我有哪些托管选项？我什至应该使用 Windows Workflow Foundation 还是应该研究第 3 方解决方案？

这是内部部署，我无法使用 azure。我已经完成了一些工作流程，似乎 WWF 不难使用，但不清楚如何托管它。我可以在没有 AppFabric 的情况下在 Web api 项目中托管吗？

如果 IIS 应用程序池使用 WorkflowApplication 回收或服务器崩溃，我主要关心的是能否恢复工作流。我没有使用 WCF 我计划在 web api 中使用 WorkflowApplication。

谁能指出我在实现 AppFabric 负责的自定义功能方面的正确方向？恢复、记录等。

来自 MS：将 IIS 与 AppFabric 结合使用是工作流的首选主机。使用 AppFabric 的工作流的宿主应用程序是 Windows 激活服务，它消除了对 HTTP over IIS 的依赖

IIS 7.0 出于各种原因定期回收应用程序池。当应用程序池被回收时，IIS 停止接受旧池的消息，并实例化一个新的应用程序池以接受新的请求。如果工作流在发送响应后继续工作，IIS 7.0 将不会意识到正在完成的工作，并且可能会回收托管应用程序池。如果发生这种情况，工作流将中止，并且跟踪服务将记录一个 1004 - WorkflowInstanceAborted 消息，其中包含一个空的原因字段。

如果使用持久性，主机必须从最后一个持久性点显式重新启动中止的实例。

如果使用了 AppFabric，工作流管理服务最终会从最后一个成功的持久化点恢复工作流（如果使用了持久化）。如果不使用持久性，并且工作流执行请求/响应模式之外的操作，则工作流中止时数据将丢失。

4

1 回答 1

0

一种托管策略是让您的 Web API 方法简单地将消息放入队列（如 MSMQ 或 Rabbit MQ），并使用后端 Windows 服务来实际托管工作流实例。后端服务将持续读取队列并启动您需要的正确工作流程。

这样您就不会遇到可能终止工作流的 IIS 应用程序池回收事件。

如果您需要让 Web API 方法等待工作流完成，您可以让它等待“关联消息”到达队列以指示操作完成。或者您可以将 WF 实例结果存储在数据库表中。

我实际上建议不要使用 App Fabric，而是简单地滚动您自己的托管服务以获得更好的灵活性。加上它相对简单的实现一个你想要的行为。

这是一个图表，我希望对您的设计有所帮助或提供想法：

一个粗略的图表......但可以提供帮助。 :)

于 2017-12-30T04:03:26.017 回答