Flowable 流程部署与删除

本文我们一起来看看流程的部署等细节问题。

其实当我们使用了 Spring Boot 之后,默认情况下流程是会自动部署的,基本上不需要我们额外做什么事情。不过这些操作里还是有不少细节,今天松哥就来带大家一起来梳理一下。

1. 默认行为

首先我们先来梳理一下默认行为。

默认情况下,我们放在 resources/processes 目录下的所有流程文件会自动被部署,流程文件的后缀有两种形式 bpmn20.xml 或者 bpmn。当然,无论是存放流程文件的位置,还是流程文件的格式,都是可以定制的,涉及到的属性主要有三个,可在 application.properties 中进行配置:

flowable.check-process-definitions=false
flowable.process-definition-location-prefix=classpath*:/processes/
flowable.process-definition-location-suffixes=**.bpmn20.xml,**.bpmn

flowable.check-process-definitions:这个表示是否在项目启动的时候,去检查文件目录是否有对应的流程文件,该属性为 true 表示如果有流程文件就自动部署,false 表示不检查,那么也就不会自动部署。

flowable.process-definition-location-prefix​:这个是流程文件的位置,默认就是 classpath*:/processes/,当然开发者也可以进行配置。

flowable.process-definition-location-suffixes​:这个是流程文件的后缀,默认有两个,分别是 **.bpmn20.xml 和 **.bpmn,当然开发者也可以进行配置。

这个配置应该没啥好说的。

2. 动态部署

有的时候,我们的流程可能并不是提前设计好的,而是项目启动之后,动态部署的,例如项目启动成功之后,动态上传一个流程的 XML 文件进行部署,这也是一种比较常见的场景,对于这种情况,我们可以按照如下方式进行部署:

@RestController
public class ProcessDeployController {

@Autowired
RepositoryService repositoryService;

@PostMapping("/deploy")
public RespBean deploy(MultipartFile file) throws IOException {
DeploymentBuilder deploymentBuilder = repositoryService.createDeployment()
.category("javaboy的工作流分类")
.name("javaboy的工作流名称")
.addInputStream(file.getOriginalFilename(), file.getInputStream())
.key("javaboy的工作流key");
Deployment deployment = deploymentBuilder
.deploy();
return RespBean.ok("部署成功",deployment.getId());
}
}

我这里给了一个简单的文件上传接口,关于文件上传部分我就不多说了。我们来看下流程部署:

首先通过 repositoryService.createDeployment() 方法来创建一个流程部署构建器,即 DeploymentBuilder。

接下来为 DeploymentBuilder 设置分类、名称以及 key 等属性。

关键的方法是 addInputStream,通过该方法去指定流程文件。官方的提供的指定流程文件的方式有好几种;除了 addInputStream 之外,另外还有一个 addString,这个就是将流程文件转为一个字符串传入进来;addBytes 是将流程文件转为字节数组传进来;addClasspathResource 方法则是直接从 classpath 目录下去加载流程文件,这几个方法根据自己的使用场景选择一个合适的方法去调用即可。

这里有一个需要跟大家强调的地方,就是 addInputStream/addBytes/addString 等方法都需要设置资源名,这个名称是可以随意设置的,但是注意名称的后缀,需要是 bpmn20.xml 或者 bpmn,否则流程没有部署。为什么流程名后缀要是 bpmn20.xml 或者 bpmn 呢?参考第一小节。

3. 表分析

在我们的流程部署过程中,一共有三张表参与到我们的工作中了,虽然松哥之前已经写过文章和大家梳理 flowable 中各个数据表的作用,不过当时只是大致上介绍了一下,没有细说,这次我们就先来看看这次涉及到的三张表。

ACT_RE_DEPLOYMENT

这个表是流程部署表,每部署一个流程,这张表中就会新增一条记录,用来描述我们刚刚定义好的流程:

这里的 ID_、NAME_、CATEGORY_ 等等,就是我们在部署流程的时候设置的参数。

ACT_RE_PROCDEF

这是流程定义表,我们每定义的一个流程,都会记录在这张表中:

这张表中的字段比较多,我这里只是列出来了其中一部分。这这表中有一个 DEPLOYMENT_ID 字段,和 ACT_RE_DEPLOYMENT 表进行关联,所以 ACT_RE_DEPLOYMENT 和 ACT_RE_PROCDEF 表的关系,其实是一对一的关系,部署表中的一条记录对应定义表中的一条记录。

另外,该表中有一个 CATEGORY_ 的字段,这个字段表示流程的分类,注意这个和部署的分类可不一样,流程部署的分类参数第二小节的代码,流程的分类,说白了其实就是我们流程定义 XML 文件中的 targetNamespace 属性,如下图:

大家可根据自己的实际需求去修改 targetNamespace 属性的值,这个值改了之后,ACT_RE_PROCDEF 表中的 CATEGORY_ 字段也会跟着发生变化。

