Flowable工作流引擎如何适配国产数据库？以达梦数据库举例说明

Flowable 连接达梦数据库并不难，难的是把“JDBC 能连通”变成“流程引擎可稳定运行、可升级、可运维”。截至 2026 年 8 月，Flowable 8.0.0 的开源文档和源码没有把达梦列为原生数据库类型，也没有随包提供 flowable.dm.*.sql、dm.properties 和达梦专用 MyBatis 映射。因此，直接更换 JDBC 驱动并不能宣称已经完成国产数据库适配。

企业通常有两条路线：利用达梦的 Oracle 兼容能力复用 Flowable Oracle 方言，快速建立可用基线；或者增加独立的 DM 数据库类型、建表升级脚本和差异 SQL，形成可长期维护的原生适配。前者改造量较小，但必须逐项验证兼容边界；后者控制力更强，却要持续跟随 Flowable 版本维护。

从私有化部署角度，推荐把适配拆成驱动、识别、方言、DDL、数据类型和验证六层，并在生产关闭自动建表，由 DBA 审核后执行版本化脚本。本文以达梦为例，也适用于人大金仓、openGauss 等国产数据库的适配评估。

一、核心结论与问题边界

先给答案：支持国产数据库需要补齐六层能力

第一层是 JDBC 驱动与连接池，解决连接、事务和故障切换；第二层是数据库类型识别，让引擎知道该加载哪套资源；第三层是 SQL 方言，处理分页、批量插入、函数和锁；第四层是 DDL 与升级脚本；第五层是类型、大小写和模式语义；第六层是自动化回归、性能与高可用验证。

只完成前两层，应用可能启动；没有后四层，问题往往在会签、定时任务、历史清理、版本升级或大数据量分页时才暴露。真正的“支持”必须覆盖完整流程生命周期，而不是只跑通一个请假 Demo。

Flowable 8.0.0 对达梦的官方支持边界

Flowable 官方开源文档列出的数据库类型包括 H2、MySQL、Oracle、PostgreSQL、DB2 和 Microsoft SQL Server。Flowable 8.0.0 源码还包含 HSQL、MariaDB 映射和 CockroachDB 处理，但默认数据库产品名映射中没有达梦。

官方源码在启动时通过 JDBC DatabaseMetaData.getDatabaseProductName() 获取产品名，再从默认映射表中推导内部数据库类型。无法匹配时会抛出“不能从数据库产品名推导数据库类型”的异常。即使手工设置数据库类型，引擎还会按照该类型加载分页属性、MyBatis databaseId 和建表升级脚本。

能力	Flowable 8.0.0 对达梦的现状	企业要补什么
JDBC 连接	达梦提供标准 JDBC 驱动	引入匹配 JDK 和数据库版本的驱动
产品名识别	默认映射没有 DM	显式选择兼容方言或扩展 DM 类型
SQL 方言	没有 dm.properties	分页、布尔值、函数和批处理规则
DDL/升级	没有 flowable.dm.*.sql	全模块建表、升级和回滚脚本
官方测试	不在开源文档支持列表	企业自行建立认证矩阵和版本基线

这里的边界很重要：使用开源 Flowable 适配达梦是可行的工程工作，但不能把它描述为 Flowable 官方开箱即用支持。项目方需要承担验证、缺陷修复和升级维护责任。

为什么只换达梦 JDBC 驱动还不够

达梦官方 JDBC 文档给出的驱动类是 dm.jdbc.driver.DmDriver，连接地址以 jdbc:dm:// 开头。驱动解决的是 Java 与数据库之间的协议和 JDBC 接口，不会自动改写 Flowable 的分页语句、建表字段类型或数据库专用 SQL。

Flowable 的数据库差异分布在多个位置：数据库产品名映射决定内部类型；org/flowable/common/db/properties/{type}.properties 提供分页、BLOB 和布尔值属性；MyBatis XML 使用 databaseId 选择专用语句；Schema Manager 根据类型定位 create、drop 和 upgrade 脚本；部分 Java 分支还直接判断 Oracle、MSSQL、DB2 等类型。

所以，驱动成功、连接池健康、select 1 正常，只能证明网络和账号可用，不能证明流程引擎兼容。

二、关键概念与能力差异

两条落地路线应该怎么选

兼容路线把达梦运行在 Oracle 兼容模式，并让 Flowable 使用 oracle 数据库类型。它可以复用 Oracle 分页、函数、布尔值约定和大部分 MyBatis 专用语句，适合交付周期紧、流程模块相对收敛、数据库参数可由项目控制的场景。

