5

在我们公司，我们的业务流程需要：

  1. 从 X 获取数据
  2. 等待用户 Y 做研究
  3. 根据第 2 步数据从 Z 获取数据

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

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

是否有更好的方法（1、2 或其他选项）？

我们所有的其他活动都是 AsyncCodeActivities，所以我相当确定它们不会触发 PersistableIdle 事件（因为它们位于非持久区域中），但我想确保在其他情况下不会意外卸载工作流。这里有风险吗？无论如何创建一个强制工作流卸载的活动？

4

1 回答 1

5

有没有更好的方法（1、2 或其他选项）？

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

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

如何决定？我认为答案通常是＃3：两者

使用 Pick Activity 是兼顾两者的好方法。在一个 PickBranch 触发器中使用 Bookmarking 活动，并在另一个 PickBranch 触发器中使用 Delay 活动，您可以组成一个工作流，该工作流将“处理先发生者 - 用户 Y 或超时”。

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

嗯，这取决于。如果您使用的是 WorkflowServiceHost，卸载工作流不会带来很大风险，因为 WorfklowServiceHost 足够聪明，可以在需要做更多工作时重新加载工作流（处理传入消息或从延迟中恢复）。

如果您没有使用 WorkflowServiceHost，您可能正在编写您的主机，您可以通过一些工作达到相同的效果，或者您可以阻止卸载发生 - 当您编写主机时，您可以通过事件控制卸载策略关于 WorkflowApplication

其他杂项： - 异步代码活动确实会阻止您的工作流在他们执行异步工作时持续存在。我不认为它们应该被故意用作一种反持久性机制——如果你想要其中之一，请查看NoPersistZone 活动。

- 没有“卸载”活动，但有“坚持”活动。工作流可以说他们想要保存进度，但只有主机才能最终决定何时卸载。

于 2011-11-30T09:17:31.417 回答