另外,该表中还有一个 VERSION_ 字段,这个看名字就知道是描述记录的版本号,当我们修改了流程的内容之后,重新部署的时候,ACT_RE_DEPLOYMENT 表和 ACT_RE_PROCDEF 表均会自动增加一条记录数,其中,流程定义表 ACT_RE_PROCDEF 中的记录的 VERSION_ 字段的值会自动加 1,这样我们就能够看到不同历史版本的流程定义。

那么系统是怎么识别修改后的流程和前一个流程是同一个呢?主要是靠流程的 id 属性,如下图:

这个流程的 id 属性,对应到表中,就是 ACT_RE_PROCDEF 表的 KEY_ 字段。

ACT_GE_BYTEARRAY

涉及到的第三张表是这个通用数据存储表,这个表的字段比较少,如下图:

小伙伴们看到,这个表中有一个 DEPLOYMENT_ID 字段,这个就是跟 ACT_RE_DEPLOYMENT 表关联的字段,一条流程部署记录在 ACT_GE_BYTEARRAY 表中对应两条记录,分别是记录 XML 文件和记录流程图片。

这个表中有一个 BYTES_ 字段,我们部署的流程的 XML 文件就保存在这里,同时,系统默认还会根据 XML 文件生成一张流程图片,也保存在这里,图片就像下面这种:

所以一个流程部署,在这张表中对应两条记录,一条记录 XML 文件,一条记录流程图片。

好啦,这就是流程部署涉及到的三张表。

4. 查询操作

接下来,强烈建议大家在 Spring Boot 的 application.properties 中添加如下配置,开启 flowable 日志:

logging.level.org.flowable=debug

这个配置表示开启 flowable 的日志,开启日志的好处是我们可以看到底层的 SQL,学习 flowable,调用 API 的时候,不能只掌握 API 的使用,调用 API 的时候,心里想着这是操作哪张表,学起来更快。

4.1 查询部署信息

例如我们现在想要查询流程的部署信息,如下:

@Test
void test01() throws IOException {
List<Deployment> list = repositoryService.createDeploymentQuery().list();
for (Deployment deployment : list){
logger.info("id:{};key:{}", deployment.getId(), deployment.getKey());
}
}

创建一个查询器,然后返回所有的流程部署信息并打印出来,我们看下此时 IDEA 控制台打印出来的 SQL 信息:

可以看到,底层执行的 SQL 其实就是去查询 ACT_RE_DEPLOYMENT 表。

现在我们再去看一些查询的方法,应该就很容易明白其含义了:

小伙伴们看到,我们可以利用流程部署的名字、分类、ID 等各种信息去查询,可以精确匹配也可以模糊匹配。

例如我想查询 key 为 javaboy的工作流key 的流程部署文件,但是这个流程我之前部署过多次(版本升级),现在我想查询最近一次的流程部署信息,查询方式如下:

@Test
void test01() throws IOException {
Deployment deployment = repositoryService.createDeploymentQuery().deploymentKey("javaboy的工作流key").latest().singleResult();
logger.info("id:{};key:{}", deployment.getId(), deployment.getKey());
}

我们来看下控制台打印出来的 SQL:

--- [           main] i.p.e.D.selectDeploymentsByQueryCriteria : ==>  Preparing: SELECT RES.* from ACT_RE_DEPLOYMENT RES WHERE RES.KEY_ = ? and RES.DEPLOY_TIME_ = (select max(DEPLOY_TIME_) from ACT_RE_DEPLOYMENT where KEY_ = RES.KEY_ and DERIVED_FROM_ is null and ( (TENANT_ID_ IS NOT NULL and TENANT_ID_ = RES.TENANT_ID_) or (TENANT_ID_ IS NULL and RES.TENANT_ID_ IS NULL) ) ) order by RES.ID_ asc
--- [ main] i.p.e.D.selectDeploymentsByQueryCriteria : ==> Parameters: javaboy的工作流key(String)
--- [ main] i.p.e.D.selectDeploymentsByQueryCriteria : <== Total: 1

这个 SQL 写的有点复杂,但是仔细看就一个意思,给定查询的 key 是 javaboy的工作流key,查询时间是一个最大的时间,这就很好懂了。

4.2 查询流程定义信息

接下来我们再来看看查询流程的定义信息。查询所有的流程定义信息,如下:

@Test
void test02(){
List<ProcessDefinition> list = repositoryService.createProcessDefinitionQuery().list();
for (ProcessDefinition pd : list){
logger.info("id:{};key:{};version:{};",pd.getId(),pd.getKey(),pd.getVersion());
}
}

来看看控制台打印的 SQL:

可以看到,就是去流程定义表 ACT_RE_PROCDEF 去查看所有。

基于此,其他的查询 API 就都好理解了,例如根据流程定义的 KEY 去查询所有的流程定义,这个 KEY 其实就是流程定义 XML 文件中的 id:

