flowable 优秀的工作流流程引擎框架,前身Activity
为什么要用工作流?
主要是应对:
如果你不用类似于flowable工作流,久而久之你要么自己创建一套工作流框架,要么用flowable,这是必然发展之路。
有现车的成熟工作流框架为何不用?
即便如 flowable这样优秀的框架,也比较难对付中国的特色工作流。
【任务3】的处理人审核不通过后 要驳回给 【并行任务2-1-1】和【并行任务2-3-3】有可能就这两步处理人填写的内容有问题。
甚至还会遇到特事特办,提前跳转下面的步骤
还有遇到 并行网关 和 多实例综合场景, 某一步骤跳转至串行多实例场景。
虽然flowable 相较于Activity已经有很多改进之处,flowable的作者也意识到中国的特色工作流需求,也提供了不少跳转之类的接口。
但一般用过的应该发现,针对并行网关的跳转,实际上是有BUG的
例如下面的场景:
T5 要驳回给T2-2 和 T4-2 , 发现最后怎么也没办法流转到T5, 原因就是少了一条 T3-2的提交完成记录。
查看 act_ru_execution 表中记录
SELECT a.* FROM act_ru_execution a
WHERE a.PROC_INST_ID_ = @PROC_INST_ID_
ORDER BY a.START_TIME_ DESC
首先表act_ru_execution 记录中必须存在三条记录,表示并行网关的三条分支,其次走完条,字段 IS_ACTIVE_ 的值为0,然后flowable6.4.2版本跳转后并没有为并行网关生成所有的分支execution。
还有更加复杂的嵌套并行网关驳回处理:
请问 T7 驳回至T5 要怎么跳转 ????
如何在act_ru_execution 补齐所有的并行网关的分支execution记录??
在业务需求上 T7 作为审核员,他发现就T5提交的有问题,难不成要全部驳回至其实任务步骤? 因此不能说这样的需求是变态需求,无法实现。
解决诸如上面所述的各类并行网关的需求,一个看下流程是否可以变通,通过分支网关+表达式来优化,另外只能扩展flowable的接口业务逻辑了
flowable 提供了人性化的多实例任务 减签加签接口
网上也有很多博客例子,但你会发现他们大多数测试的是并行多实例下的业务场景,而且大多数只是测试了加签,并没有测试减签。
当你测试串行多实例加签减签时,你会遇到一些BUG,总之你会发现多实例核心变量数值一直有问题,而且串行多实例减签会变成两个任务等异常BUG发生。
自定义flowable BPM2流程引擎接口封装组件
bpm2-spring-boot-starter
里面包含了跳转、加减签、输出流程图自定义高亮节点颜色等方法。
由于代码过多,无法在博客里面贴出,请移步下面的github或码云
码云
https://gitee.com/banana6/bpm2-boot-starter/tree/main/bpm2-spring-boot-starter
github
https://github.com/dwhgygzt/bpm2-boot-starter/tree/main/bpm2-spring-boot-starter
<dependency>
<groupId>com.middolgroupId>
<artifactId>bpm2-spring-boot-starterartifactId>
<version>最新版本号version>
dependency>
##########################redisclent##############################
middol:
bpm2:
new-process-engine-config: true
database-schema-update: true
async-executor-activate: false
##################################################################
说明
true: 业务系统当前没有任何flowable相关的配置,引入本配置将新配置一个流程引擎
false: 业务系统本身已经有flowable相关的配置(例如:flowable-spring-boot-starter),不想重复配置流程引擎
async-executor-activate 和 database-schema-update 无需配置
这两个参数意思:
database-schema-update: true = flowable引擎自动创建表
async-executor-activate: true =在流程引擎启动就激活AsyncExecutor
@Service
public class MyBusinessServiceImpl {
// 用户任务相关接口
@Resource
private BpmUserTaskService bpmUserTaskService;
// 流程部署查询操作接口
@Resource
private BpmProcessService bpmProcessService;
}
/**
* 【本任务节点】的上一步【历史任务节点】列表
*
* @param query ignore
* @return ignore
*/
List<BpmTaskModelEntity> listBackTaskModel(BpmBackTaskModelQuery query);
/**
* 【本任务节点】之前的【历史任务节点】列表
*
* @param query ignore
* @return ignore
*/
List<BpmTaskModelEntity> listAllBackTaskModel(BpmBackTaskModelQuery query);
到底调用哪一个,根据自身业务需求决定。
另外查看 BpmTaskModelEntity 类可以看出,里面有标志位:是否多实例,是否并行网关上节点,归属的并行网关id
这里查询的列表没有做排序,业务系统可根据节点编号进行自行排序,另外可以将相同并行网关id的 归属到一个集合里面。
void jump(BpmJumpForm form);
查看 BpmJumpForm 参数对象如下:
/**
* 流程跳转(适用于选择历史任务步骤驳回场景,跳转指定任务,并行网关跳转)
*
* @author guzhongtao
*/
public class BpmJumpForm extends BpmBaseParam {
private static final long serialVersionUID = 1L;
/**
* 当前任务节点
*/
private String taskId;
/**
* 目标任务节点key
*/
private List<String> targetTaskDefineKes;
/**
* 需要设置的全局相关参数,全局变量
*/
private Map<String, Object> variables;
// ...... 省略部分代码.......
}
taskId : 当前执行驳回跳转的任务id
targetTaskDefineKes: 表示你要跳转到的任务节点,该值是你在画流程图时指定的任务ID编号, 该值从BpmTaskModelEntity 对象中可以取到。 说明: 如果为多个,则里面的任务必须全部都是并行网关上的任务节点。
/**
* 多实例-加签
*
* @param form ignore
*/
void addMultiInstanceExecution(BpmMultInstAddForm form);
/**
* 多实例-减签
*
* @param form ignore
*/
void deleteMultiInstanceExecution(BpmMultInstDeleteForm form);
这里说明一下,加签减签是 多实例里面的任务处理者进行操作的,如果还没有到达多实例任务节点,则不存在多实例加签减签业务。
因此请看 BpmMultInstAddForm 和 BpmMultInstDeleteForm
里面有一个共同参数: multiInstanceTaskId(当前操作的任务id)
在减签的时候,需要调用查询接口,查询可以减签的人员列表,当然不包含自己。
/**
* 获取当前多实例任务除自己外的其他用户信息列表,
* 用于 减签 业务场景
*
* @param multiInstanceTaskId 当前多实例用户任务id
* @return List
*/
List<MultiInstanceUserDTO> getOtherMultiInstanceUsers(String multiInstanceTaskId);
本方法的加减签操作均在原flowable的基础上做了很多处理BUG的修复工作。