背景:首先这是正常的,子调用活动结束父流程也不应该结束都是对的,因为这是业务上面的问题,如果这个一个串行流程,那他应该结束,因为获取不到前面的信息后面没有必要执行,如果这是个**并行流程**(业务上的并行,比如看起来是串行,但是后面的业务不会依赖这个子流程中的数据)。

问题: 在选择不通过后,流程意外启动了下一个子流程中的动态选择审批人任务,客户想直接全不通过

正常执行一层流程不通过不会触发 下一个子流程实例中审批人的动态审批人创建, 猜想是因为子流程中进行不通过 只是先结束了子流程,这个时候系统会监听子流程结束后再结束其父流程,而这里肯定进行了什么操作读到了后面的子流程 导致启动了动态审批人。 那现在的思路就是看看 这部分黑盒的顺序..........

实践结论：想复杂了,项目的不通过只针对了当前流程,也就是流程结束后父级流程并不会为此终止继续执行下一个节点

解决方法一: 伪结束,直接递归获取当前流程的顶级父流程 通过修改 runtimeService.setVariable 执行状态为3,使得流程无法进一步操作,但实际上 中间部分的流程还是处于 等待完成状态(落地快,见效快,底层逻辑不完美)

解决方法二:根据流程的生命周期,递归把途径的流程都进行终止操作,

遇到的问题,按照方法一的方式,我进行递归设置当前流程属性为3,确实成功,但是中间的流程却被意外启动。因为当子流程不通过对于父流程也算结束状态的一种导致执行了,我**!!#ff0000 倒!!**要看看 如果先从父流程瀑布式先底层流程结束呢？？？实验确实可以,但是删除第二个流程提示失败

直接结论,父子流程在ru_exection是有级联关系,父流程删除 子流程会直接删除,所以这里其实只需要删除父流程即可,并且结果验证,附带的任务,activity也会一同被商储,这就是驱动关联带来的便利,**!24 牵一发而动全身!**,代价也是驱动量大,是吧双刃剑