@Test
void test02(){
List<ProcessDefinition> list = repositoryService.createProcessDefinitionQuery().processDefinitionKey("javaboy_submit_an_expense_account").list();
for (ProcessDefinition pd : list){
logger.info("id:{};key:{};version:{};",pd.getId(),pd.getKey(),pd.getVersion());
}
}

我们来看下查询 SQL:

其他的查询 API 我就不挨个演示了,方法基本上都是见名知意的。

4.3 原生查询

要是觉得用 API 查询 不过瘾,我们也可以自己写 SQL 查询。

跟前面一样,例如我想查询 key 为 javaboy的工作流key 的流程部署文件,但是这个流程我之前部署过多次(版本升级),现在我想查询最近一次的流程部署信息,查询方式如下:

@Test
void test03(){
Deployment deployment = repositoryService.createNativeDeploymentQuery().sql("SELECT RES.* from ACT_RE_DEPLOYMENT RES WHERE RES.KEY_ = #{key} and RES.DEPLOY_TIME_ = (select max(DEPLOY_TIME_) from ACT_RE_DEPLOYMENT where KEY_ = RES.KEY_) order by RES.ID_ asc").parameter("key","javaboy的工作流key").singleResult();
logger.info("id:{};key:{}", deployment.getId(), deployment.getKey());
}

自己写 SQL 即可,参数的占位符用 #,因为这里底层的 SQL 操作实际上是 MyBatis。

相同的道理,我想根据流程定义的 KEY 去查询流程定义信息,使用原生查询方式如下:

@Test
void test04(){
List<ProcessDefinition> list = repositoryService.createNativeProcessDefinitionQuery()
.sql("SELECT RES.* from ACT_RE_PROCDEF RES WHERE RES.KEY_ = #{key} order by RES.ID_ asc")
.parameter("key","javaboy_submit_an_expense_account").list();
for (ProcessDefinition pd : list){
logger.info("id:{};key:{};version:{};", pd.getId(), pd.getKey(), pd.getVersion());
}
}

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/269119.html<

(0)
管理的头像管理
上一篇2025-05-07 05:05
下一篇 2025-05-07 05:06

相关推荐

  • 云服务器和云虚拟主机怎么选?云服务器和虚拟主机区别

    云服务器适合业务增长快、需弹性扩展的场景,而云虚拟主机适合预算有限、技术门槛低的小型静态网站或测试环境,二者核心区别在于资源独享性与运维复杂度,核心差异解析:从底层架构到使用体验很多人容易混淆这两者,觉得它们都是“买空间建站”,它们的底层逻辑完全不同,云服务器(ECS)就像是你租了一整栋别墅,水电网络独立,你想……

    2026-06-29
    0
  • 赣州智慧旅游招聘是真的吗?赣州旅游人才招聘信息

    中级岗位(3-5年经验)月薪范围通常在6000-10000元,这类岗位需要独立负责项目模块,如独立运营一个抖音账号,或维护一个景区小程序的功能迭代,具备成功案例的候选人议价能力较强,高级岗位(5年以上经验)月薪范围通常在10000-20000元,部分核心管理岗可达更高,这类人才需要具备战略规划能力,如制定整个景……

    2026-06-29
    0
  • 赣州智能物联网车位锁如何管理?智能车位锁管理系统多少钱

    赣州智能物联网车位锁管理的核心在于通过云端平台实现远程控锁、状态实时监控及自动计费,彻底解决传统车位“被占难管”与“找位难”的痛点,在赣州这样的城市,随着机动车保有量的持续增长,老旧小区、商业综合体以及私人固定车位的资源矛盾日益凸显,传统的机械地锁或简易遥控锁,不仅操作繁琐,更无法实现数据化管理,引入智能物联网……

    2026-06-29
    0
  • 赣州智能消防栓好用吗,智能消防栓多少钱一个

    赣州智能消防栓通过物联网技术实现实时监测与远程报警,能显著降低火灾响应时间并提升城市消防安全管理水平,是目前智慧城市建设中不可或缺的基础设施,赣州智能消防栓的核心价值与应用场景传统消防栓往往存在“看不见、摸不着、用不了”的痛点,在赣州这样地形复杂、老城区与新城区并存的区域,传统设施的管理难度极大,智能消防栓的出……

    2026-06-29
    0
  • 云服务器和物理机到底有啥区别?

    云服务器本质上是虚拟化资源池中的弹性实例,而传统物理服务器是独占的硬件实体,前者胜在弹性与运维便捷,后者强在物理隔离与性能稳定,具体选择取决于业务对成本、扩展性及安全合规的权衡,很多人初次接触服务器时,容易把“云服务器”和“传统物理服务器”混为一谈,觉得它们都是用来跑网站或存数据的盒子,这两者的底层逻辑完全不同……

    2026-06-29
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注