回退(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的实际参与者重新处理该节点任务。这也符合大多数实际的业务场景。
在节点任务竞争参与的情况下,提供另一种策略,即让人员重新竞争。
回退的条件判断
对于多人(或者多部门,用户)参与的工作项,提供不同的回退策略
任意人回退即回退,剩余工作项手工终止
最后提交人回退才回退
流程定义期定义该策略。
另外流程定义时提供节点可回退列表,由用户在定义期对可回退的节点进行限制。
关于业务补偿
业务补偿是一个很重要的概念,在回退的情况下需要相应的回退部分业务操作。这里由引擎提供统一的接口,返回回退路径,由客户自定义代码进行匹配处理。
关于实现
很多工作流引擎通过流程定义时绘出回退线来显式的支持回退,这种实现在业务复杂的情况下会造成流程图的异常烦琐,但是比较清晰,实现比较容易。隐式实现相比而言优点更多。