Flowable实战（五）表单和流程变量

  流程实例按步骤执行时，需要保存并使用一些数据，在并悉Flowable中，这些数据称为变量（ variable ）。

  流程实例可以持有变量，称作流程变量（ process variables ）。

  为了使用效率，Flowable将变量分为两种：运行时变量、历史变量。

  流程实例运行时的变量，存入act_ru_variable表中。在流程实例运行结束时，此实例的变量在表中删除。

  在流程实例创建及启动时，可设置流程变量。所有的 startProcessInstanceXXX 方法都有一个可选参数用于设置变量。例如，在 RuntimeService 中：

  也可以在流程执行中加入变量。例如，( RuntimeService ):

  读取变量方法（请注意 TaskService 中有类似的方法。这意味着任务与执行一样，可以持有局部变量，其生存期为任务持续的时间。）

  历史变量，存入act_hi_varinst表中。在流程启动时，流程变量会同时存入历史变量表中；在流程结束时，历史表中的变量仍然存在。可理解为“永久代”的流程变量。

  获取已完成的、id为’XXX’的流程实例中，所有的HistoricVariableInstances（历史变量实例），并以变量名排序。

  在实际业务中，流程伴随着各种各样的表单，Flowable引擎将表单数据统一作为流程变量存入变量表中。所以，对于Flowable引擎，可以完全独立于表单运行，因为可以用流程变量替代表单数据。

  但一般的，我们需要结构化的数据，表单仍然是我们推荐的用法。

  表单定义有两种方法，内置表单和外部表单。

  以请假为例，XML内容：

  使用方法：

  或

  内置表单了解即可，实际应用更多的是使用外部表单。

  根据表单文件自行渲染的任务表单，称为外部表单。

  在springboot环境下， resources/forms 目录下任何.form后缀的表单定义文件都会被自动部署。

  例如，将2.2.2表单定义内容保存为leave.form文件，放入 resources/forms 目录下。

  实际键搜上，渲染表单所需的所有数据都组装在下面两个方法：

  可以通过下面两个方法提交表单参数：

  表单参稿蔽历数FormProperty的具体信息：

  获取指定流程实例的表单数据的方法：

  提交表单数据的方法：

  表单数据实际存放在流程变量表，所以，用流程变量的方法同样可以获取及提交表单数据。

   表单支持以下类型字段

  在实际应用中，Flowable提供的表单字段类型并不能完全满足需求，往往我们需要自定义表单字段类型。

  所有自定义字段类型需要继承一个表达类型抽象类“org.flowable.engine.form.AbstractFormType”。

  比如，定义一个"卡片"自定义类型：

  新建配置类，注册自定义字段类型解析类

  Flowable支持自定义表单引擎以适应各种场景。只需要实现接口org.flowable.engine.impl.form.FormEngine，然后在引擎中注册自定义的表单引擎实现类即可。

  注册方法与自定义表单字段类型相似，在配置类中加入以下语句：

  使用方法：

  通过本篇，我们了解到了表单和流程变量的具体使用，同样的，在实际业务使用中，还需要不少优化。比如，我们可以在formKey中保存通用的key，通过算法或转换得到实际需要使用的表单模板，在普通屏幕尺寸的Web应用中显示一个表单，在手机等小屏幕中显示另一个表单。还有下一篇将讲到的“集成JPA”，进一步对表单和流程变量的使用做出优化。

一 表结构

前面一章的关于spring的demo，我们配置好数据库，第一次会自动为我们给的数据库生成对应的表，但是表实在是太多，网上一些资料比较过时，举个例子有的材料列举了二十几个，但实际上我这个版本不止，我随便数了一下都七十几个了。

还有就是Flowable的表很多创建的名字也是为了启慎芦能“见词知意”，会有前缀或者类似“词根”之类的来拼接。同样很多人的资料博客关于这些，好像抄的是同一份一样。都是常见的几个，你想DMN这些都没人提及。

这里以我现在的flow able表结构做一个大概的总结介绍：

