企业官网建设流程全解析

前阵子帮业务方梳理一个供应商准入流程，刚开始图省事，把所有审批节点一条线画在主流程上，结果不到两周，流程图就被拉成了十多个节点的长串。业务方提需求时只能说"第三段那里"，谁也说不清"第三段"到底从哪开始到哪结束。后来把流程改成三个阶段块：资质审核、现场考察、报告归档，整体图立刻清爽了。这里用的就是 Activiti 工作流引擎里的嵌入式子流程。网络上有不少文章把它写成"Activity子流程"，其实严格说引擎叫 Activiti，但大家习惯这么叫也没什么问题。

嵌入式子流程（Embedded Subprocess）是 BPMN 2.0 里最常用的一类子流程，它的特点就一个词：内嵌。整个子流程直接写在主流程定义文件里，不需要单独部署一个流程定义，但它可以把一组任务、网关、事件折叠成一个圆角矩形块。这篇文章我会把嵌入式子流程是什么、在 Activiti 里怎么建模、执行原理、变量作用域坑、边界事件用法、多实例扩展一次讲清楚。适合正在学 Activiti 建模，以及纠结"流程里的哪些节点该拆成子流程、什么情况下用嵌入式、什么情况下用调用子流程"的读者。

1. 嵌入式子流程的定位：先分清"内嵌展开"和"独立引用"

1.1 嵌入式子流程在BPMN规范里是什么

先看BPMN 2.0的标准定义。嵌入式子流程在XML里就是一个<subProcess>元素，它直接嵌套在<process>元素里面。既然是"内嵌"，它就没有自己独立的流程定义ID，不能被单独启动，也不能被别人通过calledElement引用。你可以把它理解成主流程定义内部的一个"局部流程片段"，只是这个片段在画图时可以被折叠成一个小方块。

一个最简单的嵌入式子流程在XML里长这样：

<process id="mainProcess" name="主流程" isExecutable="true"> <startEvent id="start" name="开始" /> <sequenceFlow id="flow1" sourceRef="start" targetRef="subProcess" /> <subProcess id="subProcess" name="内嵌处理段"> <startEvent id="subStart" name="子流程开始" /> <sequenceFlow id="subFlow1" sourceRef="subStart" targetRef="task1" /> <userTask id="task1" name="子流程里的任务" activiti:assignee="zhangsan" /> <sequenceFlow id="subFlow2" sourceRef="task1" targetRef="subEnd" /> <endEvent id="subEnd" name="子流程结束" /> </subProcess> <sequenceFlow id="flow2" sourceRef="subProcess" targetRef="end" /> <endEvent id="end" name="结束" /> </process>

从这段XML里可以看到几个关键信息：

• 嵌入式子流程内部有自己的开始事件和结束事件。
• 子流程内部可以放用户任务、服务任务、网关等几乎所有普通节点。
• 主流程通过普通顺序流进入子流程，子流程走完后，再通过普通顺序流继续主流程后面的节点。

我在实际项目里习惯把它类比成 Word 文档的折叠大纲。收起时只是一个标题块，展开后里面有完整的章节结构。这么做最大的好处是：流程图的主干逻辑不被细节淹没，而每一个子流程块内部又保留着完整的业务规则。

1.2 它与调用子流程的本质差异

很多人刚接触子流程时，最容易把嵌入式子流程和调用子流程（Call Activity）搞混。这两者在BPMN图标上确实长得很像，都是圆角矩形，只是标记细节略有差异，但在Activiti中的行为差别非常大。我整理了一张对比表：

选择逻辑其实很直接：这段活动如果只属于当前流程，将来不可能被别的流程单独拿来用，就优先考虑嵌入式子流程；如果它本身就是一个可以独立运行、独立测试、甚至独立发版的流程，比如通用的审批、通用的会签、通用的整改流程，那就应该拆成调用子流程。

我见过不少项目在这个选择上本末倒置——把一些明显应该独立复用的公共流程硬写成嵌入式子流程，结果每个主流程里都复制一份，后面需求改动时要一个一个改，痛苦程度可想而知。反过来也有，本来只是主流程里的一个内部阶段，却为了"看起来规范"单独建了一个流程定义，结果变量传递写了一大堆activiti:in映射，反而把简单问题复杂化。

