为什么服务器重新启动后 Windows 工作流不存在？

Question

我有一个简单的 Windows Workflow 4.5 工作流（帖子末尾的屏幕快照）作为 IIS 中的 WCF 服务托管。我已经使用 Microsoft 提供的 SQL Server 存储设置了持久性。

工作流接受一个文档 ID 和一个布尔值，指示它是否需要暂停并等待人工活动（人工审核）。如果工作流需要等待，它有一个与文档 ID 相关联的 Receive() 活动并暂停（这会在后台创建一个书签）。否则它会运行到完成并路由文档。

只要我们不重新启动服务器或为服务回收应用程序池之类的任何事情，一切都会完美运行。据我了解持久性，工作流应在可配置的“空闲时间”周期之后持久化，例如在等待接收消息时遇到...我已将此值设置为非常激进的一秒。

但是，如果您在现实世界中期望长时间运行的工作流，如果我们通过重新启动或回收应用程序池来模拟服务器崩溃，则等待 Receive() 的工作流永远不会响应。在服务器恢复后，我们是否应该做一些特别的事情来“补充”工作流程？相关性不适用于持久化的工作流吗？

在服务器重启后永远不会触发的 Receive() 在下面的工作流程中以黄色突出显示：

Answer 1

我想我找到了这个问题的答案。

当您在 Visual Studio 2013 中创建 WCF Worflow 应用程序时，它会从包含预连接的 Receive() 和 Send() 活动的模板应用程序开始。正是这个接收，将 CanCreateInstance 设置为 true，允许在接收到 WCF 消息时实例化工作流。

问题似乎在于，捆绑在一起的接收和发送被认为是必须在工作流空闲之前完成的操作。也就是说，即使我在工作流中进行了第二次 Receive() 调用，并且该接收确实创建了一个书签并导致工作流等待输入，但它实际上并不能进入空闲状态。不闲置意味着工作流无法持久化。

您可以在我上传的工作流快照末尾看到 Send() 悬空。我把这个发送出去，工作流现在可以完美地等待、持续、关联和恢复。

回想起来，我认为我错误地认为预先连接的发送是为了提供有关工作流程的一些信息，而实际上将其视为对启动工作流程的消息的回复是有意义的——仅此而已。通过在 Visual Studio 作为模板提供的初始 Receive() 和配对的 Send() 之间插入工作流逻辑，我无意中阻止了工作流空闲，因为接收/发送 似乎被 视为原子操作 - - 至少就空闲/持续而言。