本文共 1206 字，大约阅读时间需要 4 分钟。

自定义活动(五)

中止活动的运行

无论用停止、放弃、中止或中断等之类的这些词都不能很直接地表达我这里所表达的意思！这是目前为止我遇到的封装业务逻辑到自定义活动的最大障碍；因为就自定义审核活动来讲，用户所设计的工作流中每一个活动可能被多次执行。例如需要多个人参与同一个层次的审核，当条件不满足是便“停止”运行，然后等待下一个用户来输入用于计算的基础数据，并重新执行该逻辑，直到条件满足该活动执行完毕并过渡到下一个活动为止。需要特别说明一下，这里的自定义活动的逻辑包含了基础数据的读取，条件的判断及是否往下执行、原地等待还是回退的处理，而不是用一大堆WF预置的活动来支持，全部功能都封装于一个活动之内；另外这里不对回退进行说明，有关回退的内容请看后续的文章。

在WF的SDK中有一个很关键的术语“persistencepoint”，它决定了下次加载时WF实例开始运行的点。我将用这个词语来解释一些问题，让我们来看一下它在我们“中断”工作流中所产生的影响！

我们尝试过多种方法去“中断”WF实例的运行，如：

• 杀死线程或进程。此方法可以使WF实例被再次加载并重新执行被中断的活动的逻辑。但此方法在实际应用中不可取，有很多的负面影响。
• 调用WorkflowInstance.Abort。此方法的结果是不确定的，先放着下面会描述。
• 调用WorkflowInstance.Terminate，此方法行不通，会将WF实例从数据库中清除出去！！！
• 调用WorkflowInstance.Unload，此方法也行不能，该方法会先进行持久化，然后再“中止”WF实例的运行。因为“persistence point”位于活动的中间逻辑——请求“中断”的后面，所以导致WF实例不能加载运行！！！
• 在活动执行逻辑内部产生异常，此方法我们是没有成功过，最终结果也是将WF实例从数据库中清除出去！！！

大家已经知道突破点在于Abort上，但这个也被我们差一点放弃，具体的过程已经想不太清楚了，好象是在活动执行逻辑中不能直接调用WF实例的Abort方法，只能由引擎来进行此处理才可以。如何将活动的控制权微妙地转交到引擎上去，我的同事花了一些工夫：）。解决的方法是在活动执行逻辑中返回Executing状态，这样就会触发引擎的OnIdel事件，然后在引擎的OnIdel事件处理中调用WF实例的Abort方法。然而问题不是到此就结束了。

我们用来进行我们的持久化工作，在它的构造函数里有一个unloadOnIdle参数，就是这个参数给我们带来了不小的麻烦。如果该参数为真，则会在引擎的OnIdel事件中调用WF实例的Unload方法，这样就会形成一个脏的“persistence point”。所以必须将该参数置为False。

转载地址：http://joxyz.baihongyu.com/