首先上个图

在这里插入图片描述

在这里插入图片描述

大概表名分三段

XXX_XXX_XXXX

第一段

第一段以ACT_APP_APPDEF 和 FLW_CHANNEL_DEFINITION为例子

ACT代表的Activiti 毕竟是同一批人另起的炉灶，另一方面遵循的都是BPMN还要考虑到兼容人家，方便客户转移过来。

ACT_APP_APPDEF看字面意思是应用定义表。

FLW估计就孝氏是Flowable的自己的时缩写。

FLW_CHANNEL_DEFINITION这个的意思是，Flowable支持JMS、Kafka和RabbitMQ源和目标，但也可以使用其他适配器类型进行扩展。部署通道定义时，新定义将插入到FLW_CHANNEL_DEFINITION表中，表明翻译过来Flowable的渠道定义。

第二段

APP指的是应用

CO 我认为是connection连接的意思，我看内容大部分跟连接数据库这些相关

act_cmmn_:CMMN流程引擎数据

act_dmn_ : DMN流程引擎

act_evt_log: 事件日志

act_fo_:表单引擎数据

act_ge_: 通用数据

act_hi_:表包含历史数据

act_id_:存储与用户身份相关数据

act_prodef_info:流程定义的悄带信息

act_re_: 流程定义相关数据的存储库

act_ru__:流程实例运行时数据，流程结束删除数据

第三段

实际上这一段，如果不是太长，有的很多就是整个单词，DEF就是定义的意思，DECISION就是描述的意思，JOB就是任务等，总之就是相对第二段比较容易看出来，像DMN谁能一眼看出来到底是什么。

怎么说呢，太多了这些，基本是遇到问题看那个，记住几个常用的就可以了，不一定都能接触的到，同样也能想象出这个工作流设计要多复杂，我们自己的一些审批任务，基于人家的又是都觉得有点绕，何况人家提供的基础的服务支持设计的。

流程变量

流程实例执行时，要保存数据，这些都被称作变量variable，流程变量分两种：运行时变量，历史变量。

运行时变量

就是还在运行的流程实例的持有的变量，流程实例结束了，这个实例的变量也就在这个表的被剔除了，变成历史变量。

运行时变量，存的表是act_ru_variable

#定义时就设置了变量

ProcessInstance startProcessInstanceByKey(String processDefinitionKey, Map<String, Object>variables)

#或者运行中设置变量

void setVariable(String executionId, String variableName, Object value)

void setVariableLocal(String executionId, String variableName, Object value)

void setVariables(String executionId, Map<String, ? extends Object>variables)

void setVariablesLocal(String executionId, Map<String, ? extends Object>variables)

#都运行时变量，这个如果实例运行完了就查不到留在这个表

Map<String, Object>getVariables(String executionId)

Map<String, Object>getVariablesLocal(String executionId)

Map<String, Object>getVariables(String executionId, Collection<String>variableNames)

Map<String, Object>getVariablesLocal(String executionId, Collection<String>variableNames)

Object getVariable(String executionId, String variableName)

<T>T getVariable(String executionId, String variableName, Class<T>variableClass)

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

历史变量

历史变量其实算是比较多的，一般来说除非是运行时实例，自己这边出问题直接看问题看的是运行时的变量（其实这个也能在历史变量中看到）。如果是对已经审批完的流程有疑问基本看的都是历史变量。

历史变量，存的是act_hi_varinst表act_hi_varinst

实例创建，历史变量有对应的变量，实力结束依旧能找到，可以说时变量的“永久”。

historyService.createHistoricVariableInstanceQuery()

.processInstanceId("XXX")

.orderByVariableName.desc()

.list()

1

2

3

4

5

1

2

3

4

5

重要字段介绍

（1）processDefinitionId 流程定义Id

（2）processDefinitionKey 流程定义Key

（3）processDefinitionName 流程定义名称

（4）procInstId 流程实例Id

（5）taskId 任务Id

（6）executionId 执行Id

