工作流回退机制

版本一：
回退（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的实际参与者重新处理该节点任务。

这也符合大多数实际的业务场景。

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

回退的条件判断
对于多人（或者多部门，用户）参与的工作项，提供不同的回退策略
任意人回退即回退，剩余工作项手工终止
最后提交人回退才回退
流程定义期定义该策略。

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

关于业务补偿
业务补偿是一个很重要的概念，在回退的情况下需要相应的回退部分业务操作。

这里由引擎提供统一的接口，返回回退路径，由客户自定义代码进行匹配处理。

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

隐式实现相比而言优点更多。

版本二：
工作流的回退本质上是基于路由表的路由操作,仅仅是路由表中的目标节点不同而已同时,在回退的时候,需要考虑到,回退到任意一个节点可能会带来的风险
任意回退可能存在的风险主要有以下两种(但不仅限于这两种)
1.回退的目标节点需要的属性,从当前节点回退并不能满足
2.对于并行的情况,回退的是Job的一个Sub Job的话,需要考虑到对其它兄弟姐妹Sub Job的影响
Simpleflow工作流套件的回退机制有两种,基于路由表Route Table的回退和基于自由流的回退
我们先定义流程的正常流转路径为A -- B -- C
1.基于路由表的回退
是指,从节点C回退到节点A是由路由表定义的.在节点C当满足一定条件时提交,根据路由表的规则,将Job回退到节点A.本质上是基于路由表的路由.
不同之处就是在批准的情况下将JOb路由到节点D,则不同意的情况下将Job路由到节点A,这两条路由都是已经在流程定义中预先声明的.
在业务规则允许及不会产生其它状况的情况下,你可以建立任意多的路由表,将Job路由到任意节点.
2.基于自由流的回退
基于自由流的回退是指在业务流程定义中并没有明确定义C节点的路由表可以路由(回退)到A节点,但是在Job流转过程中,发生需要将Job从节点C回退到节点A的情况,而这种情况,不是在当初业务流程定义时估计到的情况.此时,Simpleflow允许管理员通过JobReroute操作,将此Job手工从节点C路由到节点A,并由管理员判断此操作可能带来的风险,并进行调整.
Simpleflow倾向于将自由流(JobReroute)的功能仅开放给流程管理员,而不是可以由节点C的参与者可以随意将Job路由到任意节点.因为既然是业务流程就应该有一定的规则,而这些规则就应该在流程定义的时候考虑在内.既然有需求需要将节点C回退到节点A.为什么不先建立这样的路由表,并按规则来路由呢
*重新指定节点参与者
Simpleflow也提供了可以重新指定节点参与者的功能,当节点C的参与者无法完成节点操作时,管理员可以将该节点的参与者,在实际业务允许的情况下,手工指定到另外的人员进行处理.即JobReassign功能
版本三：
在流程建模的时候，定义好了返回的线路，这种严格来说，不是回退流。

例如，审核不通过，则返回重新填写，这种只是条件路由。

工作流的回退流，是流程实例在流转的过程中，可以回退到运行轨迹的任意步骤，同时还可以辅助一些业务补偿方法，使得回退时候的环境和原来执行时候的环境一样。

所以回退流，和流程引擎支持的正常的路由方式是不一样的，甚至是反流程建模的方式，流程建模就是把业务流程的各业务处理过程按一定的流转方式建立起关联。

而回退流，是没有规律的，当流转到一定的步骤后，可以回退到任意的步骤。

当流程的流转方式为顺序流的时候，处理回退很简单：
顺序流：
当运行到最后一个步骤时，可以选择回退到前面的任意步骤。

而不是按照流程定义的方式，接着往下执行。

实现过程：关闭当前执行的步骤－－》转入历史步骤－－》指定回退的步骤为当前可执行的步骤－－》生成指定回退步骤的任务－－》辅助执行业务补偿类(可选的)
条件路由：
实现过程：和顺序流的处理类似，当需要回退的时候，关闭当前的可执行步骤－－》送入历史步骤－－》建立回退到的步骤为当前可执行步骤－－》生成指定回退步骤的任务－－》辅助执行业务补偿类（可选的）
分支路由：
上一篇文章主要讲了分支和聚合，分支包含静态分支和动态分支，都是同时产生并发的分支线路。

静态分支用静态聚合来汇聚，动态分支用动态聚合来汇聚。

按正常的流转方式，静态分支和动态分支，按照流程建模时候的路由方式，继续向前流转。

但是如果选
择回退，回退的处理就和顺序流等不一样，回退到分支上，回退到主干上，处理过程会不同。

单层的分支：
当流转到分支节点，产生并发的分支时
分支－－回退到－－分支，处理过程：关闭当前分支节点－－》转入历史步骤－－》回退到的分支节点步骤为当前可执行步骤－－》生成指定回退到的步骤的任务－－》辅助执行业务补偿类（可选）
其它的分支不受影响。

分支－－回退到－－主干，处理过程：关闭所有分支上的当前步骤－－》转入历史步骤－－》回退到的主干节点步骤为当前可执行步骤－－》生成指定回退到的步骤的任务－－》辅助执行业务补偿类（可选）。

所有分支都被关闭，回退到主干节点上。

主干－－》回退到－－分支，处理过程：关闭当前主干上的当前步骤－－》转入历史步骤－－》回退到的分支节点步骤为当前可执行步骤－－》生成指定回退到的步骤的任务－－》辅助执行业务补偿类（可选）
只生成回退到的分支节点为当前可执行步骤，其它并行节点不生成，当此分支执行完成，汇聚的时候，配合其它分支节点的历史步骤的执行情况，来满足汇聚的条件。

就如只有此回退到的分支需要重新执行一次，其它的分支不用重新执行。

多层的分支：
当有分支嵌套的时候，回退的处理又更加复杂
单层的分支－－回退到－－本分支，处理过程，同上面单层分支－－分支。

其它的分支均不受影响，只在本分支上面回退。

单层的分支－－回退到－－上层分支的主干，处理过程：
递归出上层分支的所有下级分支节点
||
关闭这些节点的所有当前步骤
||
送入历史步骤
||
生成回退到的上层分支主干的节点为当前步骤
||
生成指定回退到步骤的任务
||
辅助执行业务补偿类（可选）
任意分支－－回退到－－主干，处理过程：关闭所有的多层分支的当前步骤－－》送入历史步骤－－》回退到的主干节点步骤为当前步骤－－》生成指定步骤的任务－－》辅助执行业务补偿（可选）
这种回退处理比较清晰，关闭掉所有并行的一级分支，二级分支等等。

上层分支的主干－－回退到－－任意分支步骤：
关闭分支主干上的当前步骤－－》送入历史步骤－－》生成回退到的分支节点步骤为当前步骤－－》生成回退步骤的任务－－》辅助业务补偿（可选）
其它并发分支线不受影响。

主干－－回退到－－任意分支：
只生成回退到的分支节点
处理过程：关闭主干节点的当前步骤－－》送入历史步骤－－》生成回退到的分支节点为当前步骤－－》生成回退到步骤的任务－－》辅助业务补偿（可选）
其它分支线不受影响，取其它分支的历史步骤和当前分支步骤匹配汇聚节点的条件。

就如同某分支需要重做，其它分支不需要重新处理。