Flowable 流程部署与删除
本文我们一起来看看流程的部署等细节问题。
其实当我们使用了 Spring Boot 之后，默认情况下流程是会自动部署的，基本上不需要我们额外做什么事情。不过这些操作里还是有不少细节，今天松哥就来带大家一起来梳理一下。
1. 默认行为
首先我们先来梳理一下默认行为。
默认情况下，我们放在 resources/processes 目录下的所有流程文件会自动被部署，流程文件的后缀有两种形式 bpmn20.xml 或者 bpmn。当然，无论是存放流程文件的位置，还是流程文件的格式，都是可以定制的，涉及到的属性主要有三个，可在 application.properties 中进行配置：
flowable.check-process-definitions：这个表示是否在项目启动的时候，去检查文件目录是否有对应的流程文件，该属性为 true 表示如果有流程文件就自动部署，false 表示不检查，那么也就不会自动部署。flowable.process-definition-location-prefix：这个是流程文件的位置，默认就是classpath*:/processes/，当然开发者也可以进行配置。flowable.process-definition-location-suffixes：这个是流程文件的后缀，默认有两个，分别是**.bpmn20.xml和**.bpmn，当然开发者也可以进行配置。
这个配置应该没啥好说的。
2. 动态部署
有的时候，我们的流程可能并不是提前设计好的，而是项目启动之后，动态部署的，例如项目启动成功之后，动态上传一个流程的 XML 文件进行部署，这也是一种比较常见的场景，对于这种情况，我们可以按照如下方式进行部署：
我这里给了一个简单的文件上传接口，关于文件上传部分我就不多说了。我们来看下流程部署：
首先通过 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 日志：
这个配置表示开启 flowable 的日志，开启日志的好处是我们可以看到底层的 SQL，学习 flowable，调用 API 的时候，不能只掌握 API 的使用，调用 API 的时候，心里想着这是操作哪张表，学起来更快。
4.1 查询部署信息
例如我们现在想要查询流程的部署信息，如下：
创建一个查询器，然后返回所有的流程部署信息并打印出来，我们看下此时 IDEA 控制台打印出来的 SQL 信息：
可以看到，底层执行的 SQL 其实就是去查询 ACT_RE_DEPLOYMENT 表。
现在我们再去看一些查询的方法，应该就很容易明白其含义了：
小伙伴们看到，我们可以利用流程部署的名字、分类、ID 等各种信息去查询，可以精确匹配也可以模糊匹配。
例如我想查询 key 为 javaboy的工作流key 的流程部署文件，但是这个流程我之前部署过多次（版本升级），现在我想查询最近一次的流程部署信息，查询方式如下：
我们来看下控制台打印出来的 SQL：
这个 SQL 写的有点复杂，但是仔细看就一个意思，给定查询的 key 是 javaboy的工作流key，查询时间是一个最大的时间，这就很好懂了。
4.2 查询流程定义信息
接下来我们再来看看查询流程的定义信息。查询所有的流程定义信息，如下：
来看看控制台打印的 SQL：
可以看到，就是去流程定义表 ACT_RE_PROCDEF 去查看所有。
基于此，其他的查询 API 就都好理解了，例如根据流程定义的 KEY 去查询所有的流程定义，这个 KEY 其实就是流程定义 XML 文件中的 id：
我们来看下查询 SQL：
其他的查询 API 我就不挨个演示了，方法基本上都是见名知意的。
4.3 原生查询
要是觉得用 API 查询 不过瘾，我们也可以自己写 SQL 查询。
跟前面一样，例如我想查询 key 为 javaboy的工作流key 的流程部署文件，但是这个流程我之前部署过多次（版本升级），现在我想查询最近一次的流程部署信息，查询方式如下：
自己写 SQL 即可，参数的占位符用 #，因为这里底层的 SQL 操作实际上是 MyBatis。
相同的道理，我想根据流程定义的 KEY 去查询流程定义信息，使用原生查询方式如下：
好啦，关于流程的部署和定义就和大家聊这么多，下篇文章我们来看流程实例～
版权声明: 本文为 InfoQ 作者【江南一点雨】的原创文章。
原文链接:【http://xie.infoq.cn/article/cc5572e496c3a94232230812b】。未经作者许可，禁止转载。
技术宅 2019.04.09 加入
Java猿
评论