前三个都是流程定义的，就是说我们发起流程通过ID，key，name这些来发起流程。

你发起流程就会有一个实例，大概的例子就是Java的calss和对象一样，class定义了整体的结构和意义，但是真正用的还是被new出来并且赋值的一个个对象。流程就是class，你定义好了，去处理一个个具体的场景时，就是一个个具体的对象，也就是流程实例。

（4）（5）（6）其实是一级一级的关系，一个流程实例ID可以对应多个执行ID，一个执行对应多个task（这个我后面验证一下，暂时我这边也不太确定），反正大多数材料形容三个的关系是“面-》线-》点”。

表单

表单其实就是定义的部分，就是通过一种简单的方式去构造一个flowable流程引擎。

（看下面的官网最新的英文解释，更对味，可以参照后面某个版本的flowable的中文手册翻译）

The Flowable Form engine is structured in a very similar way to the Flowable process engine. As a result parts of the documentation have a resemblance with their process engine counterpart.

在这里插入图片描述

在这里插入图片描述

在实际业务中，流程伴随着各种各样的表单，Flowable引擎将表单数据统一作为流程变量存入变量表中。所以，对于Flowable引擎，可以完全独立于表单运行，因为可以用流程变量替代表单数据。

但一般的，我们需要结构化的数据，表单仍然是我们推荐的用法。

表单：内置表单，外部表单

内置表单

以请假为例，XML内容

<process id="leave" name="请假流程-内置表单">

<startEvent id="start">

<extensionElements>

<flowable:formProperty id="startDate" name="请假开始事件" type="date"

datePattern="dd-MMM-yyyy" required="true" readable="true" writeable="true"/>

<flowable:formProperty id="endDate" name="请假结束事件" type="date"

datePattern="dd-MMM-yyyy" required="true" readable="true" writeable="true"/>

<flowable:formProperty id="reason" name="请假原因" type="string"

required="true" readable="true" writeable="true"/>

<flowable:formProperty id="leaveType" type="enum" name="请假类型">

<flowable:value id="personalLeave" name="事假" />

<flowable:value id="annualLeave" name="年假" />

</flowable:formProperty>

</extensionElements>

</startEvent>

</process>

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

StartFormData FormService.getStartFormData(String processDefinitionId)

1

1

或

TaskFormData FormService.getTaskFormData(String taskId)

1

1

外部表单

根据表单文件自行渲染的任务表单，称为外部表单。

<process id="leave" name="请假流程-内置表单">

<startEvent id="start" flowable:formKey="form1"></startEvent>

</process>

1

2

3

4

1

2

3

4

外部表单的定义

表单定义文件的后缀为.form。

表单的JSON定义以key、name和description开头。

表单引擎通过属性key来辨别表单在整个表单引擎中的唯一身份。对于来源相同的同一个表单定义的版本系统也是基于属性key运作的。

第二部分是一个数组类型fields，表单定义的字段在这里阐明。

第三部分是可选的，用来定义表单的结果outcomes。

xml文件例子

{

"key": "form1",

"name": "My first form",

"fields": [

{

"id": "input1",

"name": "Input1",

"type": "text",

"required": false,

"placeholder": "empty"

}

],

"outcomes": [

{

"id": "null",

"name": "Accept"

},

{

"id": "null",

"name": "Reject"

}

]

}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

部署表单

在springboot环境下，resources/forms目录下任何.form后缀的表单定义文件都会被自动部署。

实际应用中，应当让前端流程设计器生成指定格式的表单定义文件，通过与前文提到的接口方式，更新部署流程定义及表单定义资源。

获取及提交表单参数

实际上，渲染表单所需的所有数据都组装在下面两个方法：

StartFormData FormService.getStartFormData(String processDefinitionId)

TaskFormdata FormService.getTaskFormData(String taskId)

1

2

3

1

2

3

ProcessInstance FormService.submitStartFormData(String processDefinitionId, Map<String,String>properties)

void FormService.submitTaskFormData(String taskId, Map<String,String>properties)

---