2. Activiti里嵌入式子流程落地：以供应商准入流程为例

2.1 业务背景与拆子流程的决策

纸上谈兵没有意思，我拿一个实际改造过的流程来走一遍。业务背景是这样的：供应商要申请进入企业的准入名单，整个流程分成三大段：

1. 资质审核段：系统自动校验营业执照、相关资质证书是否齐全，再由法务人员人工复核，复核通过进入下一段，不通过直接退回。
2. 现场考察段：派单给考察人员，考察人上传考察记录，主管确认记录。
3. 报告归档段：根据前面的结果生成准入报告，归档，结束。

当时业务方的痛点有两个：第一，流程图太长，滚轮要滚好几屏；第二，资质审核内部其实有"自动校验 + 人工复核 + 通过与否判断"三个小步骤，业务方希望把这三个步骤当作一个整体来讨论和变更。正好，这三个阶段各自都不太可能被其他流程复用，所以最终选择用嵌入式子流程把它们内嵌进主流程。

拆子流程的决策点我总结过，满足下面任意一条就适合拆：

• 一段活动的内部节点多于3个，且对外只表现为"进入"和"离开"两个状态。
• 业务方经常把这段活动当作一个整体来提需求。
• 这段活动内部可能出现整体性的失败或超时，需要主流程统一收口。
• 希望通过折叠来降低主流程图的阅读复杂度。

2.2 完整BPMN XML建模

下面是我当时用的核心XML结构，缩略掉不影响理解的部分：

<process id="supplierAdmission" name="供应商准入流程" isExecutable="true"> <startEvent id="start" /> <sequenceFlow id="flow_start_to_qual" sourceRef="start" targetRef="qualSubProcess" /> <!-- 资质审核嵌入式子流程 --> <subProcess id="qualSubProcess" name="资质审核"> <startEvent id="qualStart" /> <sequenceFlow id="qualFlow1" sourceRef="qualStart" targetRef="autoCheck" /> <serviceTask id="autoCheck" name="自动校验证照" activiti:class="org.example.service.CertificateAutoCheckService" /> <sequenceFlow id="qualFlow2" sourceRef="autoCheck" targetRef="manualReview" /> <userTask id="manualReview" name="法务人工复核" activiti:assignee="legalReviewer" /> <sequenceFlow id="qualFlow3" sourceRef="manualReview" targetRef="qualGateway" /> <exclusiveGateway id="qualGateway" name="复核判断" /> <sequenceFlow id="qualFlow4" sourceRef="qualGateway" targetRef="qualEnd"> <conditionExpression xsi:type="tFormalExpression"><![CDATA[${pass == true}]]></conditionExpression> </sequenceFlow> <sequenceFlow id="qualFlowFail" sourceRef="qualGateway" targetRef="qualFailEnd"> <conditionExpression xsi:type="tFormalExpression"><![CDATA[${pass == false}]]></conditionExpression> </sequenceFlow> <endEvent id="qualEnd" /> <endEvent id="qualFailEnd" /> </subProcess> <sequenceFlow id="flow_qual_to_site" sourceRef="qualSubProcess" targetRef="siteSubProcess" /> <!-- 现场考察嵌入式子流程 --> <subProcess id="siteSubProcess" name="现场考察"> <startEvent id="siteStart" /> <sequenceFlow id="siteFlow1" sourceRef="siteStart" targetRef="dispatchTask" /> <userTask id="dispatchTask" name="派单" activiti:assignee="dispatcher" /> <sequenceFlow id="siteFlow2" sourceRef="dispatchTask" targetRef="recordTask" /> <userTask id="recordTask" name="上传考察记录" activiti:assignee="inspector" /> <sequenceFlow id="siteFlow3" sourceRef="recordTask" targetRef="confirmTask" /> <userTask id="confirmTask" name="主管确认" activiti:assignee="supervisor" /> <sequenceFlow id="siteFlow4" sourceRef="confirmTask" targetRef="siteEnd" /> <endEvent id="siteEnd" /> </subProcess> <sequenceFlow id="flow_site_to_report" sourceRef="siteSubProcess" targetRef="reportSubProcess" /> <!-- 报告归档嵌入式子流程 --> <subProcess id="reportSubProcess" name="报告归档"> <startEvent id="reportStart" /> <sequenceFlow id="reportFlow1" sourceRef="reportStart" targetRef="makeReport" /> <serviceTask id="makeReport" name="生成准入报告" activiti:class="org.example.service.ReportGenerationService" /> <sequenceFlow id="reportFlow2" sourceRef="makeReport" targetRef="archiveTask" /> <userTask id="archiveTask" name="归档确认" activiti:assignee="archiver" /> <sequenceFlow id="reportFlow3" sourceRef="archiveTask" targetRef="reportEnd" /> <endEvent id="reportEnd" /> </subProcess> <sequenceFlow id="flow_report_to_end" sourceRef="reportSubProcess" targetRef="end" /> <endEvent id="end" /> </process>

