工作流回退模式分析
网友 http://tech.qq.com/a/20100114/000032.htm
回退(Rollback WorkItem)

  回退是工作流参与者对自己“待办任务”(实际是对工作项)的一种操作,即参与者主动回退待办任务列表中的任务到已经执行过的人工节点。

  为什么要回退?

  参与者接受任务后,发现不应由自己办理此任务或以前的执行者办理有错误等情况后,需要将此接受的任务回退给以前某个节点的执行者重新办理。

  回退模式

  回退的情况实际上是非常复杂的,其中包括了参与者的重新选择以及回退的条件判断等等。这里先列出常见的回退模式(其实也是我们支持的模式)。

  串行

 

这种情况最为简单,后续节点可以回退到前续任意人工节点。回退后,节点重走。

  分支

 

 

这种情况也相对简单,实际执行的分支上的节点可以回退到前续任意人工节点(不区分主支和分支)。同样,主支上的节点也可以回退到任意实际执行的分支上的节点。

  可能的问题:多次回退后的回退节点选择。例如:第一次流程经过节点2、节点3到达节点5,节点5可以回退到节点1、节点2和节点3的任意一个,此时节点5回退到节点1,节点1重走,这一次流程改为经过节点4到达节点5,节点5回退时如何选择回退节点?此时的策略是以最近实际执行的分支为准,即节点5只允许回退到节点4和节点1,不允许回退到节点2和节点3。(抹去记忆)

  并发

 

 

  对于并发的情况,分支节点只允许在分支的节点间回退。
 
 
同理,主支节点也只允许在主支的节点间回退。

  多实例汇聚

 

 

在这种情况下,节点5会产生2个实例,实际相当于继续并发。节点5根据具体哪个节点触发的它而产生回退节点。同时不允许回退到节点1以及前续的节点去。

  子流程

 

 

  支持子流程到父流程的回退,也支持父流程到子流程节点的回退。需要注意的是子流程节点有可能产生多个子流程实例,在这种情况下不支持父子流程之间的相互回退。

  回退节点的参与者选择

  默认策略是由原先节点的实际参与者重新处理,比如节点2回退到节点1,则节点1的实际参与者重新处理该节点任务。这也符合大多数实际的业务场景。

  在节点任务竞争参与的情况下,提供另一种策略,即让人员重新竞争。

  回退的条件判断

  对于多人(或者多部门,用户)参与的工作项,提供不同的回退策略

  任意人回退即回退,剩余工作项手工终止

  最后提交人回退才回退

  流程定义期定义该策略。

  另外流程定义时提供节点可回退列表,由用户在定义期对可回退的节点进行限制。

  关于业务补偿

  业务补偿是一个很重要的概念,在回退的情况下需要相应的回退部分业务操作。这里由引擎提供统一的接口,返回回退路径,由客户自定义代码进行匹配处理。

  关于实现

  很多工作流引擎通过流程定义时绘出回退线来显式的支持回退,这种实现在业务复杂的情况下会造成流程图的异常烦琐,但是比较清晰,实现比较容易。隐式实现相比而言优点更多。

 
CIO之家 www.ciozj.com 公众号:imciow
关联的文档
也许您喜欢