SpringBoot+Flowable 审批候选人策略设计：十余种 Strategy + Invoker，一次讲清下一关谁审

SpringBoot+Flowable 审批候选人策略设计：十余种 Strategy + Invoker，一次讲清下一关谁审

🌐演示地址：http://ruoyioffice.com | 📦源码1·GitHub：ruoyi-office | 📦源码2·GitCode：ruoyi-office | 📦源码3·Gitee：ruoyi-office | 💬微信：17156169080（备注「RuoYi Office」）

流程画得再漂亮，下一关「没人可审」就全废。硬编码assignee只能应付 demo；真实企业要的是：按角色、按部门负责人、按发起人自选、按表单里填的「项目经理」……正确姿势是策略模式：每个规则一个 Strategy，Invoker 统一注册、计算与部署校验。

▲ 一屏看清：Invoker 注册/分发/校验 → 四类策略（组织 · 发起人 · 表单 · 兜底）→ candidateStrategy / candidateParam / validateBpmnConfig

引言：下一关谁审，才是流程真正的难题

目标架构一句话：设计器写 strategy+param；运行时 Invoker 算人；部署前先校验。

一、策略枚举：把「人从哪来」编码化

BpmTaskCandidateStrategyEnum用整型策略码区分规则，例如：

设计器侧把candidateStrategy/candidateParam写入 UserTask 扩展属性；运行时再解析。

▲ 流程模型是策略配置的入口：每个审批节点选一种候选人规则，而不是写死工号

二、Strategy 接口：统一契约

publicinterfaceBpmTaskCandidateStrategy{BpmTaskCandidateStrategyEnumgetStrategy();voidvalidateParam(Stringparam);defaultbooleanisParamRequired(){returntrue;}Set<Long>calculateUsersByTask(DelegateExecutionexecution,Stringparam);Set<Long>calculateUsersByActivity(BpmnModelmodel,StringactivityId,Stringparam,LongstartUserId,StringprocessDefinitionId,Map<String,Object>processVariables);}

每个策略一个 Spring Bean，构造BpmTaskCandidateInvoker时注入List<BpmTaskCandidateStrategy>，放进strategyMap，重复策略码直接 Assert 失败——避免两个实现抢同一个码。

三、Invoker：计算链路与三道保险

运行时核心是calculateUsersByTask：

Integerstrategy=BpmnModelUtils.parseCandidateStrategy(flowElement);Stringparam=BpmnModelUtils.parseCandidateParam(flowElement);Set<Long>userIds=getCandidateStrategy(strategy).calculateUsersByTask(execution,param);removeDisableUsers(userIds);// 去掉禁用账号if(CollUtil.isEmpty(userIds)){// 候选人为空 → 走 ASSIGN_EMPTY 兜底策略userIds=getCandidateStrategy(ASSIGN_EMPTY).calculateUsersByTask(execution,param);}removeStartUserIfSkip(userIds,flowElement,startUserId);// 发起人跳过配置

三道保险值得抄：

1. @DataPermission(enable = false)：算候选人时关掉数据权限，避免「权限过滤导致找不到审批人」
2. 禁用用户剔除：账号停用不能继续占坑
3. 为空兜底 / 发起人跳过：空了走「审批人为空」配置；若配置了发起人与审批人相同时跳过，则从集合移除（只剩一人时不删，避免无人可审）

自动通过 / 自动拒绝的节点直接返回空集合，不再算人。

▲ 设计器节点配置把策略落到模型；部署前 Invoker.validateBpmnConfig 会扫所有 UserTask

四、部署前校验：宁可发不出去，也不要跑到一半卡住

userTaskList.forEach(userTask->{// 自动通过/拒绝：跳过Integerstrategy=BpmnModelUtils.parseCandidateStrategy(userTask);Stringparam=BpmnModelUtils.parseCandidateParam(userTask);if(strategy==null){throwexception(MODEL_DEPLOY_FAIL_TASK_CANDIDATE_NOT_CONFIG,userTask.getName());}if(candidateStrategy.isParamRequired()&&StrUtil.isBlank(param)){throwexception(MODEL_DEPLOY_FAIL_TASK_CANDIDATE_NOT_CONFIG,userTask.getName());}getCandidateStrategy(strategy).validateParam(param);});

这是产品体验关键：错配在发布时报错，而不是员工提交后卡在待办黑洞。

▲ 策略算对了，待办才会落到真人；算错了再漂亮的时间轴也救不了

五、四类策略怎么选（产品视角）

扩展新规则时：加枚举码 → 实现 Strategy Bean → 设计器下拉加一项。Invoker 不用改。

六、技术亮点总结

七、快速体验

在线演示：http://ruoyioffice.com/web/（账号admin/admin123）

1. 打开流程管理 → 流程模型，编辑一个简单流程。
2. 点开审批节点，切换「指定角色 / 发起人自选 / 发起人部门负责人」等策略并保存发布。
3. 故意清空某节点审批人配置再发布，确认被校验拦住。
4. 发起业务单，到待办核对任务是否落到预期人。

源码仓库：GitHub | GitCode | Gitee

常见问题（FAQ）

为什么算候选人要关闭数据权限？

候选人计算是「系统找谁该审」，不是「当前登录人能看哪些数据」。若带着数据权限过滤，部门负责人可能被滤掉，流程直接断。

候选人为空一定会失败吗？

不一定。会再走「审批人为空」策略（转交管理员、自动通过等，取决于配置）。兜底策略计算时不再剔除禁用用户，防止二次清空。

发起人自选和审批人自选有什么区别？

发起人自选：提交申请时选本节点审批人。审批人自选：当前节点审批时指定下一节点审批人。时机不同。

表单内用户字段策略的 param 是什么？

通常是表单字段名；运行时从流程变量里取出用户 ID 再解析。适合「项目经理」「对接人」等随单变化的角色。

新策略要改 Flowable 引擎吗？

不用。扩展属性仍是 strategy/param；新增一个实现BpmTaskCandidateStrategy的 Bean 即可被 Invoker 自动注册。

结语

候选人策略的本质，是把「下一关谁审」从硬编码变成可配置、可校验、可扩展的策略族。Invoker 负责注册与兜底，设计器负责把规则写进模型——流程才能在组织变动中活下去。

你们项目里审批人是写死的，还是已经策略化了？有没有踩过「部署成功但无人可审」？欢迎评论区交流。

💡想要体验 RuoYi Office 的强大功能？

🌐在线演示：http://ruoyioffice.com/web/（账号 admin / admin123）

📦源码仓库：GitHub | GitCode | Gitee

💬技术咨询：添加微信17156169080，备注「RuoYi Office」

⭐如果觉得不错，请给个 Star 支持一下！