建模时有几个细节值得注意：

• 每个嵌入式子流程内部我都显式画了开始事件和结束事件。有人觉得可以偷懒省略，但实际运行时 Activi ti 进入子流程需要一个明确的入口执行上下文，没有开始事件的子流程在部分版本上会出现执行树不完整的问题，调试时很头疼。
• 序列流的方向一定要从子流程的边界指向下一个节点的边界，而不是试图"穿过"子流程内部。这是新手常犯的错误，会导致引擎解析时认为连线非法。
• 在画图工具里操作时，直接用左侧面板拖一个 Subprocess 然后双击进入内部编辑，比手写XML安全一点。但手写XML的好处是能精确控制元素顺序和表达式，所以我个人更推荐先手写关键片段，再导入设计器检查。

2.3 部署、启动与执行树观察

部署和启动的代码其实和普通流程没什么两样，因为嵌入式子流程并没有改变流程定义ID，它只是同一个流程定义内部的一种结构。

@Autowired private RepositoryService repositoryService; @Autowired private RuntimeService runtimeService; public void deployAndStart() { Deployment deployment = repositoryService.createDeployment() .addClasspathResource("processes/supplierAdmission.bpmn20.xml") .name("供应商准入流程定义") .deploy(); System.out.println("部署ID：" + deployment.getId()); ProcessInstance processInstance = runtimeService.startProcessInstanceByKey("supplierAdmission"); System.out.println("流程实例ID：" + processInstance.getId()); }

启动后，可以查一下ACT_RU_EXECUTION表，观察执行树的父子结构：

SELECT ID_, PROC_INST_ID_, PARENT_ID_, ACT_ID_, IS_ACTIVE_, IS_SCOPE_ FROM ACT_RU_EXECUTION WHERE PROC_INST_ID_ = #{processInstanceId} ORDER BY ID_;

当流程走到"资质审核"子流程内部时，ACT_RU_EXECUTION里会出现不止一条执行记录：最顶层是流程实例对应的根执行，PARENT_ID_为空或指向根节点，然后是进入子流程时创建的子执行记录，PARENT_ID_指向根执行。子执行上会带上子流程内部的当前活动ID，比如autoCheck或manualReview。

这就是嵌入式子流程在Activi里的核心执行机制：它并不会创建新的流程实例，而是在当前流程实例下面挂一个子执行（Child Execution）。子流程结束时，这个子执行会被销毁，流程实例的主执行继续往下走。理解这一层父子执行关系，是后面理解变量作用域的关键。

3. 执行树与变量作用域：嵌入子流程最容易踩的两个坑

3.1 执行实例的父子关系如何形成

前面已经看到，Activi ti 引擎在执行时维护的是一棵"执行树"：流程实例是一棵树的根，流程实例走到分支网关、并行网关、子流程等位置时，会派生出一系列子执行。嵌入式子流程进入时创建的儿子执行，本质上相当于主流程执行下的一个"栈帧"。

这一步很重要，因为很多人在ACT_RU_EXECUTION里看到多条记录就慌了，以为流程实例被重复创建了。其实这是正常的，只要PROC_INST_ID_相同，就说明它们是同一个流程实例的不同执行分支。子执行是临时的，离开子流程就被清理，所以千万不要在业务代码里长期引用某个子执行的ID。

