将工作流进行到底
工作流回退常用模式分析Workflow Rollback Pattern
版本：1.0
作者 ：胡长城 [ 银狐999 ]
/james999
完成日期：2005-1-26 version 1.0
联系信箱：james-fly@
MSN ：fcxiao2000@
免费的工作流培训，详细请访问：
/mywf/train/index.htm
1. 前言 (2)
2. 简单退回 (2)
2.1. 退回到前活动 (3)
2.2. 退回跨越几个活动 (3)
3. 分支到主支的回退 (4)
3.1. 直来直去方式 (4)
3.2. 原始路由重新走 (4)
3.3. 强制退回，撤销其他活动 (5)
3.4. 退回，不改变现有活动 (5)
3.5. 块限制 (6)
4. 主支到分支的回退 (6)
4.1. 直来直去方式 (6)
4.2. 原始路由重走 (7)
4.3. 块限制 (7)
1.前言
回退一直是国内工作流产品非常重视的一个功能，但是实现起来也是比较复杂的，其难度远高于“自由流”的实现。
不过一直以来，没有什么文档对回退有过全面的介绍。
大多工作流产品也只是在其宣传单上印上“支持回退、撤回、拒绝、自由流”等泛泛的功能说明，具体回退有哪些模式，到是很少被提及。
这两天把回退的一些常用模式进行了一些总结，当然不全，有些比较复杂的就没有列出，现实中也基本很难碰到。
我想，把下面的其中的一些模式能够支持，比如2.1，2.2，3.1，3.2，3.5，4.1，4.2，4.3这几种方式，基本上可以满足国内客户百分之八九十的需求了。
一下主要列举了十种回退模式，其中2.1，2.2，3.1，3.2，3.5，4.1，4.2，4.3这几种方式是比较常用的方式，引擎支持起来难度也不是很大。
当然这几种方式对回退行为和方式作了一定的限制。
任何产品的开发，都应该尽量遵循二八原则。
所以在工作流产品在对回退的支持上，也应该根据不同的行业、领域酌情考虑支持的力度。
2.简单退回
2.1. 退回到前活动
简单退回，就是将任务退回到前面的发送者手中。
简单回退，看似简单，但是有几点需要考虑的：
（1） 是回退给上一个活动的最后workitem的执行者，还是回退给上一活动的所有workitem的执行者。
（2） 回退的时候，如果当前活动由几个workitem在处理，那么是都终止，还是仅此workitem回退
这几点的考虑，在接下来的回退模式中都有有可能存在，所有不再叙述。
——显示中的处理，一般采用一个统一的原则就可以了：比如回退给上一个活动的所有执行人，会退的时候，所有其他的workitem都终止。
2.2. 退回跨越几个活动
这个仅针对串行路由，回退后，所有活动重新走。
3.分支到主支的回退
3.1. 直来直去方式
直来直去方式，是指回退后，被回退的人，处理完以后，就直接返回给当前活动的处理人。
——当然，回退最好是“活动之间的回退”，而不是workitem对workitem的直接回退。
3.2. 原始路由重新走
回退以后，其执行的路线是按照原始执行路由又重新执行。
比如图上，黄色的E点活动，没有任何影响，依然在执行。
3.3. 强制退回，撤销其他活动
从分支退回到主枝的时候，将此分支范围内其他正在处理活动终止。
然后路由重新计算和执行。
这样的情况就会造成，有可能原先走的分支如今不能走了（条件不满足）。
3.4. 退回，不改变现有活动
从分支退回到主枝的时候，并不改变此分支范围内其他正在处理活动。
比如回退发生的时候，图中的E活动点还在执行，而且可以继续的往下走。
这种方式，处理起来是比较麻烦。
比如E执行完以后，到达F活动点。
但是这个时候，C由于执行了回退，无法到达。
如果此时F是一个And Join，则会造成流程死等。
——所有如果引擎支持这种回退模式，那么就必须有处理这种情况机制。
当然，这种模式并不常见，一般也不允许发生。
3.5. 块限制
引入块（Block）限制，是受XPDL Block Activity的一定影响，不过不一样的。
这里的块限制只针对分支，这样就将回退的行为限制在同一个级别的分支内发生。
比如图中的F点活动，其回退的范围只能是B或C活动点。
这样的限制方式，减少了引擎的不必要算法和判断，强制限制了从分支到主支的回退行为。
4.主支到分支的回退
这里只谈论了三种，还有一种就是允许主支往分支回退。
但是在现实中，这种可能性是比较低的，一般也不允许这种行为的发生。
4.1. 直来直去方式
没必要解释了，同上一节的“直来直去”方式，唯一不同的就是，一个是从分支到主支，另一个是从主支到分支。
4.2. 原始路由重走
这个也没有什么太多的叙述，同上一节的“原始路由重走”方式。
4.3. 块限制
块限制方式不仅限制了块内分支不允许往主支回退，也限制了主支不允许往分支回退。