驰骋工作流引擎设计系列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的作用，由于同步与变更的关系，这里不再赘述。