3.2 坑一：子流程内部设置的变量，主流程后继节点读不到

这是嵌入式子流程在 Activiti 里最经典的坑，我踩过一次之后很长一段时间都在反复向同事解释。

假设在"资质审核"子流程里，有一个服务任务自动校验后设置了变量：

public void execute(DelegateExecution execution) { boolean autoPass = doCheck(); execution.setVariable("certCheckPassed", autoPass); }

如果子流程内部后面的节点读取certCheckPassed，一切正常。但如果子流程结束后，主流程后面的"现场考察"阶段想读取这个变量，你可能在调试时会发现它是null。

原因就在执行树和变量作用域上。execution.setVariable("certCheckPassed", autoPass)在嵌入式子流程内部调用时，变量默认保存在当前子执行实例上。子流程走到结束事件，这个子执行被销毁，它上面保存的局部变量也跟着消失了。主流程继续推进时，主执行实例上从来就没有这个变量，自然读出来是空。

别指望引擎"自动帮你升级成全局变量"，在 Activi ti 的嵌入式子流程里没有这个升级动作。这也是它和调用子流程的差异之一：调用子流程至少有activiti:out这种显式的输出参数映射，而嵌入式子流程我目前没有见到原生版本提供稳定的、统一的"子流程变量自动导出"机制。

我目前在实践中比较稳妥的解决办法有三种：

• 在子流程内部通过流程实例上下文写入：execution.getProcessInstance().setVariable("certCheckPassed", autoPass)。这样变量直接挂在根执行上，子执行销毁也不受影响。
• 在子流程结束事件前，加一个专门的"结果回传"服务任务，把需要暴露给主流程的变量显式写到根执行上。
• 如果是 Camunda 引擎，可以在模型器里配置输入输出映射，但原生 Activiti 里我一般不用这个方案，因为它对版本和配置要求较高，而且换了引擎团队容易踩坑。

这里有一个经验：凡是子流程结束后还需要被主流程使用的数据，不要在子流程内部用默认作用域去写，而是应该在设计阶段就明确"这个变量是要回传到主流程的"，然后用第一种或第二种方式写入根执行。宁可多写一行代码，也不要等到运行环境上报空指针时再排查。

3.3 坑二：定时器边界事件在异常退出时可能残留

嵌入式子流程常配合边界事件使用，其中一种就是定时器边界事件。比如"现场考察"子流程最多跑5天，超时自动升级给上级主管。正常情况下，子流程正常结束后，Activi ti 会清理掉这个边界事件对应的定时器 Job。

但这个清理动作是在"正常离开子流程"的前提下才可靠的。如果子流程内部某个环节走了非标准的分支，或者你在代码里直接通过runtimeService.createChangeActivityStateBuilder()做了流程实例跳转，把执行从子流程内部强行迁移到子流程外部，就有可能出现定时器 Job 残留在ACT_RU_JOB表里的情况。残留的定时器到点之后仍然会触发，造成幽灵提醒。

排查方式是在测试环境查看定时器任务：

SELECT ID_, DUEDATE_, EXECUTION_ID_, PROC_INST_ID_, RETRIES_ FROM ACT_RU_JOB WHERE PROC_INST_ID_ = #{processInstanceId} ORDER BY DUEDATE_;

如果发现流程已经离开子流程但 Job 还在，就需要手动补一条清理逻辑。我在项目里处理这类问题的做法是，在流程跳转工具类里统一判断：如果跳转的源节点处于某个子流程内，先删掉该子流程上挂的边界定时器 Job，再执行跳转。这个防御逻辑虽然看着笨，但能避免很多线上问题。

4. 错误处理与超时控制：把边界事件挂在嵌入式子流程上

4.1 错误边界事件实现整组活动的失败收口

嵌入式子流程一个很大的优势，是可以作为错误边界事件（Error Boundary Event）的附着点。业务含义是：把整个子流程内部的所有活动看作一个整体，只要其中任何节点抛出了指定错误，主流程就统一进入失败处理分支，而不是在主流程里给每个任务单独挂错误监听。

回到供应商准入案例。资质审核子流程内部，自动校验不通过时，可以走向一个"校验失败"的错误结束事件：

