服务器重启后，为什么Windows工作流不会持续存在？

Question

我在IIS中作为WCF服务托管了一个简单的Windows Workflow 4.5工作流程（帖子末尾的屏幕快照）。我使用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（）之间插入工作流逻辑，我无意中阻止工作流空闲，因为接收/发送似乎被视为原子操作 - - 至少就空转/坚持而言。