F2BPM中关于工作流引擎驳回设计

1.1 关于驳回

驳回，在有的应用中叫“回退”。驳回是中国特色的一种方式，驳回在流程图上也没有迁移线的表达经常也是隐性的，比如申请经费可能由于资料不足被驳回来补充资料，像这样的例子有非常多，也很常见。

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

回退的情况实际上是非常复杂的，有串行上的驳回，也有并行内的驳回，并行区内驳回到并行区外，从分支驳回到主干等，从主干驳回到分支内，多重聚合的驳回等。驳回过程中会发生很多事情，也会可能导致重走路径时产生重复路径。

驳回方式的支持力度也往往成为评价一个工作流引擎是否具有中国特色和引擎强弱的能重要批价指标。

1.2 关于显隐性驳回的理解

如下图所示，有节点A到节点B 属于正常发送，但从节点B到节点A，则出现两种情况：

 

（1）迁移驳回：实际说是迁移驳回的表达是不正确的，因为没有迁移驳回的说法，本质上还是正常发送，如图中B—A黑色线；（迁移的驳回严格上没有驳回的意义存在，只是一种表象，与正常向提交节点没有区别，所以迁移式的驳回不是本节讨论的重点）,这里只是提出来有一个认识。

通过流程定义时绘出驳退迁移线来显式的支持驳回，即使用迁移的方式来作为回退，实际这种不叫驳回，只是用流程的正常提交流转而已。

（2）被驳回：（流程图中不存在线，如上图中红色线是不存在的）可能因为某些特殊原因，被任务B退回，要求任务A重新办理，如图中B—A红色线。虽然都是从B到A，代表的意义却完全不同。（本章所讨论的驳回模型都是讨论这种情况），

1.3 关于业务补偿

业务补偿是一个很重要的概念，在回退的情况下需要相应的回退部分业务操作。这里由通常由用户自行编写相关的代码进行业务上的回滚，由用户自定义代码进行处理。

1.4 驳回问题类型

1仅可驳回到提单

2仅可驳回到上一步

3仅可驳回到上一步或提单

4驳回任意历史节点

5驳回指定历史节点

1.5 驳回模式

1.5.1 描述

 

上图：驳回模式

驳回模式是指驳回后再重新提交应当怎么处理，如上图所示，节点3驳回到节点2，然后节点2重新提交时直接提交回到节点3.这就叫直来直往。

上图所示，节点6驳回到节点2，节点2正常提交依然是走节点5，节点5再并发给节点3和节点6，这样的方式就叫按流程图执行。

当按直来直往或按图流程执行时都会发生一些问题，比如节点6驳回节点2时，如果当时节点3已经存在实例了，那么这时驳回节点2这后重新走节点5会导致节点3的分支重复，那么这些问题就是驳回模式中要解决的问题。

主要分为两种模式：

按流程图执行

即按流程图定义执行。

直来直往模式

哪里在来的就回哪里去。

1.5.2 直来直往

即驳回后回到本节点

 

如上图所示，节点3驳回到节点2，节点2处理后直接返回到节点3.直来直往适应于绝大多数情况。

 

直来直往模式有且只能转递一次，比如节点13直来直住模式驳回到节点3，这时候节点3不允许再有直来直往驳回到节点2.因为如果有再次直来直住驳回到节点2会造成混乱，因为节点2处理完后直接返回节点3，当节点3再次处理时是按正常提交给节点7，并不会直接返回节点13，那么此时流程实例将无法正常流转到结束，因为节点13是一个并行结束节点。

节点3此时也不支持再次使用按流程图执行的驳回，因为是会破坏节点13的设置期望，节点13是期望驳回后直接处理返回回来，所以直来直往驳回后，统一规则为不允许再次驳回。只能是按节点13的期望处理完后再次返回给节点13.

1.5.3 按流程图执行

1、并行区间外驳回到并行区前

 

如上图所示节点13驳回到节点2，此时节点2提交后是按流程图执行，而引擎是删除节点2之后所有节点实例，比如节点6如果存在实例而清空掉这些实例。那么当前任务会从节点5重新开发。

1.5.4 并行外驳回到并行区间内

 

如上图所示，任务13驳回到任务7的情况，由于节点7处于并行分支上，我们约定这种情况的驳回模式只支持“直来直往”模式, 因为若不是这样那么节点7可能永远不法继续流转，因为节点13是一个并行结束节点，需要等候节点7和节点15同时到达。

直来直往模式：支持

按流程图执行：不支持

1.5.5 并行区间内驳回到并行区间外

 

如上图所示为并行区间内驳回到并行区间外，节点3驳回到节点2.

直来直往模式：支持

按流程图执行：支持