Activiti7实战从数据库表变化逆向解析会签与或签的运行机制当你在深夜接到告警电话线上审批流程卡在某个会签节点已经两小时——作为团队里最熟悉Activiti7的开发者此刻需要的不是官方文档的标准答案而是直指问题本质的排查手段。本文将带你像法医解剖现场一样通过分析act_ru_task、act_hi_taskinst等核心表的字段变化逆向推演出多实例任务的真实运行状态。1. 解剖Activiti7的多实例任务模型工作流引擎最精妙的设计在于所有运行时状态都忠实地反映在数据库表中。理解下面三个核心表的协作关系就像掌握了流程引擎的X光透视能力act_ru_task运行时任务表相当于流程的短期记忆act_hi_taskinst历史任务表记录完整的生命周期病历act_ru_execution运行时执行流揭示流程的神经传导路径多实例任务会签/或签的本质是同一个节点生成多个并行或串行的任务实例。当我们在流程定义中设置multiInstanceLoopCharacteristics时引擎会在运行时创建一组具有特殊标记的任务-- 典型的多实例任务查询 SELECT * FROM act_ru_task WHERE PROC_INST_ID_ 流程实例ID AND IS_COUNT_ENABLED_ 1;关键字段IS_COUNT_ENABLED_1就是多实例任务的身份证。更精妙的是每个子任务会共享相同的PROC_INST_ID_但拥有不同的EXECUTION_ID_这解释了为什么同一个会签节点会产生多条任务记录。2. 会签场景的数据库指纹分析假设我们有一个需要三人会签的采购审批流程完成条件设置为超过半数同意即通过。当第二个审批人完成任务时数据库会留下这样的痕迹2.1 运行时表(act_ru_task)的生死簿任务ID执行ID任务名称处理人创建时间是否多实例50205021采购审批张三09:00150235024采购审批李四09:05150265027采购审批王五09:101当李四完成任务后神奇的事情发生了所有相关任务瞬间消失引擎会原子性地删除本节点所有运行时任务历史表记录分化通过delete_reason_字段揭示不同命运2.2 历史表(act_hi_taskinst)的考古现场SELECT TASK_DEF_KEY_, ASSIGNEE_, END_TIME_, DELETE_REASON_ FROM act_hi_taskinst WHERE PROC_INST_ID_ 流程实例ID ORDER BY START_TIME_;查询结果会呈现戏剧性的对比任务定义KEY处理人结束时间删除原因approve张三09:30completedapprove李四09:35NULLapprove王五NULLmulti-instance completion condition met这三个字段组合就是诊断会签问题的三原色END_TIME_为NULL任务被强制终止未实际完成DELETE_REASON_包含multi-instance因完成条件满足而被系统清理NULL删除原因实际完成的任务本例中李四是第二个审批人触发完成条件3. 或签异常的场景还原术或签与会签的最大区别在于完成条件的严格程度。当遇到明明有人审批了流程却不推进的灵异事件时按这个检查清单排查验证完成条件表达式-- 查询流程变量验证实际值 SELECT * FROM act_ru_variable WHERE EXECUTION_ID_ IN ( SELECT ID_ FROM act_ru_execution WHERE PROC_INST_ID_ 流程实例ID );重点检查nrOfCompletedInstances是否≥1检查历史任务终止原因-- 筛选异常终止记录 SELECT * FROM act_hi_taskinst WHERE PROC_INST_ID_ 流程实例ID AND DELETE_REASON_ LIKE %exception%;执行流卡点分析-- 定位阻塞的执行流 SELECT * FROM act_ru_execution WHERE PROC_INST_ID_ 流程实例ID AND IS_ACTIVE_ 1 AND ACT_ID_ 或签节点ID;我曾遇到过一个经典案例审批人完成任务后流程仍然停滞。最终发现是Completion Condition表达式被误写为${nrOfCompletedInstances 1}会签写法而非${nrOfCompletedInstances 1}或签标准。这个错误导致必须恰好一人审批才能通过与或签的设计初衷背道而驰。4. 高级调试技巧与性能优化当流程实例量达到百万级时直接查询生产数据库可能引发性能问题。这里分享几个实战验证过的技巧4.1 安全高效的查询方案-- 使用覆盖索引优化查询 EXPLAIN SELECT ID_, NAME_, ASSIGNEE_, CREATE_TIME_ FROM act_hi_taskinst FORCE INDEX (ACT_IDX_HI_TASK_INST_PROCINST) WHERE PROC_INST_ID_ 流程实例ID LIMIT 100;关键点强制使用ACT_IDX_HI_TASK_INST_PROCINST索引只选择必要字段减少I/O添加LIMIT防止结果集过大4.2 变量注入监控策略在多实例任务中变量传递异常是常见故障点。这个监控脚本可以实时捕获变量变化// 注册执行监听器捕获变量事件 runtimeService.addEventListener(new ExecutionListener() { Override public void notify(DelegateExecution execution) { if(multiInstanceBody.equals(execution.getCurrentActivityId())) { logger.info(多实例变量快照: {}, execution.getVariables().entrySet().stream() .filter(e - e.getKey().startsWith(nrOf)) .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue))); } } }, ExecutionListener.EVENTNAME_TAKE);4.3 历史数据归档策略对于运行多年的系统建议定期归档历史数据-- 创建历史数据归档表 CREATE TABLE act_hi_taskinst_archive LIKE act_hi_taskinst; -- 分批迁移数据 INSERT INTO act_hi_taskinst_archive SELECT * FROM act_hi_taskinst WHERE END_TIME_ DATE_SUB(NOW(), INTERVAL 3 MONTH) LIMIT 10000;配合Spring Batch可以实现无停机迁移。记得先迁移数据再创建索引速度能提升5-8倍。
Activiti7实战：从‘会签’与‘或签’的数据库表变化，逆向理解流程引擎的运转机制
Activiti7实战从数据库表变化逆向解析会签与或签的运行机制当你在深夜接到告警电话线上审批流程卡在某个会签节点已经两小时——作为团队里最熟悉Activiti7的开发者此刻需要的不是官方文档的标准答案而是直指问题本质的排查手段。本文将带你像法医解剖现场一样通过分析act_ru_task、act_hi_taskinst等核心表的字段变化逆向推演出多实例任务的真实运行状态。1. 解剖Activiti7的多实例任务模型工作流引擎最精妙的设计在于所有运行时状态都忠实地反映在数据库表中。理解下面三个核心表的协作关系就像掌握了流程引擎的X光透视能力act_ru_task运行时任务表相当于流程的短期记忆act_hi_taskinst历史任务表记录完整的生命周期病历act_ru_execution运行时执行流揭示流程的神经传导路径多实例任务会签/或签的本质是同一个节点生成多个并行或串行的任务实例。当我们在流程定义中设置multiInstanceLoopCharacteristics时引擎会在运行时创建一组具有特殊标记的任务-- 典型的多实例任务查询 SELECT * FROM act_ru_task WHERE PROC_INST_ID_ 流程实例ID AND IS_COUNT_ENABLED_ 1;关键字段IS_COUNT_ENABLED_1就是多实例任务的身份证。更精妙的是每个子任务会共享相同的PROC_INST_ID_但拥有不同的EXECUTION_ID_这解释了为什么同一个会签节点会产生多条任务记录。2. 会签场景的数据库指纹分析假设我们有一个需要三人会签的采购审批流程完成条件设置为超过半数同意即通过。当第二个审批人完成任务时数据库会留下这样的痕迹2.1 运行时表(act_ru_task)的生死簿任务ID执行ID任务名称处理人创建时间是否多实例50205021采购审批张三09:00150235024采购审批李四09:05150265027采购审批王五09:101当李四完成任务后神奇的事情发生了所有相关任务瞬间消失引擎会原子性地删除本节点所有运行时任务历史表记录分化通过delete_reason_字段揭示不同命运2.2 历史表(act_hi_taskinst)的考古现场SELECT TASK_DEF_KEY_, ASSIGNEE_, END_TIME_, DELETE_REASON_ FROM act_hi_taskinst WHERE PROC_INST_ID_ 流程实例ID ORDER BY START_TIME_;查询结果会呈现戏剧性的对比任务定义KEY处理人结束时间删除原因approve张三09:30completedapprove李四09:35NULLapprove王五NULLmulti-instance completion condition met这三个字段组合就是诊断会签问题的三原色END_TIME_为NULL任务被强制终止未实际完成DELETE_REASON_包含multi-instance因完成条件满足而被系统清理NULL删除原因实际完成的任务本例中李四是第二个审批人触发完成条件3. 或签异常的场景还原术或签与会签的最大区别在于完成条件的严格程度。当遇到明明有人审批了流程却不推进的灵异事件时按这个检查清单排查验证完成条件表达式-- 查询流程变量验证实际值 SELECT * FROM act_ru_variable WHERE EXECUTION_ID_ IN ( SELECT ID_ FROM act_ru_execution WHERE PROC_INST_ID_ 流程实例ID );重点检查nrOfCompletedInstances是否≥1检查历史任务终止原因-- 筛选异常终止记录 SELECT * FROM act_hi_taskinst WHERE PROC_INST_ID_ 流程实例ID AND DELETE_REASON_ LIKE %exception%;执行流卡点分析-- 定位阻塞的执行流 SELECT * FROM act_ru_execution WHERE PROC_INST_ID_ 流程实例ID AND IS_ACTIVE_ 1 AND ACT_ID_ 或签节点ID;我曾遇到过一个经典案例审批人完成任务后流程仍然停滞。最终发现是Completion Condition表达式被误写为${nrOfCompletedInstances 1}会签写法而非${nrOfCompletedInstances 1}或签标准。这个错误导致必须恰好一人审批才能通过与或签的设计初衷背道而驰。4. 高级调试技巧与性能优化当流程实例量达到百万级时直接查询生产数据库可能引发性能问题。这里分享几个实战验证过的技巧4.1 安全高效的查询方案-- 使用覆盖索引优化查询 EXPLAIN SELECT ID_, NAME_, ASSIGNEE_, CREATE_TIME_ FROM act_hi_taskinst FORCE INDEX (ACT_IDX_HI_TASK_INST_PROCINST) WHERE PROC_INST_ID_ 流程实例ID LIMIT 100;关键点强制使用ACT_IDX_HI_TASK_INST_PROCINST索引只选择必要字段减少I/O添加LIMIT防止结果集过大4.2 变量注入监控策略在多实例任务中变量传递异常是常见故障点。这个监控脚本可以实时捕获变量变化// 注册执行监听器捕获变量事件 runtimeService.addEventListener(new ExecutionListener() { Override public void notify(DelegateExecution execution) { if(multiInstanceBody.equals(execution.getCurrentActivityId())) { logger.info(多实例变量快照: {}, execution.getVariables().entrySet().stream() .filter(e - e.getKey().startsWith(nrOf)) .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue))); } } }, ExecutionListener.EVENTNAME_TAKE);4.3 历史数据归档策略对于运行多年的系统建议定期归档历史数据-- 创建历史数据归档表 CREATE TABLE act_hi_taskinst_archive LIKE act_hi_taskinst; -- 分批迁移数据 INSERT INTO act_hi_taskinst_archive SELECT * FROM act_hi_taskinst WHERE END_TIME_ DATE_SUB(NOW(), INTERVAL 3 MONTH) LIMIT 10000;配合Spring Batch可以实现无停机迁移。记得先迁移数据再创建索引速度能提升5-8倍。
