【问题标题】:WF4 : where are Finished persisted state machines?WF4:已完成的持久状态机在哪里?
【发布时间】:2013-10-26 07:38:50
【问题描述】:

我已成功保存状态机,并在多次加载后将书签应用到状态机。

但是当它们到达最终状态时会发生什么?

为什么在完成后它们会从持久性数据存储 ([System.Activities.DurableInstancing].[InstancesTable]) 中删除?

这是正常的还是我在持久化完成的状态机时犯了一个错误?

【问题讨论】:

  • 你为什么需要那个?
  • @Will :我想知道这是正常行为还是我错过了什么。为什么没有人在书籍或互联网文章中提到“完成的工作流将从持久性数据库中删除”?
  • 他们为什么不这样做?他们执行完毕。存储完成的工作流程有什么价值?与作用域完成后收集的变量相同。
  • @Will 好的,我明白了。但是在批准系统中,我们必须知道到目前为止批准该文件的人是谁。所以实现审批系统的最佳方式是我们将触发的书签保留到现在并且不保留工作流,并且每当我们想知道该文档现在在我们的审批系统中的什么位置时,创建一个新的工作流实例并应用到目前为止的书签并了解我们处于哪个状态。
  • 工作流就是代码。如果 any 方法确定批准/拒绝,则不会存储该方法的代码,而是存储批准者、拒绝者和最终状态。因此,您不应该存储工作流的代码,而是存储结果。我将使用扩展 NativeActivity 的自定义活动,并在有人批准/拒绝时使用工作流扩展与外部通信。工作流程完成后,我也会记录该结果。

标签: workflow-foundation-4 state-machine


【解决方案1】:

工作流程就是代码。您使用较大的部分定义逻辑,但它会执行并返回结果。这不是结果本身。

假设您有一个类,该类具有您调用的方法来确定批准/拒绝。您将启动该类,传入参数值,并让代码执行确定批准/拒绝。这段代码执行后你会做什么?

您不会存储该方法的代码,这是肯定的。您将存储谁批准、谁拒绝以及最终结果。

因此,您不应该存储工作流的代码而是存储结果

我将通过创建自定义活动来扩展 NativeActivity,使用一个或多个 workflow extensions 与外部世界通信以发送有关批准或拒绝等待操作的通知,从而实现此工作流程的目标。一路上,当我的书签恢复执行时,我会记录谁做了什么。工作流程完成后,我也会记录最终结果。

【讨论】:

  • 是的,你是对的,我想把所有的负担都放在工作流程上!
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-07-17
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多