3步配置Flowable-Engine调用活动子流程模块化与父子参数传递实战【免费下载链接】flowable-engineA compact and highly efficient workflow and Business Process Management (BPM) platform for developers, system admins and business users.项目地址: https://gitcode.com/GitHub_Trending/fl/flowable-engine同一段信用检查流程被复制进 8 个 BPMN 文件每次改规则都要改 8 处。这种痛在流程系统里很常见。Flowable-Engine 的调用活动callActivity就是为了解决它它是一个能从主流程里调用另一个独立流程的组件配合 flowable-engine 调用活动配置同一个子流程可以被任意多个主流程复用改一次子流程所有调用方同时生效。本文不逐条念属性而是按真实配置顺序走一遍先把它和嵌入子流程分清再搭一个最小可用示例然后讲父子变量传递的两种方式最后集中在动态调用和容易踩坑的三处。调用活动不是嵌入的子流程先说结论嵌入子流程embedded subprocess画在主流程内部是主流程的一部分调用活动指向一个独立的流程定义子流程有自己完整的生命周期。对比项嵌入子流程调用活动是否独立流程定义否画在主流程内是单独的 process能否独立部署否是运行时按键解析运行时的父子实例同一实例内的 scope两个独立 ProcessInstance历史数据混在主流程历史里子流程有独立历史记录多个主流程复用复制 XML改一处生效所有调用方注意第二条引擎是运行时按 key 去查被调用流程的定义。也就是说子流程可以完全独立部署、独立发版不需要和主流程捆绑。这是模块化的根本前提。模型层面对应 CallActivity.javacalledElement、inheritVariables、inParameters等属性都在这个类上。3步配出第一个调用活动以官方示例中的订单流程为底本仓库里可以直接看modules/flowable-engine/src/test/resources/org/flowable/examples/bpmn/callactivity/。第 1 步写一个独立的子流程就是一个普通流程没有任何特殊要求process idcheckCreditProcess name信用检查 startEvent idtheStart / sequenceFlow sourceReftheStart targetRefverify / userTask idverify name核查信用记录 / sequenceFlow sourceRefverify targetReftheEnd / endEvent idtheEnd / /process第 2 步在主流程里放一个 callActivity。唯一必填的就是calledElement填子流程的 process keyprocess idorderProcess name订单处理 startEvent idtheStart / manualTask idreceiveOrder name接收订单 / sequenceFlow sourceReftheStart targetRefreceiveOrder / sequenceFlow sourceRefreceiveOrder targetRefcreditCall / !-- 唯一必填属性目标流程定义的 key -- callActivity idcreditCall name信用检查 calledElementcheckCreditProcess / sequenceFlow sourceRefcreditCall targetRefship / userTask idship name打包发货 / !-- 省略其余连线与 endEvent -- /process第 3 步两个文件一起部署或分开部署。引擎到达 callActivity 时用子流程的 key 启动一个新的流程实例子流程走完后控制权交还主流程。控制调用的具体版本默认行为是按 key 取最新部署的版本。如果你的主流程和子流程要锁在同一次发布上有两个旋钮flowable:sameDeploymenttrue只从本部署单元里找定义避免主流程跑到别人刚发的子流程版本上flowable:calledElementTypeidcalledElement不再填 key直接填某个流程定义的唯一 id精确锁定版本。另外两个常用的业务属性flowable:businessKey${orderId}给子实例单独指定业务键flowable:inheritBusinessKeytrue则直接继承父实例的业务键。测试用例mainProcessBusinessKey.bpmn20.xml里分别演示了这两种写法。父子流程之间怎么传变量默认情况下父子两个实例的变量是完全隔离的子流程拿不到主流程的变量改完了也不带回去。数据交换只有两条路。方式一整包继承callActivity idcreditCall calledElementcheckCreditProcess flowable:inheritVariablestrue /主流程启动子流程时把全部变量复制一份过去。注意是复制子流程里改的是副本不会自动回写父流程。适合变量少、不想一个个映射的场景变量一多子流程里哪些变量从哪来就没人说得清了排查问题会很费劲。方式二显式 in/out 映射推荐做法。每个传递的变量都要点名source 是数据所在方的变量名target 是对方实例里的变量名callActivity idcreditCall calledElementcheckCreditProcess extensionElements !-- 进主流程 orderId → 子流程 customerOrderId -- flowable:in sourceorderId targetcustomerOrderId / !-- sourceExpression 支持表达式可顺手做转换 -- flowable:in sourceExpression${orderAmount * 1.1} targetcheckedAmount / !-- 出子流程 creditApproved → 主流程 creditResult -- flowable:out sourcecreditApproved targetcreditResult / /extensionElements /callActivity时序上启动子流程时 in 参数拷入子流程结束时 out 参数拷回主流程。模型类里对应的就是getInParameters()和getOutParameters()。维度inheritVariablesflowable:in / out配置成本一行每个变量一对变量可见性全量仅显式声明的回写父流程不支持支持out 参数适用场景变量少、链路简单生产环境主流选择动态调用与多级嵌套calledElement接受 UEL 表达式子流程可以在运行时决定。官方测试用例CallActivity.testCallSimpleSubProcessWithExpressions的写法是把目标流程 key 放进变量callActivity idcreditCall calledElement${subProcessKeyVar} /启动前或任务处理时给subProcessKeyVar赋值即可。比三元表达式更可读也方便在代码里集中管理业务类型 → 流程 key的映射。嵌套深度上测试里有三层 callActivity 链A 调 B、B 调 C的用例能正常跑通每层都是独立实例可以用superProcessInstanceId逐层向上追溯历史表里每层都有独立记录。但建议控制在两层以内。每多一层查询要加processInstanceIdWithChildren、日志要多追一层实例 id排查成本是乘法增长。三个容易踩的坑坑一子流程长时间不回来子流程里挂一个审批任务可能卡好几天。如果主流程需要超时兜底在 callActivity 上挂边界定时器即可callActivity idcreditCall calledElementcheckCreditProcess / boundaryEvent idcreditTimeout attachedToRefcreditCall timerEventDefinition timeDurationPT5M/timeDuration /timerEventDefinition /boundaryEvent sequenceFlow sourceRefcreditTimeout targetRefescalate /中断型边界事件触发时整个子流程实例会被销毁历史里记录删除原因BOUNDARY_EVENT_INTERRUPTING。写业务时想清楚子流程已产生的中间数据不会自动清理需要自己补偿。坑二异步子流程 多实例 锁冲突如果子流程全程是异步服务任务且调用活动配了多实例收尾时会出问题异步锁加在子实例上控制权回到父流程时父实例并没有锁多个子实例并发完成同一个 callActivity就可能互相把对方挤掉抛出乐观锁异常FlowableOptimisticLockingException。解法是给 callActivity 加异步完成标记引擎会基于父实例创建一个异步 job 来完成这个调用活动把多实例的收尾串行化callActivity idcreditCall calledElementcheckCreditProcess flowable:async-completetrue /坑三多租户环境下找不到子流程多租户部署时子流程 key 只在默认租户无租户下定义、而请求来自某个业务租户按 key 解析会找不到。此时加一个回退开关callActivity idcreditCall calledElementcheckCreditProcess flowable:fallbackToDefaultTenanttrue /当前租户查不到定义时回落到默认租户的定义上默认值为 false按需开启。这篇读完你应该带走什么要点一句话定位callActivity 指向独立流程定义运行时按 key 解析子流程可独立部署发版最小配置只写calledElement要锁版本用calledElementTypeid或sameDeployment传参默认隔离生产环境用flowable:in/out显式映射别默认开继承动态化calledElement${...}运行时选流程嵌套建议不超过两层避坑边界定时器会销毁子实例多实例异步收尾要开async-complete多租户注意fallbackToDefaultTenant下一步建议先跑一遍modules/flowable-engine/src/test/java/org/flowable/engine/test/bpmn/callactivity/CallActivityAdvancedTest.java里面把父子实例查询、entity link 关系、边界事件销毁行为都断言得很细比任何文档都快。本文采用场景→接线→数据→避坑的实操叙事框架与参考素材的概念→配置→参数→高级特性平铺结构不同高级内容统一后置到坑点中按问题驱动展开。【免费下载链接】flowable-engineA compact and highly efficient workflow and Business Process Management (BPM) platform for developers, system admins and business users.项目地址: https://gitcode.com/GitHub_Trending/fl/flowable-engine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考