MySQL数据迁移到Flowable的最优方案、可用API及ETL设计问询

关于MySQL到Flowable的数据迁移方案 #

1. 最优迁移方式 #

• 优先通过Flowable公开服务API写入数据，禁止直接操作Flowable业务表写入：Flowable的表之间存在大量关联约束、字段逻辑关联（比如流程实例、任务、历史数据、身份关联数据的联动），直接写库极易触发数据不一致，导致后续流程运行报错。
• 迁移分批次执行：先迁移基础数据（用户、用户组、租户等身份数据），再迁移历史流程类数据，最后增量同步正在运行中的流程数据，每批次迁移完成后立刻做数据一致性校验。
• 冷数据（已完结的历史流程）如果不需要在新系统中发起流程操作，仅需查询展示的，可以保留在原MySQL库，新系统做跨库查询即可，没必要全量迁入Flowable，降低迁移风险。

2. 可用的迁移API #

Flowable原生提供的服务接口完全可以覆盖迁移场景，常用的API类如下：

• 身份数据迁移：用IdentityService下的saveUser、saveGroup、createMembership等方法写入用户、用户组、成员关联关系。
• 流程定义数据迁移：用RepositoryService下的createDeployment相关方法部署原系统对应的流程定义文件。
• 运行中流程实例迁移：用RuntimeService下的startProcessInstanceByKey等方法启动流程实例，配合TaskService的相关接口补全任务节点、处理人、变量等信息，还原到原流程的当前运行节点。
• 历史流程数据迁移：用HistoryService下的createHistoricProcessInstanceBuilder、createHistoricTaskInstanceBuilder等方法直接写入历史记录，不需要触发流程运行逻辑。
• 全局/流程/任务变量迁移：调用对应服务下的setVariable相关方法写入即可。

3. ETL流程设计参考 #

如果需要自定义ETL流程，可按照以下步骤设计：

1. 数据抽取阶段：从原MySQL库中分层抽取数据，按身份数据、流程定义数据、流程实例数据、任务数据、变量附件数据的顺序分类导出，导出前完成原数据的空值、非法值、重复值清洗。
2. 数据转换阶段：按照Flowable服务接口的入参要求做字段映射：比如原系统的流程发起人对应Flowable流程实例的startUserId，原系统的任务处理人对应assignee字段，原系统的自定义业务字段统一存为Flowable的流程变量或者业务键businessKey。
3. 数据载入阶段：先做小批量灰度测试，导入10-20条测试数据，校验流程运行、历史查询、权限关联是否正常，校验通过后再全量分批导入，每批次导入后执行校验逻辑：对比原系统和Flowable中对应流程的节点状态、变量、处理人信息是否完全一致。

注意：不要直接修改Flowable库中ACT_*开头的系统表，所有写入操作必须走官方API，避免版本升级后出现兼容性问题。

内容的提问来源于stack exchange，提问作者Sreekanth Mohan