在端系统中流程并发驳回具体如何处理
⇨⇦
本文作者以个人在工程项目管理系统设计过程中的实际经历，为大家分享了以下设计文档，帮助大家解决＂B段系统设计中流程并发驳回＂具体该如何处理的问题。
公司用一款敏捷开发平台做企业办公系统，近日给客户做一款工程项目管理系统。因为客户行业特殊性，一个项目的概算在百亿以上，所以对流程审批比较重视，同时审批效率也有一定要求，部分流程需要几个相关部门并行一起审批；但又因平台缺少并行审批功能，在参考了网上不多的文档后加上客户实际需要与自己的思考形成以下设计文档，同时包括了开发的疑问与我的回复，供大家学习交流。
一、概念定义
1. 概念示例图
2. 流程模版
指使用流程设计器设计的，某一应用对应的所有高级表单都应执行的流程
3. 并行流程分区
并行流程由两个或者多个分支流程同时执行，分支上可以有多个节点，所有分支上的所有节点都执行完毕后，整个并行流程才被认为是执行完成，流程一旦进入并行流程，我们可以把整个并行流程步骤看做一个整体，称之为并行流程分区。本文只讨论并行流程＂与＂，＂或（多条分支但根据条件实际只执行一个分支）＂不在本文研究范围内。
并行分区应被定义为一个整体，其在整个流程中可以被看做一个节点。
在示例中共有2个并行流程，分别是4、5、6、7、8与10、11、12 。
出现并行流程的原因有：
为了提高企业效率。并行审批是多人同时审批，能够提高审批的速度；
解决同时审批，但绝大多数审批的内容不一样的用户场景。
4. 并行分支
在并行流程分区内并行执行的实例称之为并行分支
在示例中共有5个并行分支，分别是4、7与5、8与6与10、12与11
并行分支审批状态
并行分支应有同意与不同意两种审批状态，分支的状态取决于分支上节点的审批状态
当分支上所有节点都为同意时，认为分支为同意
当分支上一个节点为不同意时，认为分支为不同意
开发：
节点同意不同意，是后台程序去判断，不是页面操作？
产品：
节点不同意是指：节点的审核人员点击系统＂驳回＂按钮填写驳回表单并点击提交按钮的一系列操作。
5. 节点
可以简单的理解为：在现有流程中，一个＂方块＂等于一个＂节点＂。
并行开始节点
分支开始的作用是实现流程的并行流转，并行开始节点需要将表单同时转交给一个或多个节点。
在示例中，共有2个并行开始节点，分别是3与9。
聚合节点
聚合节点用于将分支或动态分支节点上产生的若干条并行流程实例聚合起来。
在示例中共有2个聚合节点，分别是9与13。
6. 提交
直接提交给我
流程哪里在来的就回哪里去。
重走流程
即按流程图定义，返回指定节点重新执行。
二、流程执行原则
非并行流程执行区外，在任意时间点只允许一个节点处于办理中。
两种状态：
1.并行流程分支可选
2.分支可不选：并行分支可以根某次实际业务中的需求，跳过某一分支，如下图：
在特定业务所需流程步骤中，不需要包含5、6节点的这一分支。那么在3选择转交下一步时，不对5进行勾选，则在本次流程业务中将不执行节点5、8 ；本次并行流程分区只需4、7、6同意后流程即可转交至9。
例：并行流程分区内的三个分支分别为财务、监察审计、工程管理，在某次合同审核中不需要＂监察审计＂分支进行审核，那么项目主管部门经办人可以只对财务与工程管理部分支进行勾选，跳过检查审计部。
未被选定的分支不被记录
如本次流程业务执行程中，4、7、6有人选择退回（重走流程），流程被驳回至3，3再次提交时可以再次选择分支。
1. 并行流程分区内流程等待
重申分支状态概念：
并行分支应有同意与不同意两种审批状态，分支的状态取决于分支上节点的审批状态
当分支上所有节点都为同意时，认为分支为同意
当分支上一个节点为不同意时，认为分支为不同意
2. 同意等待状态
聚合节点9应等待所有分支状态都为同意时再对聚合节点9发送一条待办信息。（不包括3在＂本次＂提交流程时未勾选的分支）
开发：
添加同意与不同意的节点信息，分支所有的节点都完成，有不同意的，就驳回？当人员不同意，是操作驳回，还是直接填写不同意？流程判断所有节点，有不同意的就驳回？每一个节点去判断不同意，只要分支上有一个不同意，就驳回？也就是说出发驳回的操作是什么？
产品：
此处有两个概念：节点不同意、分支不同意。
节点不同意是指：节点的审核人员点击系统＂驳回＂按钮填写驳回表单并点击提交按钮的一系列操作。
分支不同意参见文档上提及的概念:
分支状态概念
并行分支应有同意与不同意两种审批状态，分支的状态取决于分支上节点的审批状态
当分支上所有节点都为同意时，认为分支为同意
当分支上一个节点为不同意时，认为分支为不同意
根据概念，有多个节点的分支按照流程图顺序执行，如分支上先执行的节点获得了同意那么就按照流程图依次转交给分支上其他节点；如果先执行的节点就获得了不同意的节点状态，那么此时分支状态就获得＂不同意＂状态，分支上后执行的节点不在进行，此时等待其他分支获得分支状态后再按照其他规则进行驳回操作。
图例2个：
例1驳回：
分支1有多个节点（4、7、9）当4节点不同意，进行了节点的驳回操作（直接提交给我或重走流程都可），基于分支状态第二条，分支1无需再获得节点7与9的节点状态，此时获得分支1获得分支状态为：不同意。在获得2,3分支的分支状态获取后，综合并行流程分区的意见，按照其他规则执行驳回操作。
例2同意：
节点同意概念：点击转交下一步，填写转交下一步表单，点击提交按钮等一系列操作。
根据分支状态概念，
分支1：4、7、9三个节点都为同意后分支1才获得分支状态：同意
分支2：5、8两个节点都为同意分支2才获得分支状态：同意
分支3：6节点为同意后分支3获得分支状态：同意
此时整个并行流程分区上所有分支都同意则按照流程图转交至节点10，对节点10发送一条待办消息。
3. 驳回等待
与同意等待相似，并行流程分区内所有分支状态都获得之后才执行驳回操作，在此之前被驳回人不会收到驳回通知，以免出现各分支意见不一重复修改，一个业务办理多次等问题。
开发：
现在是有驳回就插入记录，记录每个人的驳回信息，当等待完成时，推送那一条代办？其他的代办如何处理？当有代办消息时，会如何提示？
产品：
＂现在是有驳回就插入记录，记录每个人的驳回信息＂不是记录每个人的，如果先执行的节点就获得了不同意的节点状态，那么此时分支状态就获得＂不同意＂状态，无需再获得分支上后执行的节点记录。当所有分支都获得分支状态后再按照其他规则对相应的节点推送一条待办。
三、驳回策略
1. ＂有人有异议就会被驳回＂
如果一个并行流程分区内有100个分支，有99条分支状态都是同意，有1条分支状态是不同意，也将执行驳回操作。
开发：
这里的驳回是页面操作，还是程序操作？页面操作，这一条不同意，是直接提交给我，还是重走流程？
产品：
程序操作
2. 重走流程大于直接提交给我。
在并行流程分区内，如有退回类型选择不一致的情况，则执行重走流程。
3. 大于一个直接提交给我则执行重走流程。
在并行流程分区内，如有两个及两个以上节点选择直接提交给我，则执行重走流程
4. 退回节点不一致。
在并行流程分区内，如两个分支选择的退回节点不一致，则按照流程模板的节点序号（也可以说是顺序执行中相对先执行的节点）对应的节点处执行重走流程（基于以上两条）
5. ＂直接提交给我＂有且只能传递一次。
＂直接提交给我＂模式有且只能转递一次，比如节点9＂直接提交给我＂模式驳回到节点4，这时候节点4不允许再有＂直接提交给我＂驳回到节点2。因为如果有再次＂直接提交给我＂驳回到节点2会造成混乱，因为节点2处理完后直接返回节点4，当节点4再次处理时是按正常提交给节点7，并不会直接返回节点9，那么此时流程实例将无法正常流转到结束，因为节点9是一个聚合节点。
节点4此时也不支持再次使用按流程图执行的驳回，因为是会破坏节点9的设置期望，节点9是期望驳回后直接处理返回回来，所以＂直接提交给我＂驳回后，统一规则为不允许再次驳回。只能是按节点9的期望处理完后再次返回给节点9.
6. 有驳回权限的节点
流程中所有节点都应有驳回权限
7. 可被驳回节点
本节图示：
并行流程分区内部可被驳回
并行流程分区内可驳回，两种驳回模式都应支持，但不可夸分支选择
例1：8驳回至5，可行
例2：9驳回至4，选择重走流程，可行
例3：9驳回至4，选择直接提交给我，可行
例4：9驳回至6，不可行
主线流程驳回至并行流程分区内
当审批人在驳回窗口选择驳回节点时，主线节点不可驳回至并行流程分区内任意节点，执行重走流程，只支持直接提交给我
例：10驳回到任务7的情况，由于节点7处于并行分支上，我们约定这种情况的驳回模式只支持＂直接提交给我＂模式，若不是这样那么节点7可能永远不法继续流转，因为节点10是一个聚合节点，需要等候节点9、8、6三个节点同时到达。
并行流程分区 驳回至主线节点
并行流程分区可驳回至主线节点，两种驳回模式都支持
例1：4驳回至2，选择重走流程
例2：8驳回至3，选择直接提交给我