企业官网建设流程全解析

简介：面向Flowable工作流引擎的开发者与运维人员，这份压缩包提供了Flowable 6.7.2在MySQL和Oracle两种数据库下的建表SQL脚本，解决流程引擎初始化时表结构搭建问题，免除手工逐张建表的工作。压缩包共2个SQL文件，大小约17KB，分别覆盖MySQL与Oracle环境，脚本中涵盖流程部署定义表、运行时实例任务表、历史数据表、流程变量表、事件订阅表及通用辅助表等核心数据对象，并针对Oracle特有数据类型与约束进行了适配。资源已有1826人学习，适合正在部署、调优或二次开发Flowable的工程师，也可作为初学者的表结构学习素材。通过执行这些脚本，不仅能快速建立数据库环境，还能从表名与字段设计中理解流程定义缓存、任务办理、历史查询、事件消息等底层机制，为定制工作流应用提供参考。表结构与引擎服务接口对应清晰，便于开发时按需定位，是深入掌握Flowable的重要基础。 上个月帮一个朋友排查历史项目，流程引擎一直起不来，日志卡在Table 'flowable.ACT_GE_PROPERTY' doesn't exist。项目用的是 Flowable 6.7.2，生产环境是 MySQL，验收机房还单独有一套 Oracle，两边库都得初始化数据库建表脚本，真的折腾。折腾完我最大的感受是：Flowable 本身是个很成熟的嵌入式工作流引擎，但不少项目偏偏死在最不起眼的第一关——数据库建表。这份整理好的 Flowable 6.7.2 数据库建表 SQL 脚本（MySQL + Oracle 双版本），就是解决这个问题的。它适合正在做 OA、工作流平台、低代码流程化改造的 Java 开发，也适合要给客户批量交付项目的实施工程师，核心价值是离线环境下快速初始化流程引擎库、提前给 DBA 评审表结构、以及从零搭出一套可演示的引擎环境。

1. 为什么 Flowable 6.7.2 建表脚本值得被单独整理成资源包

1.1 官方脚本不是没有，而是藏得太深

Flowable 每次发布版本，其实都会把完整的数据库脚本带在构建产物里，但很多项目根本找不到。你从 GitHub Releases 下载flowable-6.7.2.zip，解压后能看到database目录，里面按create、drop、upgrade分了三层，create目录下就是各数据库的建表脚本。如果项目是通过 Maven 依赖引入 flowable-engine，脚本也会被一起打包进 jar，路径通常在org/flowable/db/create/下面。

问题就出在这：内网部署、离线交付的时候，很多团队手里只有一个业务包和一份流水账式部署说明，压根没有官方 zip 或 jar。就算找到了，也会发现脚本不是一个all-in-one.sql，而是几十个按模块拆分的独立文件。第一次用的人很容易懵：到底先跑哪个？哪些必须跑？哪些可以不跑？我把 6.7.2 的 MySQL 和 Oracle 脚本单独抽出来打成 zip，其实就是把"从官方产物里翻脚本、挑模块、理顺执行顺序"这件事提前做掉了，拿到手直接能用。

1.2 自动建表模式并不是银弹

有人会问：Flowable 不是支持自动建表吗，为什么还要手动执行 SQL？确实，开发环境把引擎的databaseSchemaUpdate配成true，启动时会自动补表，非常省事。但真实项目里这套机制经常跑不通。先说权限：企业级数据库，应用账号通常只有 DML 权限，DDL 必须过 DBA 审批，自动建表根本不具备执行条件。再说变更管理：自动建表是个黑盒操作，建了哪些表、字段什么类型、索引叫什么名，DBA 完全不可控，后面升级、备份、闪回都难做。

手动执行脚本的过程，本质上是把建表动作纳入发布单和评审流程，每一步都可回放、可追溯。所以我一直倾向于把建表脚本当成一次普通的数据库版本变更来对待，而不是让引擎在启动瞬间"顺手"把库结构改了。

2. 打开 zip 看结构：双数据库双套脚本的组成逻辑

2.1 按模块拆分的 create 脚本到底有多少份

zip 解开后，顶层分mysql和oracle两个目录，内部目录结构完全一致。create目录下不是一个大而全的文件，而是按 Flowable 引擎模块拆分的多份脚本，命名规律是flowable.{数据库类型}.create.{模块名}.sql。

