说明:流程引擎的退回与发送,分别是前进与后退,它是流程引擎的基础功能操做,流程的退回根据不一样的应用场景,也是须要不一样的方式来控制,咱们把这些方式叫作规则处理。 ide
退回工做的场景相对复杂,因为与审核组件,表单联系在一块儿为了能适用更多的应用场景,少写代码,全部请仔细约定本文章关于退回的设置。 测试
退回窗口页面: 3d
首先选择要退回的节点,而后填写退回缘由,最后点击退回方式,完成退回工做。 日志
被退回人打开退回的工做查看页面: 对象
被退回人,能够从待办里打开工做,首先弹出的是退回信息。 blog
退回规则在节点按钮标签栏目中的退回标签设置,以下图: 事件
不能退回:当前节点不能执行退回功能,当前节点的操做人员就不能看到退回按钮。 ci
只能退回上一个节点:只能退回上一个节点,从那里发送来的,就退回到那里去。 资源
能够退回之前任意节点:不限制退回的节点,可是退回的节点必须是当前节点之前的节点。 it
可退回指定的节点:退回指定的节点,此功能须要在流程属性中的可退回的节点中设置它。
总结:
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经过如上两个方法解决退回数据的完整性问题。
与节点属性中的[是否能够退回并原路返回?] 配合使用
应用场景:一个流程走过了ABCDEFG几个节点,在G节点上发现要退回给B节点上去,还指望B节点的人员完成后直接发送给G节点上来,这种应用场景就是是否能够在退回后原路返回。若是是直接退回并不原路返回,那么CCBPM将会删除退回点与退回到点中间的数据,不然就不删除它。
单节点退回规则,是对可退回的节点仅仅有一个有效。
操做员想达到点击退回按钮,直接能够退回,不须要弹出退回窗口了。
这种工做模式下,退回的意见有两个填充模式,退回信息的字段,与审核组件填写的意见。
若是选择【按照退回信息填写字段做为退回意见直接退回】您就须要在退回信息填写字段属性里,填写这个字段名。
若是选择【按照审核组件填写字段做为退回意见直接退回】,您就须要在当前节点表单里,启动审核组件功能。
退回信息填写字段
用户常常会在审批意见的字段中填写意见而后点退回按钮,审批意见就是该操做员的审核意见,这个时候CCBPM须要把审核意见带入退回窗口,这个字段就是退回信息填写字段。
在demo的第二个节点,咱们看看退回的效果,咱们先看看测试效果。
点退回,CCBPM就会把审核意见放到退回的窗口里面
被退回后信息提示:在退回成功后,用于个性化的提示被退回的信息,支持ccbpm表达式。
单节点退回规则:
谓的单节点退回规则是指按照节点的设置的退回规则,被退回的节点只有一个节点的时候才能适用此规则。
启用此规则的时候,用户点击退回按钮,系统就会直接弹出退回信息,并执行了退回。
这种模式下的退回,是根据设置的退回意见规则填充退回信息,若是设置[退回信息填写字段]来做为退回意见,就要在该[退回信息填写字段]文本框里填写该字段的名字。
若是设置了按审核组件的意见作为退回信息直接退回,对于当前节点启用了审核组件有效。