1. 项目概述与核心挑战最近在负责一个老项目的技术栈升级核心任务是把工作流引擎从Flowable的一个旧版本升级到最新的7.x系列同时数据库要从原来的MySQL迁移到达梦数据库。这活儿听起来像是两个独立任务但实际干起来你会发现它们环环相扣任何一个环节的疏忽都可能导致流程引擎“罢工”。Flowable作为一款主流的开源BPMN 2.0流程引擎其7.x版本在性能、API设计和对云原生环境的支持上都有显著提升但官方对国产数据库的“开箱即用”支持度并不高。而达梦数据库作为信创环境下的重要选择其与Oracle的高度兼容性是一把双刃剑既降低了SQL语法迁移的成本又在一些细节实现上埋了坑。这次升级适配远不止是改个数据库连接串和驱动那么简单。它涉及到Flowable引擎底层SQL脚本的兼容性改写、Spring Boot集成配置的深度调整、以及因数据库特性差异引发的各种运行时异常处理。整个过程更像是一次对Flowable内核和达梦数据库特性的深度探秘。如果你也正面临类似的技术改造或者对Flowable与国产数据库的整合感兴趣我把自己趟过的路、踩过的坑以及最终的解决方案梳理出来希望能帮你省下大量排查时间。2. 升级适配的整体设计与思路拆解2.1 为什么是Flowable 7.x 达梦这次技术选型的背后有明确的驱动因素。原系统使用的Flowable 6.x版本虽然稳定但已停止主流维护一些新的特性和性能优化无法享受。Flowable 7.x带来了异步历史日志处理、增强的REST API、以及对Spring Boot 2.7和Java 17更好的支持这对于提升系统处理高并发流程的能力和拥抱现代技术栈至关重要。另一方面数据库国产化替代是不可逆的趋势。达梦数据库DM8因其与Oracle语法的高度兼容、良好的事务支持和完善的生态工具成为许多项目的首选。然而Flowable官方发布的数据库脚本主要面向MySQL、PostgreSQL、Oracle等没有提供直接的达梦版本。这就意味着我们需要扮演一次“数据库方言”的翻译官将Flowable的建表逻辑和运行时SQL准确地“翻译”成达梦能理解并高效执行的语言。2.2 核心思路分而治之逐步验证面对这个复合型任务最忌讳的就是“一把梭”。我的核心思路是“分而治之逐步验证”将大问题拆解成可独立推进和测试的小步骤环境隔离首先在本地或开发环境搭建纯净的达梦数据库实例与现有生产环境完全隔离。这是所有测试和调试的安全沙箱。驱动与连接解决最基础的问题——让Spring Boot应用能够连接到达梦数据库。这涉及到正确的JDBC驱动引入和连接池配置。脚本适配与初始化这是最核心、最繁琐的一步。需要逐表、逐句地分析并修改Flowable的官方SQL脚本使其符合达梦的DDL语法和约束。运行时适配即使表建成功了引擎在运行时的动态SQL也可能因为函数、分页查询等差异而报错。需要准备应对这些运行时兼容性问题。功能回归测试在适配后的环境上对流程的定义、部署、启动、任务处理、历史查询等核心功能进行完整测试。这个顺序不能乱。如果连表都创建失败谈何运行时测试如果基本的JDBC连接都通不了后续所有工作都是空中楼阁。3. 核心细节解析与实操要点3.1 达梦JDBC驱动的选择与配置陷阱第一步是引入正确的驱动。达梦提供了DmJdbcDriver18对应JDK 1.8你可以在Maven仓库或达梦安装目录的/drivers/jdbc下找到它。依赖引入dependency groupIdcom.dameng/groupId artifactIdDmJdbcDriver18/artifactId version8.1.3.62/version !-- 请务必使用与你达梦数据库服务器匹配的版本 -- /dependency配置要点与坑在application.yml中配置数据源时有几个关键点极易出错spring: datasource: url: jdbc:dm://localhost:5236/FLOWABLE_DB?schemaFLOWABLEzeroDateTimeBehaviorconvertToNullnullCatalogMeansCurrenttrue username: FLOWABLE_USER password: your_strong_password driver-class-name: dm.jdbc.driver.DmDriver hikari: connection-test-query: SELECT 1 FROM DUAL # 达梦的健康检查SQL注意schema参数达梦的模式Schema概念类似于Oracle的用户。schemaFLOWABLE表示连接后默认使用FLOWABLE模式。你需要在达梦数据库中先创建好这个用户/模式并授予相应权限。连接参数zeroDateTimeBehaviorconvertToNull是为了处理MySQL特有但Flowable脚本中可能遗留的0000-00-00日期问题达梦对此很严格。nullCatalogMeansCurrenttrue有助于解决一些元数据查询的问题。驱动类名是dm.jdbc.driver.DmDriver不是常见的com.mysql.cj.jdbc.Driver写错会直接导致ClassNotFoundException。健康检查SQLHikariCP等连接池需要配置connection-test-query达梦中简单的SELECT 1或SELECT 1 FROM DUAL即可。不配置可能导致连接池认为连接失效而不断创建新连接。3.2 Flowable SQL脚本的深度适配改造Flowable引擎启动时会根据配置决定是否自动执行数据库初始化脚本flowable.*.create.*.sql。我们的主战场就在这里。官方脚本位于Flowable引擎jar包的org/flowable/db/create目录下。我们需要针对达梦创建一套自己的脚本。核心改造原则关键字和数据类型映射AUTO_INCREMENT-IDENTITY(1,1)。这是自增主键的写法差异必须改。DATETIME-TIMESTAMP。达梦更推荐使用TIMESTAMP来存储日期时间。TINYINT-NUMBER(3)或INTEGER。达梦没有TINYINT根据实际存储的数值范围选择。ENGINEInnoDB- 删除。这是MySQL的表引擎声明达梦不支持直接去掉整行。COMMENT- 达梦的注释语法是COMMENT ON TABLE/COLUMN需要将字段后的COMMENT ‘xxx’拆分成独立的COMMENT ON语句。KEY PRIMARY (ID)-PRIMARY KEY (ID)。达梦对主键的声明语法更标准。索引和约束语法达梦创建索引时不能在同一句CREATE TABLE语句中通过KEY关键字定义普通索引必须使用单独的CREATE INDEX语句。外键约束的语法基本兼容但要注意命名不要超长不超过128字节。长文本字段处理 Flowable的ACT_GE_BYTEARRAY资源表和ACT_HI_COMMENT评论表等表有LONGBLOB或LONGTEXT字段。达梦对应的类型是CLOB长文本和BLOB二进制长文本。直接映射即可但要注意在插入和查询时可能需要使用达梦特定的函数如DBMS_LOB包来处理超大对象不过JDBC驱动通常会封装好。实操示例改造ACT_RE_PROCDEF流程定义表假设原始MySQL脚本片段如下CREATE TABLE ACT_RE_PROCDEF ( ID_ varchar(64) NOT NULL, REV_ integer, CATEGORY_ varchar(255), NAME_ varchar(255), KEY_ varchar(255) NOT NULL, VERSION_ integer NOT NULL, DEPLOYMENT_ID_ varchar(64), RESOURCE_NAME_ varchar(4000), DGRM_RESOURCE_NAME_ varchar(4000), DESCRIPTION_ varchar(4000), HAS_START_FORM_KEY_ tinyint, HAS_GRAPHICAL_NOTATION_ tinyint, SUSPENSION_STATE_ integer, TENANT_ID_ varchar(255) default , ENGINE_VERSION_ varchar(255), DERIVED_FROM_ varchar(64), DERIVED_FROM_ROOT_ varchar(64), DERIVED_VERSION_ integer DEFAULT 0 NOT NULL, PRIMARY KEY (ID_), UNIQUE KEY ACT_UNIQ_PROCDEF_KEY_TENANT (KEY_,VERSION_, TENANT_ID_) ) ENGINEInnoDB DEFAULT CHARSETutf8 COLLATE utf8_bin;适配后的达梦脚本应为CREATE TABLE ACT_RE_PROCDEF ( ID_ VARCHAR(64) NOT NULL, REV_ INTEGER, CATEGORY_ VARCHAR(255), NAME_ VARCHAR(255), KEY_ VARCHAR(255) NOT NULL, VERSION_ INTEGER NOT NULL, DEPLOYMENT_ID_ VARCHAR(64), RESOURCE_NAME_ VARCHAR(4000), DGRM_RESOURCE_NAME_ VARCHAR(4000), DESCRIPTION_ VARCHAR(4000), HAS_START_FORM_KEY_ INTEGER, -- 达梦无TINYINT用INTEGER替代 HAS_GRAPHICAL_NOTATION_ INTEGER, SUSPENSION_STATE_ INTEGER, TENANT_ID_ VARCHAR(255) DEFAULT , ENGINE_VERSION_ VARCHAR(255), DERIVED_FROM_ VARCHAR(64), DERIVED_FROM_ROOT_ VARCHAR(64), DERIVED_VERSION_ INTEGER DEFAULT 0 NOT NULL, PRIMARY KEY (ID_) ); CREATE UNIQUE INDEX ACT_UNIQ_PROCDEF_KEY_TENANT ON ACT_RE_PROCDEF(KEY_, VERSION_, TENANT_ID_); COMMENT ON TABLE ACT_RE_PROCDEF IS ‘流程定义数据表’; COMMENT ON COLUMN ACT_RE_PROCDEF.ID_ IS ‘主键’; -- ... 其他字段注释心得不要试图手动修改所有脚本工作量巨大且易错。我的做法是先使用达梦的“迁移工具”或一些SQL转换器进行初步转换然后以转换后的脚本为基础进行精细化的校对和修正重点就是上面提到的几个原则点。可以编写一个简单的脚本或使用IDE的批量替换功能来辅助。3.3 Spring Boot配置的针对性调整在application.yml中除了数据源还需要对Flowable的配置进行针对性设置flowable: async-executor-activate: true # 启用异步执行器7.x推荐 database-schema-update: true # 首次启动设为true自动执行建表脚本 db-history-used: true # 使用历史数据 history-level: audit # 历史级别通常用audit或full database-type: oracle # 关键告诉Flowable使用Oracle方言最重要的配置是database-type: oracle。因为达梦的SQL方言与Oracle高度兼容将Flowable的数据库类型设置为oracle引擎在生成分页查询、时间函数等动态SQL时就会采用Oracle的语法规则这能解决绝大部分运行时SQL兼容性问题。当然这要求你的达梦数据库实例配置的兼容模式支持Oracle语法。4. 实操过程与核心环节实现4.1 准备适配后的SQL脚本库获取官方脚本从Flowable 7.x的发行包如flowable-engine-7.0.0.jar中解压出org/flowable/db/create目录下的所有flowable.*.create.engine.sql脚本。批量转换与校对按照第3.2节的原则对所有脚本进行转换。建议按模块engine, history, identity等分开处理便于管理。组织资源在Spring Boot项目的src/main/resources目录下创建如/sql/dameng的文件夹将修改好的脚本按原命名规则放入。例如flowable.dm.create.engine.sql。4.2 配置Spring Boot工程以使用自定义脚本我们需要自定义Flowable的自动配置告诉它使用我们准备好的达梦脚本而不是jar包里的默认脚本。方案一通过application.yml指定简单但可能不彻底flowable: database-schema-update: true database-schema: classpath:/sql/dameng/ # 指定自定义脚本路径这种方式理论上可行但需要确保你的脚本命名完全符合Flowable内部约定的格式如flowable.{db-type}.create.{component}.sql并且要覆盖所有组件engine, history, identity, form...实操中可能遇到路径解析问题。方案二自定义ProcessEngineConfigurationConfigurer推荐更可控这是一个更强大和灵活的方式。创建一个配置类Configuration public class FlowableDamengConfig { Bean public ProcessEngineConfigurationConfigurer processEngineConfigurationConfigurer() { return configuration - { // 1. 设置数据库类型为Oracle configuration.setDatabaseType(oracle); // 2. 禁用默认的自动创建脚本逻辑 configuration.setDatabaseSchemaUpdate(ProcessEngineConfiguration.DB_SCHEMA_UPDATE_FALSE); // 3. 手动设置自定义的建表SQL资源路径 // 这里需要根据Flowable内部类名来定位资源比较hack但一劳永逸 // 更稳健的做法是在应用启动后手动执行我们准备好的SQL文件 }; } // 推荐做法使用DataSourceInitializer在Spring启动后执行SQL Bean public DataSourceInitializer dataSourceInitializer(DataSource dataSource) { ResourceDatabasePopulator populator new ResourceDatabasePopulator(); populator.addScript(new ClassPathResource(/sql/dameng/flowable.dm.create.engine.sql)); populator.addScript(new ClassPathResource(/sql/dameng/flowable.dm.create.history.sql)); populator.addScript(new ClassPathResource(/sql/dameng/flowable.dm.create.identity.sql)); // ... 添加所有必要的脚本 populator.setSeparator(;); // 达梦SQL分隔符 populator.setIgnoreFailedDrops(true); DataSourceInitializer initializer new DataSourceInitializer(); initializer.setDataSource(dataSource); initializer.setDatabasePopulator(populator); // 设置只在没有表的时候初始化根据某个核心表是否存在判断 initializer.setEnabled(isDatabaseEmpty(dataSource)); return initializer; } private boolean isDatabaseEmpty(DataSource dataSource) { // 实现一个检查例如查询ACT_GE_PROPERTY表是否存在 // 如果不存在返回true触发初始化 try (Connection conn dataSource.getConnection(); ResultSet rs conn.getMetaData().getTables(null, “FLOWABLE”, “ACT_GE_PROPERTY”, null)) { return !rs.next(); } catch (SQLException e) { // 日志记录 return true; // 出错时也尝试初始化 } } }通过DataSourceInitializer我们完全掌控了数据库初始化的时机和执行的SQL内容避免了Flowable自动机制可能带来的不确定性。4.3 启动应用与初始化验证配置好上述所有内容后启动Spring Boot应用。观察启动日志重点关注DataSourceInitializer是否执行了我们的SQL脚本以及Flowable引擎是否成功初始化。连接到达梦数据库使用管理工具如达梦管理工具或DBeaver查看FLOWABLE模式下是否成功创建了所有ACT_开头的表。通过Flowable提供的REST API或集成到应用中的API尝试部署一个最简单的BPMN 2.0流程文件例如一个只有开始和结束节点的流程。如果部署成功并在ACT_RE_PROCDEF和ACT_RE_DEPLOYMENT表中看到记录说明表结构和基础运行环境基本正常。5. 常见问题与排查技巧实录在实际操作中你几乎一定会遇到下面这些问题。这里我把它们和解决方案记录下来。5.1 表创建失败语法错误问题现象启动应用时日志报错提示SQL语法错误通常在创建某张表或索引时失败。排查思路定位错误SQL仔细查看日志堆栈找到达梦数据库返回的具体错误信息和导致错误的SQL片段。核对脚本在自定义的SQL脚本中找到对应的建表语句。对照原则检查检查是否还有未转换的MySQL特有语法如AUTO_INCREMENT,ENGINE,TINYINT, 内联的KEY索引定义等。达梦关键字冲突有些列名可能是达梦的保留字如KEY,COMMENT。虽然Flowable的表字段名后都有下划线如KEY_一般不会冲突但仍需注意。如果冲突需要对字段名加双引号如“KEY_”但这会非常麻烦尽量避免。技巧在达梦数据库上开启SQL日志或使用跟踪功能可以捕获到应用执行的所有SQL语句对于调试动态SQL问题至关重要。可以在达梦的dm.ini配置文件中设置SVR_LOG1并指定SVR_LOG_FILE_PATH。5.2 流程启动或任务查询失败分页查询错误问题现象部署流程正常但启动流程实例或查询任务列表时报错提示SQL异常错误信息可能包含ROWNUM、RN__或子查询嵌套问题。原因分析这是最典型的“方言”问题。即使设置了database-typeoracleFlowable内部某些复杂查询尤其是嵌套查询生成的分页SQL可能在达梦上执行仍有细微差别。达梦对Oracle的ROWNUM分页模拟并非100%完美。解决方案确认方言设置首先确保flowable.database-typeoracle已生效。自定义分页处理器如果问题依旧可能需要实现一个自定义的AbstractPagingProvider。但这属于深度定制需要对Flowable源码有较深理解。更实用的变通方案在实际项目中如果遇到特定分页查询出错可以暂时考虑关闭Flowable的历史查询分页功能如果业务允许或者通过覆盖Flowable的默认服务实现将出错的查询方法替换为手写兼容达梦的SQL。例如自定义一个MyTaskQueryImpl继承自TaskQueryImpl重写其executeList方法。5.3 历史数据查询异常时间函数不兼容问题现象查询历史流程实例或任务时涉及时间范围过滤的条件失效或报错。原因分析Flowable在生成查询条件时可能会使用数据库特定的时间函数如DATE_ADD(MySQL) 或ADD_MONTHS(Oracle)。当方言设置为oracle时它会使用Oracle的函数但达梦对某些函数的支持或参数顺序可能有差异。排查与解决通过日志或数据库跟踪抓取到出错的SQL。分析其中的时间函数。例如发现是TRUNC函数处理方式不同。解决方案有两种方案A推荐在业务层避免使用过于复杂的时间过滤条件或者将计算转移到Java代码中将计算好的时间点作为参数传入查询。方案B侵入性强自定义Flowable的VariableType或历史管理器HistoryManager重写涉及时间处理的SQL生成逻辑。这需要深入Flowable内部机制。5.4 连接池与长事务问题问题现象系统运行一段时间后出现连接池耗尽、数据库锁超时或死锁。原因分析Flowable处理长流程如包含用户任务时一个流程实例可能会跨越多个数据库事务。达梦数据库的默认隔离级别和锁机制可能与MySQL有差异。同时连接池配置不当如max-lifetime太短也可能导致正在执行长事务的连接被回收从而引发错误。优化建议调整达梦参数咨询DBA适当调整达梦数据库的UNDO_RETENTION等参数以更好地支持长事务。优化连接池配置适当增加HikariCP的maximum-pool-size并确保connection-timeout和max-lifetime设置合理避免在事务中途断开连接。可以将max-lifetime设置为略大于你预估的最长流程执行时间。审视流程设计检查是否有流程节点长时间等待如“挂起”状态而不释放数据库连接。考虑使用Flowable的异步执行器async-executor-activate: true来分离流程执行与核心事务。5.5 数据迁移的挑战如果你是从旧的Flowable MySQL环境迁移到达梦还需要进行数据迁移。这不是简单的mysqldump和dmimp就能解决的。迁移步骤建议结构迁移使用我们适配好的达梦建表脚本在新环境创建空表。数据迁移基础数据对于ACT_GE_*通用数据、ACT_RE_*静态部署数据等表可以使用数据库工具尝试直接导入导出注意字段类型的映射尤其是时间、大文本字段。运行时和历史数据ACT_RU_*运行时数据和ACT_HI_*历史数据表数据量可能巨大且包含外键约束。建议编写专门的迁移脚本利用Flowable的API如HistoryService进行数据读取和重放虽然慢但能保证数据一致性和引擎状态的正确性。切忌直接操作数据库表否则极易破坏引擎内部状态。严格验证迁移后必须对关键流程实例、任务、历史记录进行端到端的业务验证。6. 性能调优与监控考量完成基础适配后在准生产环境进行压力测试时可能会发现性能瓶颈。以下是一些针对Flowable on Dameng的调优方向达梦数据库层面表空间与存储为Flowable的表创建独立的表空间并放置在高速存储上。合理设置初始扩展大小避免频繁扩展。索引优化Flowable的表通常已有较多索引。使用达梦的性能监控工具如DM Performance Monitor分析慢SQL检查是否有缺失的索引。特别注意流程实例IDPROC_INST_ID_、执行流IDEXECUTION_ID_、任务IDTASK_ID_等高频查询字段的索引效率。内存参数调整达梦的BUFFER、MEMORY_POOL等内存参数确保有足够的内存缓存流程相关的数据。Flowable配置层面异步执行器务必启用并合理配置AsyncExecutor。将耗时的作业如历史数据清理、定时器触发交给异步线程池避免阻塞核心流程线程。调整core-pool-size和max-pool-size以适应你的并发量。批量处理Flowable 7.x增强了批量操作。确保在插入或更新大量历史数据时相关配置如flowable.history.batch-size已优化。缓存配置Flowable内置了流程定义等缓存。在流程定义不常变更的生产环境可以适当增加缓存大小如flowable.process-definition-cache-limit减少数据库访问。应用监控集成Micrometer等指标库将Flowable的指标如活动流程实例数、已完成任务数、作业队列长度暴露给Prometheus和Grafana。监控达梦数据库的连接数、慢SQL、锁等待情况建立基线以便在出现性能退化时快速定位。整个升级适配过程是对耐心和细心的极大考验。它没有银弹需要你像侦探一样根据错误日志去分析底层SQL再结合达梦和Flowable的知识去解决。成功的关键在于分阶段推进每完成一步都做充分的验证。当你在达梦数据库上成功跑起第一个流程实例时那种成就感会让你觉得所有的折腾都是值得的。最后记住一点在彻底完成所有功能测试和性能验证之前不要轻易对生产环境动刀。 
长河君 · 2026/8/3 2:01:54 · 阅读 1.2k Flowable 7.x工作流引擎适配达梦数据库实战指南
1. 项目概述与核心挑战最近在负责一个老项目的技术栈升级核心任务是把工作流引擎从Flowable的一个旧版本升级到最新的7.x系列同时数据库要从原来的MySQL迁移到达梦数据库。这活儿听起来像是两个独立任务但实际干起来你会发现它们环环相扣任何一个环节的疏忽都可能导致流程引擎“罢工”。Flowable作为一款主流的开源BPMN 2.0流程引擎其7.x版本在性能、API设计和对云原生环境的支持上都有显著提升但官方对国产数据库的“开箱即用”支持度并不高。而达梦数据库作为信创环境下的重要选择其与Oracle的高度兼容性是一把双刃剑既降低了SQL语法迁移的成本又在一些细节实现上埋了坑。这次升级适配远不止是改个数据库连接串和驱动那么简单。它涉及到Flowable引擎底层SQL脚本的兼容性改写、Spring Boot集成配置的深度调整、以及因数据库特性差异引发的各种运行时异常处理。整个过程更像是一次对Flowable内核和达梦数据库特性的深度探秘。如果你也正面临类似的技术改造或者对Flowable与国产数据库的整合感兴趣我把自己趟过的路、踩过的坑以及最终的解决方案梳理出来希望能帮你省下大量排查时间。2. 升级适配的整体设计与思路拆解2.1 为什么是Flowable 7.x 达梦这次技术选型的背后有明确的驱动因素。原系统使用的Flowable 6.x版本虽然稳定但已停止主流维护一些新的特性和性能优化无法享受。Flowable 7.x带来了异步历史日志处理、增强的REST API、以及对Spring Boot 2.7和Java 17更好的支持这对于提升系统处理高并发流程的能力和拥抱现代技术栈至关重要。另一方面数据库国产化替代是不可逆的趋势。达梦数据库DM8因其与Oracle语法的高度兼容、良好的事务支持和完善的生态工具成为许多项目的首选。然而Flowable官方发布的数据库脚本主要面向MySQL、PostgreSQL、Oracle等没有提供直接的达梦版本。这就意味着我们需要扮演一次“数据库方言”的翻译官将Flowable的建表逻辑和运行时SQL准确地“翻译”成达梦能理解并高效执行的语言。2.2 核心思路分而治之逐步验证面对这个复合型任务最忌讳的就是“一把梭”。我的核心思路是“分而治之逐步验证”将大问题拆解成可独立推进和测试的小步骤环境隔离首先在本地或开发环境搭建纯净的达梦数据库实例与现有生产环境完全隔离。这是所有测试和调试的安全沙箱。驱动与连接解决最基础的问题——让Spring Boot应用能够连接到达梦数据库。这涉及到正确的JDBC驱动引入和连接池配置。脚本适配与初始化这是最核心、最繁琐的一步。需要逐表、逐句地分析并修改Flowable的官方SQL脚本使其符合达梦的DDL语法和约束。运行时适配即使表建成功了引擎在运行时的动态SQL也可能因为函数、分页查询等差异而报错。需要准备应对这些运行时兼容性问题。功能回归测试在适配后的环境上对流程的定义、部署、启动、任务处理、历史查询等核心功能进行完整测试。这个顺序不能乱。如果连表都创建失败谈何运行时测试如果基本的JDBC连接都通不了后续所有工作都是空中楼阁。3. 核心细节解析与实操要点3.1 达梦JDBC驱动的选择与配置陷阱第一步是引入正确的驱动。达梦提供了DmJdbcDriver18对应JDK 1.8你可以在Maven仓库或达梦安装目录的/drivers/jdbc下找到它。依赖引入dependency groupIdcom.dameng/groupId artifactIdDmJdbcDriver18/artifactId version8.1.3.62/version !-- 请务必使用与你达梦数据库服务器匹配的版本 -- /dependency配置要点与坑在application.yml中配置数据源时有几个关键点极易出错spring: datasource: url: jdbc:dm://localhost:5236/FLOWABLE_DB?schemaFLOWABLEzeroDateTimeBehaviorconvertToNullnullCatalogMeansCurrenttrue username: FLOWABLE_USER password: your_strong_password driver-class-name: dm.jdbc.driver.DmDriver hikari: connection-test-query: SELECT 1 FROM DUAL # 达梦的健康检查SQL注意schema参数达梦的模式Schema概念类似于Oracle的用户。schemaFLOWABLE表示连接后默认使用FLOWABLE模式。你需要在达梦数据库中先创建好这个用户/模式并授予相应权限。连接参数zeroDateTimeBehaviorconvertToNull是为了处理MySQL特有但Flowable脚本中可能遗留的0000-00-00日期问题达梦对此很严格。nullCatalogMeansCurrenttrue有助于解决一些元数据查询的问题。驱动类名是dm.jdbc.driver.DmDriver不是常见的com.mysql.cj.jdbc.Driver写错会直接导致ClassNotFoundException。健康检查SQLHikariCP等连接池需要配置connection-test-query达梦中简单的SELECT 1或SELECT 1 FROM DUAL即可。不配置可能导致连接池认为连接失效而不断创建新连接。3.2 Flowable SQL脚本的深度适配改造Flowable引擎启动时会根据配置决定是否自动执行数据库初始化脚本flowable.*.create.*.sql。我们的主战场就在这里。官方脚本位于Flowable引擎jar包的org/flowable/db/create目录下。我们需要针对达梦创建一套自己的脚本。核心改造原则关键字和数据类型映射AUTO_INCREMENT-IDENTITY(1,1)。这是自增主键的写法差异必须改。DATETIME-TIMESTAMP。达梦更推荐使用TIMESTAMP来存储日期时间。TINYINT-NUMBER(3)或INTEGER。达梦没有TINYINT根据实际存储的数值范围选择。ENGINEInnoDB- 删除。这是MySQL的表引擎声明达梦不支持直接去掉整行。COMMENT- 达梦的注释语法是COMMENT ON TABLE/COLUMN需要将字段后的COMMENT ‘xxx’拆分成独立的COMMENT ON语句。KEY PRIMARY (ID)-PRIMARY KEY (ID)。达梦对主键的声明语法更标准。索引和约束语法达梦创建索引时不能在同一句CREATE TABLE语句中通过KEY关键字定义普通索引必须使用单独的CREATE INDEX语句。外键约束的语法基本兼容但要注意命名不要超长不超过128字节。长文本字段处理 Flowable的ACT_GE_BYTEARRAY资源表和ACT_HI_COMMENT评论表等表有LONGBLOB或LONGTEXT字段。达梦对应的类型是CLOB长文本和BLOB二进制长文本。直接映射即可但要注意在插入和查询时可能需要使用达梦特定的函数如DBMS_LOB包来处理超大对象不过JDBC驱动通常会封装好。实操示例改造ACT_RE_PROCDEF流程定义表假设原始MySQL脚本片段如下CREATE TABLE ACT_RE_PROCDEF ( ID_ varchar(64) NOT NULL, REV_ integer, CATEGORY_ varchar(255), NAME_ varchar(255), KEY_ varchar(255) NOT NULL, VERSION_ integer NOT NULL, DEPLOYMENT_ID_ varchar(64), RESOURCE_NAME_ varchar(4000), DGRM_RESOURCE_NAME_ varchar(4000), DESCRIPTION_ varchar(4000), HAS_START_FORM_KEY_ tinyint, HAS_GRAPHICAL_NOTATION_ tinyint, SUSPENSION_STATE_ integer, TENANT_ID_ varchar(255) default , ENGINE_VERSION_ varchar(255), DERIVED_FROM_ varchar(64), DERIVED_FROM_ROOT_ varchar(64), DERIVED_VERSION_ integer DEFAULT 0 NOT NULL, PRIMARY KEY (ID_), UNIQUE KEY ACT_UNIQ_PROCDEF_KEY_TENANT (KEY_,VERSION_, TENANT_ID_) ) ENGINEInnoDB DEFAULT CHARSETutf8 COLLATE utf8_bin;适配后的达梦脚本应为CREATE TABLE ACT_RE_PROCDEF ( ID_ VARCHAR(64) NOT NULL, REV_ INTEGER, CATEGORY_ VARCHAR(255), NAME_ VARCHAR(255), KEY_ VARCHAR(255) NOT NULL, VERSION_ INTEGER NOT NULL, DEPLOYMENT_ID_ VARCHAR(64), RESOURCE_NAME_ VARCHAR(4000), DGRM_RESOURCE_NAME_ VARCHAR(4000), DESCRIPTION_ VARCHAR(4000), HAS_START_FORM_KEY_ INTEGER, -- 达梦无TINYINT用INTEGER替代 HAS_GRAPHICAL_NOTATION_ INTEGER, SUSPENSION_STATE_ INTEGER, TENANT_ID_ VARCHAR(255) DEFAULT , ENGINE_VERSION_ VARCHAR(255), DERIVED_FROM_ VARCHAR(64), DERIVED_FROM_ROOT_ VARCHAR(64), DERIVED_VERSION_ INTEGER DEFAULT 0 NOT NULL, PRIMARY KEY (ID_) ); CREATE UNIQUE INDEX ACT_UNIQ_PROCDEF_KEY_TENANT ON ACT_RE_PROCDEF(KEY_, VERSION_, TENANT_ID_); COMMENT ON TABLE ACT_RE_PROCDEF IS ‘流程定义数据表’; COMMENT ON COLUMN ACT_RE_PROCDEF.ID_ IS ‘主键’; -- ... 其他字段注释心得不要试图手动修改所有脚本工作量巨大且易错。我的做法是先使用达梦的“迁移工具”或一些SQL转换器进行初步转换然后以转换后的脚本为基础进行精细化的校对和修正重点就是上面提到的几个原则点。可以编写一个简单的脚本或使用IDE的批量替换功能来辅助。3.3 Spring Boot配置的针对性调整在application.yml中除了数据源还需要对Flowable的配置进行针对性设置flowable: async-executor-activate: true # 启用异步执行器7.x推荐 database-schema-update: true # 首次启动设为true自动执行建表脚本 db-history-used: true # 使用历史数据 history-level: audit # 历史级别通常用audit或full database-type: oracle # 关键告诉Flowable使用Oracle方言最重要的配置是database-type: oracle。因为达梦的SQL方言与Oracle高度兼容将Flowable的数据库类型设置为oracle引擎在生成分页查询、时间函数等动态SQL时就会采用Oracle的语法规则这能解决绝大部分运行时SQL兼容性问题。当然这要求你的达梦数据库实例配置的兼容模式支持Oracle语法。4. 实操过程与核心环节实现4.1 准备适配后的SQL脚本库获取官方脚本从Flowable 7.x的发行包如flowable-engine-7.0.0.jar中解压出org/flowable/db/create目录下的所有flowable.*.create.engine.sql脚本。批量转换与校对按照第3.2节的原则对所有脚本进行转换。建议按模块engine, history, identity等分开处理便于管理。组织资源在Spring Boot项目的src/main/resources目录下创建如/sql/dameng的文件夹将修改好的脚本按原命名规则放入。例如flowable.dm.create.engine.sql。4.2 配置Spring Boot工程以使用自定义脚本我们需要自定义Flowable的自动配置告诉它使用我们准备好的达梦脚本而不是jar包里的默认脚本。方案一通过application.yml指定简单但可能不彻底flowable: database-schema-update: true database-schema: classpath:/sql/dameng/ # 指定自定义脚本路径这种方式理论上可行但需要确保你的脚本命名完全符合Flowable内部约定的格式如flowable.{db-type}.create.{component}.sql并且要覆盖所有组件engine, history, identity, form...实操中可能遇到路径解析问题。方案二自定义ProcessEngineConfigurationConfigurer推荐更可控这是一个更强大和灵活的方式。创建一个配置类Configuration public class FlowableDamengConfig { Bean public ProcessEngineConfigurationConfigurer processEngineConfigurationConfigurer() { return configuration - { // 1. 设置数据库类型为Oracle configuration.setDatabaseType(oracle); // 2. 禁用默认的自动创建脚本逻辑 configuration.setDatabaseSchemaUpdate(ProcessEngineConfiguration.DB_SCHEMA_UPDATE_FALSE); // 3. 手动设置自定义的建表SQL资源路径 // 这里需要根据Flowable内部类名来定位资源比较hack但一劳永逸 // 更稳健的做法是在应用启动后手动执行我们准备好的SQL文件 }; } // 推荐做法使用DataSourceInitializer在Spring启动后执行SQL Bean public DataSourceInitializer dataSourceInitializer(DataSource dataSource) { ResourceDatabasePopulator populator new ResourceDatabasePopulator(); populator.addScript(new ClassPathResource(/sql/dameng/flowable.dm.create.engine.sql)); populator.addScript(new ClassPathResource(/sql/dameng/flowable.dm.create.history.sql)); populator.addScript(new ClassPathResource(/sql/dameng/flowable.dm.create.identity.sql)); // ... 添加所有必要的脚本 populator.setSeparator(;); // 达梦SQL分隔符 populator.setIgnoreFailedDrops(true); DataSourceInitializer initializer new DataSourceInitializer(); initializer.setDataSource(dataSource); initializer.setDatabasePopulator(populator); // 设置只在没有表的时候初始化根据某个核心表是否存在判断 initializer.setEnabled(isDatabaseEmpty(dataSource)); return initializer; } private boolean isDatabaseEmpty(DataSource dataSource) { // 实现一个检查例如查询ACT_GE_PROPERTY表是否存在 // 如果不存在返回true触发初始化 try (Connection conn dataSource.getConnection(); ResultSet rs conn.getMetaData().getTables(null, “FLOWABLE”, “ACT_GE_PROPERTY”, null)) { return !rs.next(); } catch (SQLException e) { // 日志记录 return true; // 出错时也尝试初始化 } } }通过DataSourceInitializer我们完全掌控了数据库初始化的时机和执行的SQL内容避免了Flowable自动机制可能带来的不确定性。4.3 启动应用与初始化验证配置好上述所有内容后启动Spring Boot应用。观察启动日志重点关注DataSourceInitializer是否执行了我们的SQL脚本以及Flowable引擎是否成功初始化。连接到达梦数据库使用管理工具如达梦管理工具或DBeaver查看FLOWABLE模式下是否成功创建了所有ACT_开头的表。通过Flowable提供的REST API或集成到应用中的API尝试部署一个最简单的BPMN 2.0流程文件例如一个只有开始和结束节点的流程。如果部署成功并在ACT_RE_PROCDEF和ACT_RE_DEPLOYMENT表中看到记录说明表结构和基础运行环境基本正常。5. 常见问题与排查技巧实录在实际操作中你几乎一定会遇到下面这些问题。这里我把它们和解决方案记录下来。5.1 表创建失败语法错误问题现象启动应用时日志报错提示SQL语法错误通常在创建某张表或索引时失败。排查思路定位错误SQL仔细查看日志堆栈找到达梦数据库返回的具体错误信息和导致错误的SQL片段。核对脚本在自定义的SQL脚本中找到对应的建表语句。对照原则检查检查是否还有未转换的MySQL特有语法如AUTO_INCREMENT,ENGINE,TINYINT, 内联的KEY索引定义等。达梦关键字冲突有些列名可能是达梦的保留字如KEY,COMMENT。虽然Flowable的表字段名后都有下划线如KEY_一般不会冲突但仍需注意。如果冲突需要对字段名加双引号如“KEY_”但这会非常麻烦尽量避免。技巧在达梦数据库上开启SQL日志或使用跟踪功能可以捕获到应用执行的所有SQL语句对于调试动态SQL问题至关重要。可以在达梦的dm.ini配置文件中设置SVR_LOG1并指定SVR_LOG_FILE_PATH。5.2 流程启动或任务查询失败分页查询错误问题现象部署流程正常但启动流程实例或查询任务列表时报错提示SQL异常错误信息可能包含ROWNUM、RN__或子查询嵌套问题。原因分析这是最典型的“方言”问题。即使设置了database-typeoracleFlowable内部某些复杂查询尤其是嵌套查询生成的分页SQL可能在达梦上执行仍有细微差别。达梦对Oracle的ROWNUM分页模拟并非100%完美。解决方案确认方言设置首先确保flowable.database-typeoracle已生效。自定义分页处理器如果问题依旧可能需要实现一个自定义的AbstractPagingProvider。但这属于深度定制需要对Flowable源码有较深理解。更实用的变通方案在实际项目中如果遇到特定分页查询出错可以暂时考虑关闭Flowable的历史查询分页功能如果业务允许或者通过覆盖Flowable的默认服务实现将出错的查询方法替换为手写兼容达梦的SQL。例如自定义一个MyTaskQueryImpl继承自TaskQueryImpl重写其executeList方法。5.3 历史数据查询异常时间函数不兼容问题现象查询历史流程实例或任务时涉及时间范围过滤的条件失效或报错。原因分析Flowable在生成查询条件时可能会使用数据库特定的时间函数如DATE_ADD(MySQL) 或ADD_MONTHS(Oracle)。当方言设置为oracle时它会使用Oracle的函数但达梦对某些函数的支持或参数顺序可能有差异。排查与解决通过日志或数据库跟踪抓取到出错的SQL。分析其中的时间函数。例如发现是TRUNC函数处理方式不同。解决方案有两种方案A推荐在业务层避免使用过于复杂的时间过滤条件或者将计算转移到Java代码中将计算好的时间点作为参数传入查询。方案B侵入性强自定义Flowable的VariableType或历史管理器HistoryManager重写涉及时间处理的SQL生成逻辑。这需要深入Flowable内部机制。5.4 连接池与长事务问题问题现象系统运行一段时间后出现连接池耗尽、数据库锁超时或死锁。原因分析Flowable处理长流程如包含用户任务时一个流程实例可能会跨越多个数据库事务。达梦数据库的默认隔离级别和锁机制可能与MySQL有差异。同时连接池配置不当如max-lifetime太短也可能导致正在执行长事务的连接被回收从而引发错误。优化建议调整达梦参数咨询DBA适当调整达梦数据库的UNDO_RETENTION等参数以更好地支持长事务。优化连接池配置适当增加HikariCP的maximum-pool-size并确保connection-timeout和max-lifetime设置合理避免在事务中途断开连接。可以将max-lifetime设置为略大于你预估的最长流程执行时间。审视流程设计检查是否有流程节点长时间等待如“挂起”状态而不释放数据库连接。考虑使用Flowable的异步执行器async-executor-activate: true来分离流程执行与核心事务。5.5 数据迁移的挑战如果你是从旧的Flowable MySQL环境迁移到达梦还需要进行数据迁移。这不是简单的mysqldump和dmimp就能解决的。迁移步骤建议结构迁移使用我们适配好的达梦建表脚本在新环境创建空表。数据迁移基础数据对于ACT_GE_*通用数据、ACT_RE_*静态部署数据等表可以使用数据库工具尝试直接导入导出注意字段类型的映射尤其是时间、大文本字段。运行时和历史数据ACT_RU_*运行时数据和ACT_HI_*历史数据表数据量可能巨大且包含外键约束。建议编写专门的迁移脚本利用Flowable的API如HistoryService进行数据读取和重放虽然慢但能保证数据一致性和引擎状态的正确性。切忌直接操作数据库表否则极易破坏引擎内部状态。严格验证迁移后必须对关键流程实例、任务、历史记录进行端到端的业务验证。6. 性能调优与监控考量完成基础适配后在准生产环境进行压力测试时可能会发现性能瓶颈。以下是一些针对Flowable on Dameng的调优方向达梦数据库层面表空间与存储为Flowable的表创建独立的表空间并放置在高速存储上。合理设置初始扩展大小避免频繁扩展。索引优化Flowable的表通常已有较多索引。使用达梦的性能监控工具如DM Performance Monitor分析慢SQL检查是否有缺失的索引。特别注意流程实例IDPROC_INST_ID_、执行流IDEXECUTION_ID_、任务IDTASK_ID_等高频查询字段的索引效率。内存参数调整达梦的BUFFER、MEMORY_POOL等内存参数确保有足够的内存缓存流程相关的数据。Flowable配置层面异步执行器务必启用并合理配置AsyncExecutor。将耗时的作业如历史数据清理、定时器触发交给异步线程池避免阻塞核心流程线程。调整core-pool-size和max-pool-size以适应你的并发量。批量处理Flowable 7.x增强了批量操作。确保在插入或更新大量历史数据时相关配置如flowable.history.batch-size已优化。缓存配置Flowable内置了流程定义等缓存。在流程定义不常变更的生产环境可以适当增加缓存大小如flowable.process-definition-cache-limit减少数据库访问。应用监控集成Micrometer等指标库将Flowable的指标如活动流程实例数、已完成任务数、作业队列长度暴露给Prometheus和Grafana。监控达梦数据库的连接数、慢SQL、锁等待情况建立基线以便在出现性能退化时快速定位。整个升级适配过程是对耐心和细心的极大考验。它没有银弹需要你像侦探一样根据错误日志去分析底层SQL再结合达梦和Flowable的知识去解决。成功的关键在于分阶段推进每完成一步都做充分的验证。当你在达梦数据库上成功跑起第一个流程实例时那种成就感会让你觉得所有的折腾都是值得的。最后记住一点在彻底完成所有功能测试和性能验证之前不要轻易对生产环境动刀。