工作流回退模式分析

回退（Rollback WorkItem）

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

为什么要回退？

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

回退模式

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

串行

<!-- [if gte vml 1]> <![endif]-->

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

分支

<!-- [if gte vml 1]> <![endif]-->

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

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

并发

<!-- [if gte vml 1]> <![endif]-->

对于并发的情况，分支节点只允许在分支的节点间回退。

<!-- [if gte vml 1]> <![endif]-->

同理，主支节点也只允许在主支的节点间回退。

多实例汇聚

<!-- [if gte vml 1]> <![endif]-->

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

子流程

<!-- [if gte vml 1]> <![endif]-->

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

回退节点的参与者选择

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

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

回退的条件判断

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

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

最后提交人回退才回退

流程定义期定义该策略。

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

关于业务补偿

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

关于实现

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