Flowable多实例实战避坑：从‘全员审批’到‘半数通过’的完整配置与调试记录

Flowable多实例审批流程流程引擎

于 2026-05-29 11:25:04 修改

·本内容遵循CC 4.0 BY-SA版权协议

Flowable多实例实战：从全员审批到动态比例通过的深度解析

上周团队接到一个紧急需求：市场部希望将原本需要全员签字的促销方案审批流程，改为"超过半数同意即可自动推进"。听起来简单，但当我们真正在Flowable引擎上实施时，却遇到了各种预期之外的行为——有的审批人还没收到任务流程就结束了，有的明明达到了通过比例却卡住不动。经过三天密集调试，终于摸清了多实例任务的完整运作机制，今天就把这些实战经验系统梳理出来。

1. 多实例基础：不只是简单的循环

很多人把多实例简单理解为for循环，这种认知会导致后续配置出现各种偏差。本质上，Flowable的多实例机制是带有状态管理的智能任务分发系统。我们来看个典型配置：

XML

<multiInstanceLoopCharacteristics

isSequential="false"

flowable:collection="${approvers}"

flowable:elementVariable="assignee">

<completionCondition>${nrOfCompletedInstances/nrOfInstances >= 0.6}</completionCondition>

</multiInstanceLoopCharacteristics>

</userTask>

这个配置会产生几个关键行为：

根据approvers集合自动生成并行实例
每个实例会获得独立的assignee变量
当完成数达到总数60%时立即终止剩余任务

常见误区警示：

集合变量${approvers}必须存在于流程实例级别（而非任务局部变量）
并行模式下nrOfActiveInstances不等于剩余未完成数（而是当前活跃实例数）
表达式中的除法运算最好显式处理精度（建议使用>= 0.6而非> 0.5）

2. 结束条件设计的五种实战模式

2.1 比例通过模式

最常用的动态阈值方案，注意分母处理的两种方式：

JAVA

// 方式一：硬编码比例

${nrOfCompletedInstances/nrOfInstances >= 0.5}

// 方式二：动态阈值（从业务变量读取）

${nrOfCompletedInstances/nrOfInstances >= passRate}

关键点：当审批人列表可能变化时，建议采用动态集合大小计算： ${nrOfCompletedInstances >= Math.ceil(nrOfInstances*0.5)}

2.2 一票否决模式

结合网关实现的特殊逻辑：

XML

${nrOfRejectedInstances > 0 || nrOfApprovedInstances >= requiredApprovals}

</completionCondition>

需要配合任务监听器维护nrOfRejectedInstances变量。

2.3 分级审批模式

不同级别审批人权重不同：

职级	权重	计算方式
普通	1	∑(权重 * 同意状态)
主管	2
总监	3

对应的表达式：

JAVASCRIPT

${sumOfWeights >= totalWeights * 0.6}

2.4 时间窗口模式

在指定时间内收集足够审批：

XML

${(nrOfCompletedInstances >= minApprovals)

|| (dateCompare(now, deadline) > 0)}

</completionCondition>

2.5 混合条件模式

结合多个条件的复杂逻辑：

JAVASCRIPT

${ (nrOfCompletedInstances >= minApprovals && !hasRejection)

|| (nrOfCompletedInstances >= emergencyApprovals) }

3. 调试技巧：看不见的变量与执行流

当多实例行为不符合预期时，可以按以下步骤排查：

3.1 变量检查清单

BASH

# 查看实例变量

flowable-runtime query variables

--processInstanceId [ID]

--names nrOfInstances,nrOfActiveInstances,nrOfCompletedInstances

# 验证集合变量

flowable-runtime query variables

--processInstanceId [ID]

--name approvers

3.2 历史数据分析

关键表查询SQL：

SQL

SELECT * FROM ACT_HI_TASKINST

WHERE PROC_INST_ID_ = '流程实例ID'

ORDER BY START_TIME_ DESC;

SELECT * FROM ACT_HI_VARINST

WHERE PROC_INST_ID_ = '流程实例ID'

AND NAME_ LIKE 'nrOf%';

3.3 日志级别调整

在application.properties中增加：

PROPERTIES

logging.level.org.flowable.engine.impl.persistence.entity=DEBUG

logging.level.org.flowable.task.service.impl=TRACE

典型问题诊断案例：

现象：流程提前结束但未达阈值
排查：检查是否有审批人重复导致nrOfInstances计数不准
解决：在集合变量处理前执行去重操作

4. 高级配置：当基础功能不够用时

4.1 动态调整审批人列表

通过执行监听器实现中途增减审批人：

JAVA

public class DynamicApproverListener implements ExecutionListener {

@Override

public void notify(DelegateExecution execution) {

if ("addApprover".equals(execution.getEventName())) {

List<String> approvers = (List<String>) execution.getVariable("approvers");

approvers.add("new_approver");

execution.setVariable("approvers", approvers);

}

4.2 多实例任务超时处理

结合边界事件实现超时自动跳过：

XML

</timerEventDefinition>

</boundaryEvent>

4.3 跨多实例的任务协作

通过共享变量实现实例间通信：

JAVA

// 在任务完成监听器中

execution.getEngineServices().getRuntimeService()

.setVariable(execution.getProcessInstanceId(),

"lastApprover",

execution.getVariable("assignee"));

5. 性能优化：大规模审批的实践方案

当审批人数量超过50时，需要特别考虑性能问题：

5.1 分批加载策略

XML

<multiInstanceLoopCharacteristics

flowable:collection="${approvalService.getPagedApprovers(execution, 0, 20)}"

flowable:elementVariable="assignee">

<flowable:executionListener

event="end"

class="com.example.LoadNextBatchListener"/>

</extensionElements>

</multiInstanceLoopCharacteristics>

5.2 异步化处理配置

PROPERTIES

# 启用异步多实例

flowable.async.executor.activate=true

flowable.async.executor.default.queue.size=1000

5.3 数据库优化参数

SQL

-- 增加历史表索引

CREATE INDEX IDX_HI_TASKINST_PIID ON ACT_HI_TASKINST(PROC_INST_ID_);

CREATE INDEX IDX_HI_VARINST_PIID ON ACT_HI_VARINST(PROC_INST_ID_);

-- 调整事务超时

SET GLOBAL innodb_lock_wait_timeout=120;

实际项目中，我们曾用这些方案处理过单流程300+审批节点的场景，平均完成时间控制在15分钟内。关键是要避免在内存中一次性加载所有审批人数据，转而采用分页查询+增量加载的方式。