Flowable表结构解析：深入理解工作流引擎的数据存储设计

Flowable作为一款强大的开源业务流程管理（BPM）引擎，其数据库表结构设计体现了模块化、高效性和可扩展性。本文将从表命名规则、核心引擎表结构及功能模块表三个方面，全面解析Flowable的数据库表设计。

一、表命名规则与通用结构

Flowable的表名遵循前缀+功能标识+后缀的命名规则，便于快速识别表的用途和所属模块：

1. 前缀分类：
   • ACT_：核心引擎表（如流程引擎、CMMN引擎、DMN引擎）。
   • FLW_：Flowable扩展模块（如Action、Audit、Form等）。
   • FLWCTRL：Flowable控制模块相关表。
2. 功能标识：
   • GE_：通用数据，例如ACT_GE_PROPERTY存储引擎配置。
   • RU_（Runtime）：运行时数据，仅存储未完成实例，执行完成后删除。
   • HI_（History）：历史数据，持久化存储已完成实例。
   • RE_（Repository）：静态模型定义，例如流程定义。
3. 通用后缀：
   • DEPLOYMENT：部署记录。
   • DEPLOYMENT_RESOURCE：部署资源，存储模型文件（如BPMN文件）。
   • DEFINITION：定义信息，如流程定义或表单定义。

示例：

• ACT_RU_EXECUTION：记录流程实例的运行时执行路径。
• ACT_HI_PROCINST：存储已完成的流程实例历史记录。

二、核心引擎表结构

1. 流程引擎（Process Engine）

流程引擎是Flowable的核心，相关表分为运行时表、历史表和模型仓库表。

• 运行时表（ACTRU*）：
  • ACT_RU_EXECUTION：流程实例及执行路径。
  • ACT_RU_TASK：未完成的用户任务。
  • ACT_RU_VARIABLE：流程变量。
  • ACT_RU_JOB：异步任务（如定时器）。
• 历史表（ACTHI*）：
  • ACT_HI_PROCINST：流程实例历史。
  • ACT_HI_TASKINST：任务执行历史。
  • ACT_HI_ACTINST：活动节点历史。
• 模型仓库表（ACTRE*）：
  • ACT_RE_DEPLOYMENT：部署记录。
  • ACT_RE_PROCDEF：流程定义元数据。

2. CMMN引擎（Case Management）

CMMN（案例管理模型和符号）用于处理非结构化流程。

• 运行时表（ACTCMMN_RU*）：
  • ACT_CMMN_RU_CASE_INST：未完成的案例实例。
  • ACT_CMMN_RU_PLAN_ITEM_INST：案例计划项实例。
• 历史表（ACTCMMN_HI*）：
  • ACT_CMMN_HI_CASE_INST：历史案例实例。
  • ACT_CMMN_HI_MIL_INST：里程碑达成记录。

3. DMN引擎（决策引擎）

DMN（决策模型和符号）用于定义和执行业务规则。

• ACT_DMN_DECISION_TABLE：决策表元数据。
• ACT_DMN_HI_DECISION_EXECUTION：决策执行历史。

三、功能模块表结构

1. 表单引擎（Form Engine）

• FLW_FO_FORM_DEFINITION：表单定义。
• FLW_FO_FORM_INSTANCE：表单实例数据（例如用户填写的具体表单内容）。

2. 身份管理（Identity Engine）

• FLW_ID_USER：用户信息。
• FLW_ID_GROUP：用户组信息。
• FLW_ID_MEMBERSHIP：用户与组的关系。

3. 内容管理（Content Engine）

• FLW_CO_CONTENT_ITEM：内容项元数据。
• FLW_CO_CONTENT_OBJECT：存储二进制内容（如上传的文件）。

4. 审计模块（Audit Engine）

• FLW_AUDIT_INSTANCE：业务事件审计记录。

5. 服务与策略

• 服务引擎（Service Engine）：
  • FLW_SE_DEFINITION：服务定义（如REST服务配置）。
• 策略引擎（Policy Engine）：
  • FLW_POLICY_DEFINITION：访问策略定义。

四、表关系与性能优化

1. 表关系图

Flowable的表通过关键字段（如PROCINST_ID、 TASKID）建立关联。以下是一个简化的表关系示例：

ACT_RE_PROCDEF (流程定义)
  └── PROC_DEF_ID_ → ACT_RU_EXECUTION (流程实例)
       └── PROC_INST_ID_ → ACT_RU_TASK (任务)
            └── TASK_ID_ → ACT_HI_TASKINST (任务历史)

说明：

• ACT_RE_PROCDEF定义流程模型，部署后生成流程实例存储在ACT_RU_EXECUTION中。
• 流程实例产生任务，记录在ACT_RU_TASK，完成后归档至ACT_HI_TASKINST。

2. 性能优化建议

• 索引创建：为高频查询字段（如PROCINST_ID、 TASKID）添加索引，提升查询效率。 示例SQL：

CREATE INDEX idx_proc_inst_id ON ACT_RU_EXECUTION (PROC_INST_ID_);

• 数据归档：定期将ACTHI*表中的历史数据归档到单独的归档表，减少主表压力。
• 批量操作：在高并发场景下，使用批量插入和更新，减少数据库交互次数。

与其他BPM引擎的比较

与Flowable相比，Activiti作为其前身提供了基础架构，但功能较为基础；Camunda虽有相似表结构，但针对企业级应用进行了更多优化；jBPM则采用完全不同的设计理念，与Drools规则引擎的集成更为紧密。Flowable在继承Activiti基础上，通过增加CMMN、DMN支持和更丰富的扩展模块表结构，提供了更全面的BPM解决方案。

五、实践案例

1. 流程实例存储示例

在一个请假审批流程中：

• 流程启动后，ACT_RU_EXECUTION记录流程实例ID和当前节点（如"经理审批"）。
• ACT_RU_TASK记录审批任务的详细信息（如任务名称、负责人）。
• 流程完成后，数据迁移至ACT_HI_PROCINST（流程实例历史）和ACT_HI_TASKINST（任务历史）。

2. 性能瓶颈优化

在高并发场景下，ACTRU_TASK表的任务查询可能变慢。通过为PROC_INST_ID和TASKDEF_KEY创建复合索引，可显著提升性能：

CREATE INDEX idx_task_proc_def ON ACT_RU_TASK (PROC_INST_ID_, TASK_DEF_KEY_);

3. 数据归档实践

对于历史数据量大的系统，可每月执行脚本将ACTHI*表的数据迁移至归档表（如ACT_HI_PROCINST_ARCHIVE），保持主表轻量化。

六、数据库脚本与维护

• 初始化脚本：Flowable提供SQL脚本（如flowable.engine.sql、flowable.work.sql）用于手动建表。
• 自动更新配置：

flowable.database-schema-update=true  # 自动校验并更新表结构
flowable.database-schema-update=ignore # 禁用自动管理

• 升级策略：升级时需按顺序执行脚本，先运行flowable.engine.sql，再运行flowable.work.sql。

七、 总结

Flowable通过模块化的表结构设计，将运行时数据（ACTRU）与历史数据（ACTHI）分离，既满足高性能查询需求，又支持长期审计。其命名规则（如ACT、FLW前缀和RU、HI标识）使开发者能快速定位数据位置。结合性能优化、实践案例和未来展望，开发者可充分利用Flowable表结构，优化流程性能、扩展功能并高效解决问题。

参考资料

• Flowable中文文档