Flowable 6.8.0实战动态多部门审批的架构设计与实现上周在重构公司采购审批系统时遇到一个典型场景技术部需要评估设备参数财务部审核预算法务部检查合同条款——这三个部门的审批必须并行执行且每个部门的处理人需要根据组织架构动态分配。传统硬编码方式不仅维护成本高每次组织调整都要重新发布流程。本文将分享如何用Flowable 6.8.0的多实例子流程配合动态任务分配解决这个问题。1. 多实例并行审批的核心设计多部门并行审批的本质是流程实例的批量创建与协同。在Flowable中这通过multiInstanceLoopCharacteristics元素实现。与简单循环任务不同子流程级别的多实例具有完整生命周期管理能力。关键设计参数对比特性单任务多实例子流程多实例隔离性共享父执行上下文独立执行上下文变量作用域全局可见实例私有父流程共享异常处理影响整个流程可单独补偿适用场景简单会签复杂跨系统协作采购审批流程的BPMN核心结构subProcess iddepartmentApproval name部门审批 multiInstanceLoopCharacteristics flowable:collection${departmentService.getApprovalDepartments(execution)} flowable:elementVariablecurrentDept isSequentialfalse completionCondition${nrOfCompletedInstances nrOfInstances}/completionCondition /multiInstanceLoopCharacteristics !-- 部门内部审批节点 -- /subProcess2. 动态处理人分配方案硬编码分配方式的最大痛点在于组织变更与流程解耦。我们采用三级分配策略部门发现层通过JavaDelegate获取当前有效部门public class DepartmentLookupDelegate implements JavaDelegate { Override public void execute(DelegateExecution execution) { ListDepartment depts departmentService.findByProcessType( (String) execution.getVariable(processType)); execution.setVariable(approvalDepartments, depts); } }角色映射层使用监听器绑定部门与角色userTask iddeptTask name部门审批 extensionElements flowable:taskListener eventcreate classcom.example.DeptTaskAssignmentListener/ /extensionElements /userTask人员决策层基于业务规则确定最终处理人public class DeptTaskAssignmentListener implements TaskListener { Override public void notify(DelegateTask task) { Department dept (Department) task.getVariable(currentDept); String roleType dept.getApprovalRole(); if(FINANCE.equals(dept.getType())) { task.addCandidateGroup(roleType); } else { User user userService.findDefaultApprover( dept.getId(), roleType); task.setAssignee(user.getId()); } } }3. 实战中的性能优化当并发部门超过20个时原始实现会出现性能瓶颈。我们通过以下优化使吞吐量提升300%数据库优化方案为ACT_RU_IDENTITYLINK表添加复合索引CREATE INDEX idx_identitylink_task ON ACT_RU_IDENTITYLINK(TASK_ID_, TYPE_);启用批量插入模式spring.flowable.async-executor-activatetrue spring.flowable.bulk-insert-enabledtrue内存优化技巧在循环特性中使用缓存查询Cacheable(deptApprovers) public ListString getDepartmentApprovers(String deptId) { // 数据库查询 }限制变量作用域multiInstanceLoopCharacteristics flowable:collection${cachedDeptService.getApprovers(deptId)} flowable:elementVariableapprover flowable:variableAggregations[{ target: local, variables: [approvalComment] }]4. 异常处理与监控多实例流程需要特殊的异常处理策略。我们推荐采用分级错误捕获机制子流程级别设置边界事件捕获业务异常boundaryEvent iddeptErrorBoundary attachedToRefdeptTask errorEventDefinition errorRefapprovalRejectedError/ /boundaryEvent实例级别通过执行监听器记录异常public class InstanceErrorLogger implements ExecutionListener { Override public void notify(DelegateExecution execution) { if(execution.getEventName().equals(end)) { MapString, Object vars execution.getVariables(); auditService.logProcessEnd( execution.getProcessInstanceId(), vars); } } }全局监控自定义历史处理器Component public class ApprovalHistoryHandler implements HistoryListener { Override public void eventOccurred(HistoryEvent event) { if(event instanceof HistoricActivityInstanceEvent) { // 分析审批耗时 } } }关键提示在并行多实例场景下务必设置asynctrue属性避免长时间任务阻塞整体流程。5. 与现有系统集成方案许多企业已有HR系统或权限管理系统需要与Flowable深度集成。我们实践出三种可靠模式模式一实时API集成startuml participant Flowable participant HRSystem Flowable - HRSystem : 获取部门信息(同步调用) HRSystem -- Flowable : JSON响应 enduml模式二事件驱动架构EventListener(condition #event.typeORG_CHANGE) public void handleOrgChange(PlatformEvent event) { cache.evict(deptApprovers); processEngine.getRuntimeService() .createChangeDeploymentTenantIdBuilder() .sourceTenantId(event.getTenantId()) .deploy(); }模式三数据镜像同步-- 定时任务将HR数据同步到Flowable专用表 MERGE INTO ACT_ID_GROUP target USING (SELECT dept_code AS ID_, dept_name AS NAME_ FROM hr_departments) source ON (target.ID_ source.ID_) WHEN MATCHED THEN UPDATE SET target.NAME_ source.NAME_ WHEN NOT MATCHED THEN INSERT (ID_, NAME_, TYPE_) VALUES (source.ID_, source.NAME_, dept);实际项目中我们最终采用模式二模式三混合方案日常变更通过事件通知实时处理每日凌晨全量同步作为兜底。这种方案在保证实时性的同时具备最终一致性保障。6. 扩展性设计建议随着业务发展审批流程可能衍生出新的需求。我们在架构设计中预留了这些扩展点动态条件分支sequenceFlow idtoFinance sourceRefapproval targetReffinanceReview conditionExpression xsi:typetFormalExpression ${dept.type FINANCE amount 10000} /conditionExpression /sequenceFlow审批矩阵配置化# approval-matrix.yml finance: base-approver: CFO conditions: - when: amount 100000 then: [CFO, CEO] tech: base-approver: CTO跨流程协同// 在主管审批通过后触发采购流程 runtimeService.startProcessInstanceByKey( purchaseProcess, approvalVariables);在最近一次组织架构调整中这套方案仅需修改部门映射配置即完成适配无需停服或流程变更验证了其灵活性。某个核心审批流程的平均处理时间从原来的72小时降至28小时特别是跨部门协作效率提升显著。