<endEvent id="qualFailWithError"> <errorEventDefinition errorRef="certCheckError" /> </endEvent>

然后在主流程层，给整个资质审核子流程挂一个错误边界事件：

<boundaryEvent id="qualErrorBoundary" attachedToRef="qualSubProcess"> <errorEventDefinition errorRef="certCheckError" /> </boundaryEvent>

再把这个边界事件的出口引到主流程的"通知供应商退回"分支。

用这种结构的好处是：业务方只关心"资质审核是否整段通过"，而不关心内部究竟是自动校验失败还是法务复核不通过。子流程内部怎么改，只要最终错误码一致，主流程的失败处理分支就不用动。这在需求频繁变化的阶段特别省事。

需要留意的点：错误边界事件不能捕获子流程内部所有异常，它只对 BPMN 错误事件生效。如果子流程里某个 Java 服务任务直接抛了运行时异常，那不会自动转换成 BPMN 错误，流程会直接进入错误结束状态。正确做法是服务任务内部捕获业务异常后，通过throwError方法抛出指定错误码，或走向错误结束事件。

4.2 定时器边界事件实现整体超时

定时器边界事件挂在嵌入式子流程上的作用更直观——给整段活动设定一个最大耗时，超时触发分支逻辑。

<boundaryEvent id="siteTimerBoundary" attachedToRef="siteSubProcess" cancelActivity="true"> <timerEventDefinition> <timeDuration>PT5D</timeDuration> </timerEventDefinition> </boundaryEvent>

这段XML表示：进入现场考察子流程开始计时，5天之内如果子流程没有正常结束，就中断当前子流程路径，走边界事件后面的升级分支。

我一般把它用在类似"考察人员一直未提交记录""主管一直未确认"这类需要整体兜底的场景。注意它和单个任务上挂定时器边界事件的区别：单任务超时只针对那一个任务，而挂在嵌入式子流程上则覆盖子流程内所有任务的执行周期。如果你要用单任务超时，就把边界事件挂到具体的用户任务上；如果你要整个阶段超时，就挂到子流程边界。

cancelActivity="true"这个属性也很关键。为true表示触发后取消当前子流程的执行；为false则不中断，超时后并行走出一条提醒分支，子流程内部还可以继续做。以供应商考察为例，如果超时后只是发个提醒，考察人员仍需要继续完成任务，就用false；如果超时后直接取消本次考察，就走true。

4.3 嵌入式子流程不是事务子流程

这里我必须专门提醒一下：BPMN 里还有一种叫"事务子流程"（Transaction Subprocess）的东西，图标和嵌入式子流程几乎一样，只是边界不同。事务子流程语义上要求把整个子流程当成一个原子事务，要么全成功，要么全部回滚。

Activi ti 引擎对事务子流程的支持一直不太完整。官方文档里也明确说过，它并不保证完整的事务语义，很多取消边界事件、补偿行为在引擎里并没有实现到位。所以我在实际项目里几乎不用事务子流程，遇到"要么全部成功要么全部失败"的需求，优先考虑在应用层事务里解决，或者明确接受最终一致性。

嵌入式子流程能做的只是"流程片段的折叠"和"事件边界收口"，它不可能帮你回滚已经执行过的业务操作。比如在子流程里给供应商发了邮件、更新了数据库，后面发现失败想回滚，流程引擎不可能撤销这些外部副作用。这一点想清楚，就不会对嵌入式子流程抱有不切实际的期望。

5. 多实例与选型总结：嵌入式子流程该怎么用、什么时候拆出去

5.1 多实例嵌入式子流程的建模与注意点

有些场景需要在主流程内同时处理多条独立的数据，比如现场考察阶段要同时对多个供应商地址分别考察，这时可以用多实例嵌入式子流程，让同一个子流程定义并行跑多个实例。

<subProcess id="siteMultiSubProcess" name="多地址考察"> <multiInstanceLoopCharacteristics isSequential="false" activiti:collection="${addressList}" activiti:elementVariable="address"> <completionCondition>${nrOfCompletedInstances >= nrOfInstances}</completionCondition> </multiInstanceLoopCharacteristics> <startEvent id="siteMultiStart" /> <!-- 内部用 address 变量处理每个地址 --> </subProcess>

