写给做审批系统的你：状态和权限一旦没分层，后面一定越来越乱

Activiti/Flowable 工作流实战业务状态和流程状态怎么保持一致再讲清 RBAC 数据权限工作流项目真正难的地方往往不是“怎么发起流程”而是“流程跑起来之后状态别乱、权限别乱、数据别乱”。这个项目里我能明显看到两条很重要的主线一条是act_z_business.status/result这类流程侧状态管理另一条是sys_permission、SysPermissionDataRule、jurisdiction、节点字段权限这些权限控制。这两块如果一开始没设计好系统前面跑得再快后面也会越来越难维护。文章目录Activiti/Flowable 工作流实战业务状态和流程状态怎么保持一致再讲清 RBAC 数据权限一、为什么“业务状态”和“流程状态”总是容易打架二、这个项目里更稳的做法流程状态和业务状态分层2.1 流程侧状态放在 act_z_business2.2 业务侧状态放在业务表三、流程状态到底该怎么同步才不容易乱3.1 发起时同步一次流程主状态3.2 取消、办结、审批通过时统一回写3.3 业务表不要直接写成“经理待审”“财务待审”四、我建议的“一致性设计原则”4.1 流程节点只保留一份真相4.2 业务表只保留业务语义状态4.3 所有状态更新都走统一服务层4.4 事务失败时把外部副作用一起回滚五、只做 RBAC 为什么不够六、这个项目里的权限体系其实是 4 层一起工作的6.1 第一层菜单/功能权限6.2 第二层数据权限6.3 第三层页面/按钮权限6.4 第四层节点字段权限七、RBAC 数据权限 节点权限三者到底怎么分工八、如果让我继续优化这套权限体系我会补什么8.1 把流程状态到业务状态的映射做成统一配置8.2 让节点字段权限和按钮权限共用一套表达式能力8.3 对“流程状态一致性”增加巡检机制九、总结一、为什么“业务状态”和“流程状态”总是容易打架很多团队一开始做审批系统都会这么写业务表里写一个状态字段审批到哪个节点就把状态改成“经理待审”“财务待审”“总监待审”前端列表也直接根据这个状态做展示短期看很省事长期看问题很大。因为流程引擎本身已经有当前任务当前节点流程实例状态历史任务轨迹如果业务表再自己维护一套“细颗粒节点状态”很容易出现两边不一致引擎里已经到财务节点了业务表还停在经理审批引擎里流程被撤销了业务表却还是审批中引擎里任务已经办结业务表列表仍显示待处理这类问题在项目刚上线时不一定明显但一旦涉及加签退回撤销子流程条件分支状态漂移几乎一定会出现。二、这个项目里更稳的做法流程状态和业务状态分层我比较认可这个项目里的思路因为它没有把所有状态都塞进一处而是做了分层。2.1 流程侧状态放在act_z_business从ActivitiConstant和ActBusiness能看出这套系统对流程状态做了统一抽象。status负责描述流程生命周期0待提交1处理中2处理结束3已撤销result负责描述流程结果0待提交1处理中2通过3驳回4撤销5删除6办结另外还有procInstIdnodeIdcurrTaskNameapplyTime这些字段一起构成了“流程侧统一真相”。2.2 业务侧状态放在业务表业务表仍然可以保留自己的业务语义状态比如单据是否启用计划是否终止库存是否冻结合同是否到期这个项目里DataBaseConstant也专门定义了标准字段bpm_status我会把它理解为“业务面向报表与业务判断的状态字段”而不是“替代流程引擎的节点状态字段”。也就是说流程状态负责描述流程跑到哪一步业务状态负责描述业务当前是什么语义这两者应该映射不应该互相覆盖。三、流程状态到底该怎么同步才不容易乱这套项目里其实已经给了一个相对标准的同步思路。3.1 发起时同步一次流程主状态在ActBusinessServiceImpl.apply里发起流程成功之后会更新procInstIdstatus 1result 1applyTimecurrTaskName这一步非常关键。它说明系统不是在业务表里随便写一句“已提交”而是把流程实例真正跑起来之后再统一更新桥表状态。3.2 取消、办结、审批通过时统一回写在cancel、finish以及任务审批相关逻辑里又会更新取消时status STATUS_CANCELED办结时status STATUS_FINISH通过时result RESULT_PASS撤回/办结时result RESULT_REVOKE这说明桥表不是只在发起时写一次而是整个流程生命周期都在维护。3.3 业务表不要直接写成“经理待审”“财务待审”这是我最想强调的一点。如果你把业务表状态直接写成采购经理待审财务负责人待审总经理待审那你其实是在把 BPMN 的节点语义复制一份到业务库里。一旦流程图稍微调整增加一个会签节点某个分支跳过财务某个节点改名你业务库里的语义就会开始变形。更稳的做法应该是细粒度流程节点以引擎和act_z_business.nodeId/currTaskName为准粗粒度业务语义以业务表自己的bpm_status或biz_status为准比如业务表只保留草稿审批中已通过已驳回已撤销这就足够了。四、我建议的“一致性设计原则”如果你也在做 Activiti/Flowable 项目我建议你优先守住这 4 条。4.1 流程节点只保留一份真相“当前在谁手里”“当前是什么节点”“是否还有待办”统一以引擎运行时任务act_z_business.nodeIdact_z_business.currTaskName为准。不要业务表、缓存、前端页面各维护一份。4.2 业务表只保留业务语义状态业务表状态字段应该回答的是这张单据现在是不是审批中它对业务来说是否生效能不能继续后续业务动作而不是回答现在卡在流程图第几个节点4.3 所有状态更新都走统一服务层不要控制器改一点定时任务改一点SQL 脚本又改一点流程状态同步一定要收口到统一服务层里不然你永远查不清谁把状态改乱了。4.4 事务失败时把外部副作用一起回滚这个项目里有一个我很喜欢的细节如果保存失败会把生成编码重新回填 Redis 队列。这说明团队已经意识到事务回滚不只是数据库回滚还包括编码占用回滚草稿缓存清理外部状态恢复这类意识才是流程系统能不能做稳的关键。五、只做 RBAC 为什么不够很多人一说权限第一反应就是用户角色菜单接口也就是标准 RBAC。但工作流系统里RBAC 只能解决第一层问题你能不能进入某个功能它解决不了你能看哪些数据你在这个节点能编辑哪些字段你能不能看到某个按钮同一个页面里你和别人看到的是不是同一套内容所以在审批系统里权限至少要拆成 4 层。六、这个项目里的权限体系其实是 4 层一起工作的6.1 第一层菜单/功能权限这一层还是经典 RBAC。核心就是sys_rolesys_permissionsys_role_permission它解决的是这个角色有没有这个菜单这个用户能不能访问这个页面/接口这是入口权限。6.2 第二层数据权限这套项目里数据权限不是口头概念而是有完整实现的。能看到几个很关键的点PermissionData(pageComponent ...)SysPermissionDataRuleJeecgDataAutorUtilsQueryGenerator这套链路的意思非常清楚页面或接口声明自己使用哪个菜单组件的数据权限系统查询该菜单对应的数据规则数据规则放进请求上下文QueryGenerator在组装QueryWrapper时自动把规则拼进去这说明它做的不是“页面上藏一个筛选条件”而是真正把数据权限下沉到了查询层。这点非常重要。因为真正可靠的数据权限不是前端不展示而是后端根本查不出来。6.3 第三层页面/按钮权限在低代码页面这一层项目又加了一套jurisdiction配置。比如SysBaseApiImpl.checkUserJurisdictionSnDesignServiceImpl.processButton它会根据当前用户的角色部门去过滤页面按钮、操作按钮、扩展按钮。也就是说同一个页面不是所有人都能看到同样的操作项。这层权限特别适合处理某部门可见别的部门不可见某角色能点“审核通过”别的角色只能看详情某些快捷操作只在特定组织范围内开放6.4 第四层节点字段权限这一层是审批系统最容易被忽略但实际最重要的一层。项目里专门有表sn_flow_node_procdef_promission从实体能看出来它是按formIdflowIdflowNodeIdfieldId来配置字段权限的。而promissionType语义也很清楚0不使用1隐藏2可写3只读这就意味着同一张表单在不同审批节点上可以表现成完全不同的交互形态。这才是真正的“流程驱动表单”。七、RBAC 数据权限 节点权限三者到底怎么分工如果让我用一句最容易记住的话来总结我会这么说RBAC 决定你能不能进来数据权限决定你能看哪些记录节点字段权限决定你能改哪些字段再加上页面按钮权限刚好构成一套比较完整的审批权限体系。我比较反对的一种做法是所有权限都堆到角色里因为角色一旦负责太多事就会开始失控角色越来越多角色语义越来越混乱页面按钮、数据范围、字段可写性全绑在一起最后没人敢改。而这个项目现在的方向至少是把这些维度分开了这是对的。八、如果让我继续优化这套权限体系我会补什么8.1 把流程状态到业务状态的映射做成统一配置现在这套系统已经有流程统一状态和业务侧状态字段但如果继续平台化我会再往前走一步用统一映射表或统一枚举策略明确“哪个流程结果映射成哪个业务状态”这样跨业务线时就不会各写各的。8.2 让节点字段权限和按钮权限共用一套表达式能力现在字段权限、按钮权限、数据权限是分层的这是优点。但如果后面还能再抽一层统一表达式引擎比如都支持角色部门表单字段值当前节点那整个系统的可配置性会更强。8.3 对“流程状态一致性”增加巡检机制比如定时检查act_z_business.procInstId是否存在流程已结束但桥表是否还在处理中业务表business_id/process_id/node_id是否为空这类巡检对长期运行的系统非常有价值。九、总结我现在越来越觉得审批系统做到后面真正拉开差距的不是会不会发起流程而是两件事状态能不能始终对得上权限能不能分层控制好结合这个项目我比较认同的一套思路是流程状态统一放在act_z_business业务状态留在业务表表达业务语义RBAC 管入口数据权限管记录范围页面按钮权限管操作入口节点字段权限管表单交互如果只记一句话我觉得可以记住这句工作流系统里最稳的做法不是把所有状态和权限揉成一团而是让“流程状态”“业务状态”“角色权限”“数据权限”“节点字段权限”各自分层再通过统一服务把它们串起来。