原生路线把达梦定义为独立的 dm 类型，提供 dm.properties、DM 版 DDL/升级脚本、MyBatis 差异语句及必要的引擎扩展。它适合多项目复用、长期国产化产品、不能依赖 Oracle 兼容模式或需要明确自主兼容边界的场景。

维度	Oracle 兼容路线	独立 DM 方言路线
首次改造成本	较低	较高
上线速度	较快	较慢
对达梦参数依赖	高	可逐步降低
差异可见性	容易被兼容模式掩盖	差异显式、便于测试
Flowable 升级维护	仍需回归 Oracle 路径	需持续合并和维护适配层
推荐场景	单项目、时间优先	平台产品、长期维护优先

兼容模式不是“不需要测试”。达梦官方文档明确指出 COMPATIBLE_MODE=2 是 Oracle 兼容设置，修改会影响数据存储和操作结果，并且需要重启生效。空字符串与 NULL 等语义变化，可能直接影响流程变量、查询条件和业务数据判断。

第一步：建立受控的达梦数据源

达梦 JDBC 驱动应作为私有化交付基线的一部分统一管理，驱动版本要与 JDK、DM 服务端版本和 CPU 架构匹配。不要让每个项目临时拷贝一个来源不明的驱动包。达梦官方 Java 文档说明，驱动可以从数据库安装目录获取，也可以通过 Maven 坐标引入。

Spring Boot 的基础配置可以保持简单，生产密码应由密钥系统或配置中心提供：

spring:
  datasource:
    driver-class-name: dm.jdbc.driver.DmDriver
    url: jdbc:dm://10.0.0.20:5236
    username: FLOWABLE
    password: ${DM_PASSWORD}

flowable:
  database-schema-update: false

连接池需要验证连接有效性、借还连接、事务隔离、自动提交、网络超时和主备切换。达梦 JDBC 支持 DataSource 方式；企业应用应优先由连接池管理连接，而不是在业务代码中直接使用 DriverManager。

当前云程低代码项目已经把达梦驱动纳入统一依赖管理，并预留 jdbc:dm:// 与 DmDriver 数据源配置。这类能力解决了平台级连接入口，但流程引擎仍需单独完成方言、DDL 和回归认证。

三、模型架构与运行机制

第二步：解决数据库类型识别

如果不做处理，Flowable 会根据 JDBC 返回的产品名查找数据库类型；Flowable 8.0.0 默认映射表没有 DM，因此可能在引擎初始化阶段失败。

兼容路线可以在 Spring Boot 的 Flowable 引擎配置器中显式选择 Oracle 类型：

@Bean
EngineConfigurationConfigurer<SpringProcessEngineConfiguration> dmConfigurer() {
    return configuration -> configuration.setDatabaseType("oracle");
}

这段配置的含义是“让 Flowable 加载 Oracle 资源”，不是把达梦伪装成已经获得官方认证。使用它之前，应先完成达梦 Oracle 兼容参数、转换后 DDL 和回归测试。

独立方言路线则要把 JDBC 产品名映射为 dm，并保证引擎所有模块都能找到对应资源。仅增加一个常量还不够，因为分页属性、MyBatis 映射、Schema Manager 和某些数据库条件分支都依赖这个内部类型。

第三步：准备完整的 DM 建表和升级脚本

Flowable 8.0.0 不只有 BPMN 两张脚本。按照启用模块，至少要检查 common、BPMN engine、history、CMMN、DMN、IDM、Event Registry 和 App 等脚本。只转换 ACT_RU_* 表，启动时仍可能在任务、变量、作业、身份或事件模块报错。

生产环境不建议让 database-schema-update=true 自动改库。更稳妥的做法是：从目标 Flowable 版本的官方 Oracle 或 PostgreSQL 脚本建立转换基线；由开发与 DBA 联合审查；在干净库和升级库分别执行；最后把脚本放入企业自己的版本迁移体系，并将 Flowable 自动更新关闭。

脚本转换应重点核对：字符类型和最大长度、CLOB/BLOB、时间精度、布尔值、默认值、唯一约束、索引、外键、标识符长度、保留字、表空间和模式。不能只追求“DDL 执行成功”，还要检查引擎预期的数据语义。

四、核心场景与处理策略

第四步：分页、函数和批量 SQL 必须逐项验证

Flowable 的列表查询、任务查询、历史查询和清理任务高度依赖分页。Oracle 属性文件使用基于 ROWNUM 的双层分页结构，PostgreSQL 使用 LIMIT/OFFSET。达梦采用哪一种实现，取决于数据库版本、兼容模式和企业选择的适配路线，不能靠 JDBC 驱动自动决定。

