驰骋工做流引擎设计系列13

 

退回设计

第1节. 关键字

驰骋工做流引擎 流程快速开发平台 workflow ccflow jflow

第1节. 退回设计

1.1.1: 退回规则设计

流程引擎的退回与发送，分别是前进与后退，它是流程引擎的基础功能操做，流程的退回根据不一样的应用场景，也是须要不一样的方式来控制，咱们把这些方式叫作规则处理。

退回规则设置

退回规则在节点按钮标签栏目中的退回标签设置，以下图：

不能退回:当前节点不能执行退回功能，当前节点的操做人员就不能看到退回按钮。

只能退回上一个节点：只能退回上一个节点，从那里发送来的，就退回到那里去。

能够退回之前任意节点:不限制退回的节点，可是退回的节点必须是当前节点之前的节点。

可退回指定的节点:退回指定的节点，此功能须要在流程属性中的可退回的节点中设置它。

总结：

1,根据实际业务需求，设置不一样的退回方式。

2, 配合退回前、退回后的事件完成业务的可逆的操做。

1.1.2: 退回的消息处理

1.执行退回后，系统都会向执行人发送消息，发送对象仅限于上一节点的执行人员，这样上被退回的点上的工做人员就有一个待办工做，若是您集成了ccim它就会自动发一个消息提醒。

2.退回的动做写入WF_Track中，流程轨迹中就能很好的反应出来。

3.被退回的人在进入当前工做时，第一次会有消息提示。

Ccbpm如何处理流程退回过程的数据的完整性？

流程在退回时，有一段流程数据就是从当前点到退回点的所作的工做，这部分节点的数据如何处理成为了咱们要探讨与取舍的难点。

以请假流程为例，申请人发起，部门经理审批，总经理审批，人力资源归档。若是总经理退回到第一个点，能够解释为，部门经理作的无效的工做，此部分工做须要删除，在3.0之前的版本，ccbpm都是这样的处理的，这样的解释也是用户所接受的。

可是在其它的流程就不能这样解释了，由于他须要保留历史痕迹，而且在退回后有以下可能要发生。

1， 退回到指定的点后，发起人删除流程。

2， 退回到退回节点后，发起人修改表单后发送，按原节点发回来。

3， 退回到退回节点后，发起人修改表单后发送，经历与其它的路线步骤到当前点。

4， 退回到退回节点后，发起人修改表单后发送，该走其它的路线不经当前点。

基于如上可能性的发生ccbpm，作了以下处理。

1， 退回阶段流程数据写入txt 文件里，放在D:\ccflow\CCFlow\DataUser\ReturnLog

2， 增长了流程报告与节点的焦点字段功能，系统把每一步骤的操做都记到日志表里了，经过焦点字段的配合，可让操做员方便明晰的看到轨迹。

Ccbpm6.0经过如上两个方法解决退回数据的完整性问题。

1.1.3: 退回并原路返回

与节点属性中的[是否能够退回并原路返回？] 配合使用

应用场景：一个流程走过了ABCDEFG几个节点，在G节点上发现要退回给B节点上去，还指望B节点的人员完成后直接发送给G节点上来，这种应用场景就是是否能够在退回后原路返回。若是是直接退回并不原路返回，那么ccbpm将会删除退回点与退回到点中间的数据，不然就不删除它。

退回信息填写字段

用户常常会在审批意见的字段中填写意见而后点退回按钮，审批意见就是该操做员的审核意见，这个时候ccbpm须要把审核意见带入退回窗口，这个字段就是退回信息填写字段。

在demo的第二个节点，咱们看看退回的效果，咱们先看看测试效果。

点退回，ccbpm就会把审核意见放到退回的窗口里面。

1.1.4: 接口定义

退回是比较经常使用的方法之一，退回方法的api是BP.WF.Dev2Interface.Node_ReturnWork。

仔细的看看参数，就知道如何调用该退回方法了。

咱们不建议用户直接调用api，而建议调用ccbpm的这个工做部件，这个工做部件调用很简单。详细请参考：BP.WF.Dev2Interface.UI_Window_Return

因为在BP.WF.Dev2Interface这个类库里，已经很清晰的描述了各个api的做用，因为同步与变动的关系，这里再也不赘述。