Workflow PersistableIdle

Question

在我们公司，我们有一个业务流程，需要：

1. 从X中获取数据
2. 等待用户Y做研究
3. 基于步骤2的数据从Z获取数据

在研究这一点时，似乎有几个选项可以在工作流中实现。

1. 在步骤1(工作流活动)和步骤3(工作流活动)之间添加延迟活动。然后，在PersistableIdle事件期间，卸载工作流程。当用户完成步骤2时，从数据库重新加载工作流.
2. 与#1相同，只是使用书签而不是延迟活动。

是否有更好的批准(1，2或其他选项)？

我们所有的其他活动都是AsyncCodeActivities，所以我相当肯定它们不会触发PersistableIdle事件(因为它们位于非持久化区域)，但我希望确保工作流在其他情况下不会意外卸载。这里有风险吗？是否存在创建强制工作流卸载的活动？

Answer 1

是否有更好的方法(1，2或其他选项)？

乍一看，#2听起来很有必要。使用书签(或某些类型的书签活动，如接收)的原因是它们可以随时恢复。这允许用户Y的研究结束，工作流可以在任何时候恢复执行(而不是在延迟到期之前被阻止)。

反论点，即#1可能也是必要的，是您可能希望设置一个触发工作流操作的时间限制(触发提醒、异常、取消等)。

怎么决定？我认为答案通常是#3:两者都是

使用Pick活动是两种方法都可以做到的好方法。使用一个PickBranch触发器中的书签活动和另一个PickBranch触发器中的延迟活动，您可以组成一个工作流，它将“处理第一个发生的事件--用户Y或超时”。

您提出的第二个问题是，当我不希望工作流卸载时，我如何阻止它卸载--意外工作流卸载是一种风险吗？

那得看情况了。如果您正在使用WorkflowServiceHost，卸载您的工作流并不是很大的风险，因为WorfklowServiceHost足够聪明地在它需要做更多的工作时重新加载您的工作流(处理传入的消息，或者从延迟恢复)。

如果您不使用WorkflowServiceHost，您可能正在编写您的主机，您可以通过某些工作实现相同的效果，或者您可以通过WorkflowApplication上的事件来防止卸载发生--当您编写主机时，您控制卸载策略。

其他杂项问题：-Asynchronous代码活动确实会阻止您的工作流在执行异步工作时持久化。我认为它们不应该被故意用作一种对抗机制--如果你想要其中之一，就去看看NoPersistZone活性吧。

-There不是“卸载”活动，而是“持久”活动。工作流可以说他们想要保存进度，但是只有主机才能在卸载发生时做出最后的决定。