关于activiti的流程回退功能讨论

最近在整理一版基于struts、hibernate、spring和activiti的开发平台，在流程设计使选用了activiti的流程引擎，主要原因是习惯了JBPM的流程思路，而Tom Baeyens基于JBPM思想设计的activiti更加合理，使用方便，功能也更加强大。

但是在流程回退方面确遇到了很大的困难，国外的流程思想与国内差别还是很大的，在中国人的观念中，流程既然能前进就应该可以回退，但是在国外的思想中，回退也是正常流转的一种，只在特定环节画线回退即可，如果流程过于复杂，按照中国人的习惯就需要每个环节之间都画回退线，这显然不现实。

经过与同事和领导的讨论，基本整理出一下回退思路。( 流程图可能显示不全，请下载查看)

 

 

 

一、审批1.1、审批2.1 不允许驳回，两者是并发任务，如果审批1.1驳回，审批2.1需不需要驳回？这是一个问题，如果不驳回，填单环节更改信息，审批2.1需不需要重新发待办，如果发待办与现实不符，不发待办会出现流程风险；如果驳回，实际业务中会出现责任纠纷。经过与领导的讨论，大家一致认为并发环节不允许驳回。

如：审批1.1、审批2.1、审批1.7、审批1.8、审批2.5、审批2.4

二、审批2.2可驳回审批审批2.1；审批2.3可驳回审批2.2和审批2.1；审批2.6可驳回审批2.3、审批2.2、审批2.1 。其他情况以此类推，也就是并行分支节点内部可驳回。

三、审批1.8可驳回审批1.5、审批1.3、审批1.1或审批1.4、审批1.2、审批1.1。条件分支节点的驳回可能会因为信息的流程而走不同的流向，所以审批1.8的驳回方向可能会有不同，具体驳回哪一条流程就要看哪条流程的发生时间最晚。即驳回最近发生的流向。

如：审批1.5和审批1.4都同属审批1.8的上一节点(审批1.7和审批1.8在并行节点内，不作为流程1.8的上一节点)，到历史记录表分析比较，哪个任务发生时间最晚，即可决定所在的流向。

四、审批二可驳回审批一、填单。即并行节点外环节可驳回。

五、为了便于并行节点内外的判断，要求流程设计时，并行节点成对出现，且遵循XXX_start、XXX_end的命名规则（在开发web流程设计器自动封装）

六、由于考虑到实际业务，activiti的多实例没有应用到并行审批，用并行分支可完成绝大多数的业务需求，此外嵌套子流程功能也被剔除，而采用外接子例程的方式，所有没有讨论嵌套子流程的回退，而外接子流程与主流程相对独立，起驳回思路与主流程一样。

 

本次回退讨论仅参考了本公司的业务流程，多实例与嵌套子流程等没有考虑在内。本公司是集团公司，全国有近500家分公司还有海外子公司，业务流程应该基本能涵盖绝大多数的流程。如果有特殊无法满足的流程，请联系我，给我一个实际应用的思路，便于我们的完善。谢谢。

由于本人水平实在是有限，activiti也仅仅接触了二周，所有肯定会有很多理解偏差，请大家不吝赐教，让我这只小鸟能尽快成长。谢谢。

 

此外，关于activiti回退的代码工作已完成，后续会整理资料上传，给大家提供一点点思路。