里面有两个关键地方：

• activiti:collection指向主流程里的集合变量，比如多个考察地址。
• activiti:elementVariable指定每次循环从集合里取出的元素存在哪个变量名里。

多实例子流程在运行时会派生出多个子执行，每个子执行持有各自的局部变量。不同子执行之间读不到彼此的局部变量，这是符合预期的。但如果多个实例共享同一份结果数据，或者最后需要汇总，就要显式把结果写到根执行上，或者等所有实例结束后再做汇总。

我自己的一个教训是：多实例子流程如果内部还挂错误边界事件，错误语义会变得复杂——某个实例抛错时，边界事件触发的是整个子流程的错误处理，而不只是失败实例的处理。后来我在项目里约定：多实例子流程内部不在子流程边界上挂错误处理，而是每个实例内部自行捕获并记录失败原因，最后通过 completionCondition 判断是否继续。

5.2 选择嵌入式子流程还是调用子流程的具体清单

我在方案评审时一般直接给一份决策清单，团队照着勾一遍基本就能定：

1. 这段活动是否会被多个不同流程引用？会，选调用子流程；不会，选嵌入式子流程。
2. 是否需要给这段活动单独做版本管理、独立部署？需要，选调用子流程。
3. 是否需要从外部单独发起这段活动的流程实例？需要，选调用子流程。
4. 主流程图上是否更希望这段活动折叠成一个块？是，选嵌入式子流程。
5. 主流程和这段活动之间的变量共享是强绑定还是弱绑定？弱绑定、需要显式传入传出，选调用子流程；强绑定、本身就是主流程的一部分，选嵌入式子流程。
6. 这段活动内部是否有整体性的超时/失败收口需求？两者都可实现，但嵌入式子流程因为直接挂在主流程执行树上，实现起来通常更直观。

另外提醒一下版本差异。Activi ti 5.x、6.x、7.x 对嵌入式子流程的基本支持是一致的，但 Flowable、Camunda 这些同源引擎在变量映射、边界事件细节上会有细微差异。如果你在多个引擎之间迁移流程定义，不能想当然认为"XML一样就行为一样"，至少要在测试环境里把子流程内变量传递和边界事件触发两个场景重测一遍。

5.3 一些习惯与建议

最后说几条我实际干项目攒下来的习惯。

第一，我通常要求一个嵌入式子流程内部不超过5个节点。超过5个，说明这个子流程本身规模已经不小，应该评估是不是拆成调用子流程，或者继续细分成多个更小的嵌入段。这不是硬性规定，而是经验值：超过这个数，折叠的收益会被内部复杂度抵消。

第二，设计流程图时就要按业务阶段划分子流程，不要等线条已经乱成一团时再"补救"。嵌入式子流程最适合在建模初期介入，这时候业务方还能清楚描述"哪些动作属于同一段"，等到流程已经上线，再拆就要处理存量流程实例的迁移，成本高很多。

第三，给嵌入式子流程起名要"对外命名"，不要"对内命名"。比如叫"资质审核"，不要叫"子流程A"。因为流程图折叠后，业务方看到的就是这个名称，它直接决定沟通效率。一个好的子流程名称应该让人一看就知道这段是干什么的、什么时候进入、什么时候离开。

第四，调试时先用单个嵌入式子流程跑通，再叠加边界事件和多实例。不要一次性把定时器边界事件、错误边界事件、多实例全部加上，否则一旦执行树不符合预期，排查变量来源和事件触发时机都非常痛苦。我一般是先确认子流程内部节点能正常走完，再测边界事件，最后再套多实例。

这个内容以后还可以继续扩展：比如把嵌入式子流程和事件子流程（Event Subprocess）配合使用，做一个全局的异常监听；或者在嵌入式子流程上同时挂多个定时器边界事件做多级超时升级。实际项目里这些组合能解决不少真实问题，但核心还是先把嵌入式子流程自身的行为边界和使用习惯吃透。我自己改造完供应商准入流程之后，流程图从十几个平铺节点变成三个阶段块，业务方再提需求时直接说"资质审核那段要怎么改"，沟通成本明显降了一截。这就是嵌入式子流程最实在的价值。