还要验证 NVL、COALESCE、位运算、日期计算、字符串连接、FROM DUAL、布尔常量、FOR UPDATE、批量插入以及 IN 参数数量。Flowable 的 MyBatis 映射中存在 Oracle 专用批量插入和数据库专用查询，简单接口跑通并不能覆盖这些分支。

适配层应尽量集中：分页和通用属性放在数据库属性文件；少量 SQL 差异放在带 databaseId="dm" 的 MyBatis 映射；数据库建表与升级放在独立脚本；只有无法通过资源覆盖的条件分支才修改引擎代码。这样升级时可以清楚看到维护面。

第五步：处理大小写、模式与表前缀

达梦中的用户、模式、标识符大小写和引号策略会影响 Flowable 查表、自动校验和 MyBatis 返回列名。最常见的问题是 DDL 创建了大写对象，而应用按带引号的小写名称访问，或者运行账号默认模式不是建表模式。

建议在项目开始时固定三条规则：流程表由独立用户和独立模式管理；表名和列名不使用双引号制造大小写敏感对象；应用连接后的当前模式必须可预测。确需共享数据库时，可以评估 databaseSchema 和表前缀，但要验证 JDBC setSchema、元数据查询和所有模块的表发现逻辑。

业务 SQL 还要注意 Map 返回键的大小写。当前低代码平台在达梦适配中已经对结果集字段名大小写做了统一处理，这说明数据库兼容不只发生在流程引擎内部；表单、数据集、报表和权限 SQL 也要采用同一套标识符规范。

五、数据、规则与状态设计

第六步：数据类型不能只做名称替换

流程变量和历史数据会使用字符串、数值、时间、JSON 字符串以及字节数组。适配时至少测试普通字符串、中文、空字符串、超长字符串、序列化对象、BLOB/CLOB、毫秒时间、布尔值和 NULL。

达梦 Oracle 兼容模式会改变空字符串与 NULL 的行为。Flowable 自身很多查询使用非空判断，业务表单也可能把空串当成有效值，因此必须用真实业务样本测试，而不是假设 Oracle 兼容模式对所有场景都是透明的。

大变量和附件应重点测试写入、读取、删除和历史清理。驱动返回的 JDBC 类型如果与 MyBatis TypeHandler 预期不同，可能出现启动正常、读取变量时才报类型转换异常的情况。

运行时事务和锁是流程引擎的核心兼容点

工作流引擎依靠数据库事务和乐观锁保证流程令牌、任务和作业的一致性。需要验证同一任务并发提交时只能成功一次，作业获取不会被多个节点重复执行，失败事务能够完整回滚，死锁和锁超时能够被正确识别和重试。

多节点部署时，还要压测定时器、异步作业、批处理和历史清理的竞争。数据库主备切换后，连接池应淘汰失效连接；正在执行的事务可能回滚，但任务不能被静默丢失。把一次 HTTP 请求返回 200 当成高可用验证远远不够。

事务隔离级别、锁等待时间和连接超时应由 Flowable、Spring 事务、连接池与达梦数据库共同定义，不能由各自默认值偶然拼接。

六、工程实现与系统集成

从 MySQL 或 Oracle 迁移到达梦怎么做

第一步冻结版本，明确 Flowable 版本、启用模块、扩展表和目标 DM 参数；第二步用转换后的脚本创建目标结构；第三步迁移全量流程表和业务关联数据；第四步在停写窗口完成增量追平；第五步执行一致性校验；第六步切换应用并保留可回退时间窗。

迁移运行中流程时，必须在一致性时间点停止流程写入和异步执行器，否则运行表、任务表、变量表和作业表可能来自不同事务快照。不要只迁移历史表，也不要在目标库先启动一个空 Flowable 再覆盖部分数据。

校验至少包括：各表记录数与摘要、流程实例与业务单据关联、运行任务与执行树、变量和字节数组、定时作业与重试次数、流程定义资源、历史轨迹以及引擎版本属性。切换后先恢复只读查询，再逐步开放启动、审批和异步作业。

必须建立一套可重复执行的认证矩阵

