系列文10突破Activiti限制政务工作流任意流转支持跳退回退非科班野生程序员深耕政务信息化20年这套自研Java Web框架支撑过省级新农保、全国首例跨省医保结算等核心民生系统18年稳定运行至今。本系列拆解10个核心架构决策全是政务场景踩坑后的实用解法不求优雅但求落地也欢迎懂行大佬轻拍指正。最后感谢豆包、智谱、OpenCode决策是我做的代码是我搓的文字是他们总结的。背景标准的 Activiti 工作流只能按 BPMN 定义好的路径走线。但政务系统的实际需求是科长要能直接跳到处长、退回到科员、转办到其他科室。Activiti 原生不支持这种任意跳。如果每次新增一个跳转需求都要去改 BPMN 定义那流程图会变成蜘蛛网而且改了流程定义会影响所有正在运行的实例。这个功能我啃了将近2个月几乎每天到晚上9点。翻Activiti源码、试方案、炸了再来。最终找到了一个洞——ActivityImpl的连线可以在运行时动态修改。我的方案在运行时动态修改流程定义的连线跳转到目标节点完成后恢复原状。任意跳转的核心流程正常流程 科员 ──→ 科长 ──→ 处长 ↑ 任意跳转 科员 ──→ 科长 ──×──→ 处长 临时建一条线直通处长 │ ↑ └──临时连线─────┘ 完成后 科员 ──→ 科长 ──→ 处长 恢复原状其他实例不受影响turnTransition()——核心方法privatevoidturnTransition(StringtaskId,StringactivityId,MapString,Objectvariables)throwsException{// 1. 获取当前节点ActivityImplcurrActivityfindActivitiImpl(taskId,null);// 2. 保存当前所有出线然后清空ListPvmTransitionoriPvmTransitionListclearTransition(currActivity);// 3. 创建一条临时出线指向目标节点TransitionImplnewTransitioncurrActivity.createOutgoingTransition();ActivityImplpointActivityfindActivitiImpl(taskId,activityId);newTransition.setDestination(pointActivity);// 4. complete——任务沿临时线走到目标节点taskService.complete(taskId,variables);// 5. 删除临时线pointActivity.getIncomingTransitions().remove(newTransition);// 6. 恢复原来的出线restoreTransition(currActivity,oriPvmTransitionList);}6步操作最关键的 insight 是修改的是内存中的ActivityImpl对象不会持久化到数据库不影响其他流程实例。清空和恢复连线的代码很简单——保存、清空、恢复privateListPvmTransitionclearTransition(ActivityImplactivityImpl){ListPvmTransitionoriListnewArrayListPvmTransition();ListPvmTransitionlistactivityImpl.getOutgoingTransitions();for(PvmTransitiont:list){oriList.add(t);}list.clear();returnoriList;}privatevoidrestoreTransition(ActivityImplactivityImpl,ListPvmTransitionoriList){ListPvmTransitionlistactivityImpl.getOutgoingTransitions();list.clear();for(PvmTransitiont:oriList){list.add(t);}}commitProcess()——统一提交入口privatevoidcommitProcess(StringtaskId,MapString,Objectvariables,StringactivityId)throwsException{if(variablesnull){variablesnewHashMapString,Object();}variables.put(nextid,activityId);if(StrTool.isNull(activityId)||.equals(activityId)){// 没指定目标走标准下一步taskService.complete(taskId,variables);}elseif(isNext(taskId,activityId)){// 目标是标准路径的下一个节点直接completetaskService.complete(taskId,variables);}else{// 目标不是标准路径需要动态跳转try{turnTransition(taskId,activityId,variables);}finally{// 清除缓存防止动态修改残留影响后续操作flowUtil.getConf().getProcessDefinitionCache().clear();}}}三个分支没指定目标 → 标准下一步目标是标准路径的下一个节点 → 直接 complete目标不是标准路径 →turnTransition()动态跳转finally里清缓存是踩坑后加的。一开始没清跳转完之后偶尔出现流程定义被污染的情况——其他实例莫名其妙走错了路径。排查了很久才发现是 Activiti 内部缓存了修改后的ActivityImpl对象。完整审批流程——passProcess()passProcess()是前端调用的主要入口做了这些事前端请求 → 拾取任务 → 前置处理器 → 保存表单数据 → 计算下一步处理人 → 提交流程 → 指定下一步处理人 → 后置处理器 → 记录日志核心代码节选省略了参数解析和表单保存的细节// 1. 拾取任务this.claim(taskid,userid);// 2. 执行前置处理器数据校验、特殊业务处理task_interceptor intercptorobjthis.getinterceptor(taskid);if(beforeid!null){before beforeobj(before)BeanFactory.getBean(beforeid);beforeobj.beforeTrans(center);}// 3. 保存业务数据CommonSQLcontrolsqlcl(CommonSQLcontrol)BeanFactory.getBean(CommonSQL);sqlcl.CommonSaveofbyseach(dc,request,response);// 4. 计算下一步处理人详见下方 getdusersDataCenterdcuserthis.getdusers(center,request,response);// 5. 提交流程内部判断走标准路径还是动态跳转this.commitProcess(taskid,variables,nextid);// 6. 指定下一步处理人HashMapString,Stringtaskthis.currTask(insid);taskService.setAssignee(task.get(taskid),nextUserId);// 7. 执行后置处理器通知、数据同步after afterobj(after)BeanFactory.getBean(afterid);afterobj.afterTrans(center);前置/后置处理器是配置在数据库里的——每个任务节点可以配置不同的处理器用逗号分隔。处理器本身也是框架的bean通过BeanFactory.getBean()获取。回退流程——back()回退比提交多一步标记历史。// back() 核心逻辑省略表单保存细节HashMapString,StringmapgetPreDefinitionKey(taskId);// 找上一步StringactivityIdmap.get(preTaskDefid);StringapplyUserIdmap.get(preUserid);backProcess(taskId,activityId,variables);// 回退后把任务分配给原处理人HashMapString,StringtaskscurrTask(insid);claim(tasks.get(taskid),applyUserId);getPreDefinitionKey()通过当前节点的入线找到上一个节点再从历史任务中找到上一步的处理人。backProcess()——处理并行任务回退privatevoidbackProcess(StringtaskId,StringactivityId,MapString,Objectvariables)throwsException{// 找到同一节点的所有并行任务会签等场景ListTasktaskListfindTaskListByKey(findProcessInstanceByTaskId(taskId).getId(),findTaskById(taskId).getTaskDefinitionKey());for(Tasktask:taskList){commitProcess(task.getId(),variables,activityId);retracttasks(task.getId(),activityId);}}会签场景下同一个节点可能有多个并行任务。回退时必须全部回退否则会出现一半人回退了、一半人还在审批的混乱状态。retracttasks()——标记历史为retractprivatevoidretracttasks(StringtaskId,StringactivityId){// 1. 当前任务标记为retract((TaskServiceImpl)this.taskService).getCommandExecutor().execute(newUpdateHiTaskReasonCommand(taskId,retract));HistoricTaskInstancetaskthis.historyService.createHistoricTaskInstanceQuery().taskId(taskId).singleResult();// 2. 目标节点已完成的任务也标记为retractListHistoricTaskInstancelistthis.historyService.createHistoricTaskInstanceQuery().taskDefinitionKey(activityId).processInstanceId(task.getProcessInstanceId()).taskDeleteReason(completed).finished().list();for(HistoricTaskInstanceobj:list){((TaskServiceImpl)this.taskService).getCommandExecutor().execute(newUpdateHiTaskReasonCommand(obj.getId(),retract));}}两步标记当前任务标记撤回目标节点原来的已完成任务也标记撤回。这样前端展示审批历史时用户能看到这个环节被回退过。UpdateHiTaskReasonCommand——不改Activiti源码修改历史publicclassUpdateHiTaskReasonCommandimplementsCommandBoolean{privateStringtaksid;privateStringdeletereason;publicUpdateHiTaskReasonCommand(Stringtaskid,Stringdeletereason){this.deletereasondeletereason;this.taksidtaskid;}OverridepublicBooleanexecute(CommandContextarg0){HistoricTaskInstanceEntityentityarg0.getDbSqlSession().selectById(HistoricTaskInstanceEntity.class,taksid);if(entity!null){entity.markEnded(deletereason);}returntrue;}}Activiti 的Command接口是扩展点——不需要改 Activiti 源码写一个自定义命令就能直接操作历史表。markEnded()是 Activiti 自带的方法只是用它改了deleteReason字段。注意变量名taksid——源码里就是这么拼的task 少了个 t跑了十几年也没问题。获取下一步参与者——getdusers()这是整个工作流中最贴近业务的方法。所有规则不是写死在代码里的是配置在数据库中的。流程设计人员在后台配置每个环节的参与者规则系统运行时动态读取。方法签名和核心结构publicDataCentergetdusers(DataCentercenter,HttpServletRequestrequest,HttpServletResponseresponse)throwsutilException{StringtaskidString.valueOf(center.getParameters(taskid));StringnextidString.valueOf(center.getParameters(nextid));StringuseridString.valueOf(center.getParameters(userid));StringapplyUseridString.valueOf(center.getParameters(applyuserid));// 从数据库读取这个环节配置的参与者规则HashMapString,StringmapgetTask(taskid);Stringpidmap.get(pid);ListHashMapString,StringlistgetUsers(pid,nextid);// 遍历规则根据 type limitType 解析出具体的人for(HashMapString,Stringrow:list){if(ROLE.equals(row.get(type))){// 角色 地区/部门限定StringlimitTyperow.get(limitType);if(2001.equals(limitType)){// 参保人所在地区从表单数据取地区编码Stringaab301center.getStore(bd).getRowset().getrow(0).getItemStringValue(aab301);Stringroleidrow.get(id)#aab301;// ... 添加到结果集}elseif(101.equals(limitType)){// 特定部门从配置的部门列表中查角色部门的用户for(Stringdeptcode:deptcodes){UserparamnewUser();param.setDept_id(deptcode);param.setRole_id(row.get(id));ListUserusers(ListUser)DBUtil.getDao(userMapper.class,selectuserbyroleanddept,param);// ... 添加到结果集}}// ... 其他 limitType 类似}elseif(ORG.equals(row.get(type))){// 按组织机构找人}elseif(USER.equals(row.get(type))){// 指定具体用户}elseif(OLD.equals(row.get(type))){// 原路回退从历史任务找上一个处理人ListHistoricTaskInstancetlisthistoryService.createHistoricTaskInstanceQuery().processInstanceId(map.get(insid)).taskDefinitionKey(row.get(id)).orderByHistoricTaskInstanceStartTime().asc().list();// 取第一个处理人}}// 最后单机构→平铺用户列表多机构→机构→用户树形结构returndc;}完整的参与者解析规则四种参与者类型typetype含义怎么找人ROLE角色根据limitType限定地区/部门拼接角色ID#地区编码作为查询条件ORG组织机构按部门ID查该部门下所有用户USER指定用户直接按用户ID查OLD原路回退从历史任务找到上一次在这个环节处理的人角色限定条件limitTypetypeROLE 时生效limitType含义数据来源2001参保人所在地区表单字段aab3012002当前经办人所在地区AppContext中当前用户2003申请人所在地区数据库查申请人信息2004转入地所在地区表单字段aab301_22005转出地所在地区表单字段aab301_12006参保人所在乡镇查父级机构101特定部门配置中的部门列表1001当前用户顶级部门递归查组织架构1002当前用户父部门当前用户所在部门1003当前用户顶级部门的下一级两级查询其他只用角色不限地区全库查这套规则引擎撑住了两套完全不同的业务体系某海关总关→处级→科级垂直管理3层1001/1003精确定位到某个处的所有科长某省居民养老保险省→市→县→乡镇→村5级行政层级2001/2006根据参保人所在地自动匹配到乡镇经办人两种组织架构、两种审批逻辑同一个getdusers()通吃。新增一个限定条件只需要在数据库加配置不改代码。为什么这样做turnTransition利用 Activiti 的标准 API不需要改 Activiti 源码没有修改 BPMN XML 的部署文件不影响同一流程定义下的其他实例直接操作内存中的ActivityImpl对象只影响当前操作决策原则不能改变框架时就找到一个洞绕过去。这和2007年用 PB 的 DataWindow.update 事件拦截 SQL 是同一个思路——框架不直接支持的功能通过理解框架的内部机制找到一个切入点来实现。ActivityImpl的连线可以在运行时动态修改这就是 Activiti 留下的那个洞。找到这个洞花了2个月。试过改BPMN定义影响其他实例、试过流程变量控制网关流程图变蜘蛛网、最后翻到ActivityImpl的createOutgoingTransition()方法才跑通。跑通之后又踩了缓存污染的坑加了finally里的clear()才稳定。你在项目中用过 Activiti 吗有没有遇到过需要自由跳转的场景你是怎么解决的欢迎评论区讨论。系列导航上一篇[系列文9政务报表自由Excel模板驱动业务人员改格式开发零参与]- 回到总纲[Java Web自研框架18年架构决策复盘系列文]作者许彰午| 非科班野生程序员深耕政务信息化20年标签#Java #Activiti #工作流 #任意跳转 #政务审批 #流程引擎 #BPMN #政务信息化 #技术复盘