核心 engine 模块对应flowable.mysql.create.engine.sql，历史模块对应flowable.mysql.create.history.sql，还有 identitylink、entitylink、job、eventsubscription 这几个边界清晰的脚本模块。如果你要启用 CMMN、DMN、FORM、CONTENT、APP 这些扩展引擎，还能看到对应的模块脚本。每个模块主要管哪些表，从前缀就能看出来：

如果你只做纯 BPMN 工作流，优先保证 engine、history 两个脚本落库即可，其他模块按需执行。不启用对应引擎就不建对应模块的表，这样能省下不少表。这也是这个 zip 的实际价值之一：给你一个按模块取舍的清晰视图。

2.2 配套的 drop 与 upgrade 脚本怎么用

create目录之外，还有drop目录和upgrade目录。drop目录下的脚本命名和create一一对应，把flowable.create换成flowable.drop就是清理脚本，适合测试环境重置或者版本回滚时删表。

注意 drop 脚本存在外键约束，建议按模块逆序执行，否则可能出现删不掉表的情况。upgrade目录里则是版本升级脚本，比如从 6.7.1 升到 6.7.2，直接跑对应的 upgrade 步骤脚本即可，不用 drop 重建。我的习惯是：升级前先全库备份，然后在测试库完整跑一遍 upgrade，用ACT_GE_PROPERTY表里的版本号确认升级结果，再上生产。

3. MySQL 版脚本：从建库到验证的完整执行链路

3.1 建库字符集和排序规则不能想当然

MySQL 版脚本执行前，第一步是把库建好。我见过不少同学直接CREATE DATABASE flowable就开跑，后面流程变量存中文出现乱码才回头改库，非常被动。Flowable 的建表脚本本身没有写死字符集，用的是数据库默认值，所以建库时一定要把字符集定好：

CREATE DATABASE flowable DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

utf8mb4比utf8多出来的部分是四字节表情和生僻字，审批意见、表单富文本内容经常会出现这些字符，直接上utf8mb4最省心。排序规则选utf8mb4_bin是因为它做的是二进制比较，流程定义 key、任务标识这类字段按精确匹配处理，更符合引擎的预期。

另外，JDBC 连接串里最好带上characterEncoding=utf8、serverTimezone=Asia/Shanghai这两个参数，不然中文乱码和日期时区问题能折腾一整天。如果 MySQL 实例还没有设置lower_case_table_names，建议统一为 1。Flowable 生成的表名都是小写，Linux 环境下表名大小写敏感，保持统一小写策略能避免很多莫名其妙的表找不到问题。

3.2 source 执行顺序与常见报错

建好库后，在 mysql 客户端里进入对应库，用source逐份执行脚本。我的推荐顺序是：engine、eventsubscription、identitylink、entitylink、job、history，最后按需执行 cmmn、dmn、form、content、app。这个顺序不是绝对的，但能减少外键找不到表的概率。

执行中最常见的报错有两类。一类是重复执行导致表已存在，这类报错可以忽略，前提是你确定上一轮脚本已经完整跑过。另一类是 InnoDB 索引过长，报 1071 或 1709，常见于旧版本 MySQL 5.6 搭配 utf8mb4 的场景，解决方式是升级 MySQL 版本，或者在建库时退回 utf8 字符集。

跑完以后别急着走，先查一下表数量：

USE flowable; SHOW TABLES LIKE 'ACT\_%'; SHOW TABLES LIKE 'FLW\_%';

如果核心模块都执行了，能看到几十张 ACT_ 开头的表，基本说明脚本成功落库。

3.3 建表完成后如何确认版本正确写入

Flowable 会在ACT_GE_PROPERTY表里记录自身 schema 版本，这是判断初始化有没有成功的硬指标。执行：

SELECT * FROM ACT_GE_PROPERTY;

正常情况下能看到 name 为schema.version的记录，value 是 6.7.2 开头、带小版本号的编号，同时还有next.dbid、schema.history等条目。如果schema.version不存在，说明漏跑了某个核心脚本，哪怕show tables看着像模像样，引擎启动时照样会报版本不匹配。这一步验证在整个初始化流程里最容易漏，但恰恰最值得花十秒做掉。

4. Oracle 版脚本：权限、表空间与对象大小写三座大山

4.1 账号权限最小集：能建表不等于能跑引擎