测试域	必测场景	关键判定
启动与结构	空库建表、已有库校验、跨版本升级	无缺表、无错误自动升级
流程执行	串行、网关、子流程、会签、边界事件	路径和执行树正确
人工任务	认领、完成、转办、委托、加签、驳回	任务关系和历史一致
变量与附件	中文、空串、大文本、BLOB、JSON	类型、长度和清理正确
作业	定时器、异步任务、失败重试、多节点竞争	不丢失、不重复、可恢复
查询	待办、已办、历史、深分页、原生查询	语义正确且执行计划可控
并发	重复提交、乐观锁、死锁、批量处理	一致性和重试符合预期
运维	备份恢复、主备切换、扩容、历史清理	RPO/RTO 和审计满足要求

这套矩阵应进入 CI 或发布认证环境。每次升级 Flowable、DM 服务端、JDBC 驱动、JDK 或 Spring Boot，都要重新跑关键用例，而不是沿用第一次适配结论。

七、安全、性能与治理要求

性能优化要以达梦执行计划为准

从 Oracle 迁移来的索引不一定在达梦上得到相同执行计划。流程任务查询通常包含候选人、租户、流程定义、状态和时间排序；历史查询则容易跨大表分页。索引应根据真实 SQL、数据分布和达梦执行计划设计。

压测至少覆盖流程启动、任务完成、会签创建、作业获取、历史分页和历史清理。观察吞吐量、P95/P99、锁等待、日志写入、Buffer 命中、连接池等待和主备复制延迟。批量插入数量、作业获取批次和历史清理批次都可能需要针对达梦调优。

不要以单用户功能测试代替容量结论，也不要把某条 SQL 在 Oracle 上的经验参数原样复制到达梦。

生产环境如何管理 DDL 和升级

建议将适配包与 Flowable 版本绑定，例如“Flowable 8.0.0 + DM8 指定版本 + 指定 JDBC + 指定 JDK”。适配包应包含建表脚本、每个版本的增量脚本、回滚或恢复说明、差异 SQL、测试报告和已知限制。

生产运行账号只保留必要的 DML 权限，DDL 由独立发布账号执行。升级时先备份和演练，再执行脚本、校验引擎属性、启动单节点验证，最后逐步恢复集群。不要依赖应用启动时临时修改数据库结构。

如果采用原生 dm 方言，应把适配层做成独立模块或维护清晰补丁集，并持续与 Flowable 上游比较。若条件允许，最好把通用改造贡献给社区；否则每次升级都可能重新踩一遍数据库识别、DDL 和 MyBatis 差异。

八、平台落地、测试与选型

国产数据库适配应该成为平台能力

低代码和 OA 平台不应让每个业务项目重复修改流程引擎。平台层应提供数据库适配 SPI、受控驱动仓库、脚本包、版本兼容矩阵、自动化认证环境和运行监控。流程、表单、数据集、报表与权限引擎还要共享标识符、时间和空值规范。

对外交付时，应明确标注“官方原生支持”“兼容模式认证”“平台自研适配”三种等级，并给出经过验证的版本组合。这样，客户知道问题由谁负责，升级边界也不会模糊。

常见问题

1. 达梦兼容 Oracle，是否直接把 databaseType 设置成 oracle 就行

不能把“可以尝试”理解为“无需验证”。还要转换和审查 DDL，验证分页、批量插入、锁、类型、空字符串、历史清理和升级脚本，并固定兼容参数和版本组合。

2. database-schema-update 是否应该设置为 true

开发环境可以用于快速验证，生产环境不建议。Flowable 没有随包提供 DM 脚本，自动建表或升级的失败边界难以控制。生产应执行审核后的版本化脚本，并设置为 false。

3. 是否需要修改 Flowable 源码

兼容路线可能通过显式选择 Oracle 类型、转换脚本和少量扩展完成；原生 DM 类型通常需要增加资源并处理源码中的数据库条件分支。是否修改核心代码取决于实际差异，但应优先把改动集中在可替换的适配层。

4. 跑通请假流程是否代表适配完成

不代表。请假流程通常没有覆盖并发、作业、批处理、大变量、历史清理、升级和主备切换。至少要通过本文的认证矩阵。

九、结论

Flowable 支持达梦的正确做法，是先承认官方边界，再选择兼容路线或原生方言路线。JDBC 负责连接，数据库类型负责选择资源，属性和 MyBatis 负责 SQL 方言，DDL 负责结构与升级，类型规范负责数据语义，认证矩阵负责证明结果。

如果企业只是单项目快速交付，可以从达梦 Oracle 兼容模式建立基线，但必须用审核后的脚本和完整回归兜底；如果要建设长期低代码或 OA 产品，应投资独立适配层、自动化测试和版本认证。最终衡量标准不是“应用能启动”，而是流程能正确执行、数据可升级、故障可恢复、性能可证明。