Oracle 这边第一关不是表结构，而是账号怎么建。很多人图省事直接GRANT DBA给 flowable 用户，这当然能跑起来，但后续安全审计会很难看。Flowable 在 Oracle 上需要的权限其实不多：建表、建序列、建触发器、会话连接，外加表空间配额就够了。常见的最小授权脚本长这样：

CREATE TABLESPACE flowable_ts DATAFILE '/u01/app/oracle/oradata/ORCL/flowable01.dbf' SIZE 2G AUTOEXTEND ON NEXT 512M MAXSIZE 32G; CREATE USER flowable IDENTIFIED BY "your_password" DEFAULT TABLESPACE flowable_ts QUOTA UNLIMITED ON flowable_ts; GRANT CREATE SESSION TO flowable; GRANT CREATE TABLE TO flowable; GRANT CREATE SEQUENCE TO flowable; GRANT CREATE TRIGGER TO flowable;

表空间数据文件路径要跟实际 ORACLE_HOME 和实例名一致，SIZE 可以根据预估流程实例量调整。只给 CREATE SESSION 和 CREATE TABLE 不一定够，因为引擎运行时要靠序列取 ID、靠触发器维护增量，所以 CREATE SEQUENCE 和 CREATE TRIGGER 是必须的。独立账号、独立表空间，后面做数据迁移和清理会省事很多。

4.2 主键、CLOB、Sequence 在脚本里的特殊处理

Oracle 和 MySQL 的建表语法差异，Flowable 脚本里已经处理好了，但你要知道差异在哪，排查问题时才有方向。MySQL 的表用 AUTO_INCREMENT 自增主键，Oracle 版本则用 SEQUENCE 加 BEFORE INSERT 触发器，所以同一个字段会同时出现序列和触发器两份对象。流程变量表、历史详情表里的大文本内容，Oracle 版用的是 CLOB，MySQL 对应的是 TEXT/LONGTEXT。这类字段不要试图在 Oracle 里改成 VARCHAR2，超过 4000 字节会直接报错。

另外，Oracle 12c 之前的标识符长度限制是 30 字节，Flowable 6.7.2 官方脚本在命名上已经避开了这个限制，但你自己手工加索引或外键时要注意，别把长表名和长列名直接拼接成约束名，否则会出现 ORA-00972。执行 Oracle 脚本时，建议用 SQL*Plus 或 PL/SQL Developer 的 Command Window，用@文件路径方式执行，避免复制粘贴大段脚本时分隔符错乱。

4.3 ORA- 报错现场复盘

我在 Oracle 上执行时踩过的报错主要有三个。

ORA-00955：名称已被现有对象占用，八成是一份脚本重复执行导致的，序列和触发器最容易留存同名对象。处理方式：确认脚本是否已完整跑过，如果是重复执行，用 drop 脚本清理后重来。

ORA-01950：表空间中无权限，基本是 QUOTA 没授权，检查用户默认表空间和配额就行。

ORA-00942：表或视图不存在，这个稍微隐蔽。除了执行顺序错位，还有可能是大小写问题。Flowable 为了跨数据库行为一致，在 Oracle 里创建的表名是小写形式，如果你手动用大写去查询，很容易出现这个报错。可以试试用双引号包裹不同大小写去验证：

SELECT * FROM "act_ge_property"; SELECT * FROM "ACT_GE_PROPERTY";

两种写法结果不一样，说明库里表的实际大小写和你的查询语句不匹配，用脚本创建出来的那一种就对了。这个细节在项目迁移时坑过不少人。

5. 从 ACT_ 前缀一眼看懂 Flowable 六大核心表模块

5.1 前缀与业务模块对照表

Flowable 的数据库设计很有规律，表名按前缀划分职责。看完这张表，你基本能从报错里猜出问题出在哪个环节：

实际项目里，流程发起后数据通常在 ACT_RU_ 系列表里流转，流程结束再转移到 ACT_HI_ 系列，ACT_RE_ 系列保存审批流定义本身，ACT_ID_ 只有用了 Flowable 内置身份模块才会被频繁读写。理解这套映射，至少能让你在看到 "ACT_RU_TASK 里没数据" 这种问题时，知道该往哪个方向排查。

5.2 初始化后第一时间要查的几张表

脚本执行完，不要急着启动应用，先验证几张

本文还有配套的精品资源，点击获取