37-nextid变量法

37-nextid变量法：32行BPMN里的流转控制

demo自带的示例流程只有32行——四个节点直线连。但退回、驳回、跳转全都能跑——秘密是所有路由判断都不在BPMN里，在应用层的变量设置。这篇用这个最简BPMN讲清楚nextid变量法怎么配合网关工作，以及32行直线流程为什么能承载复杂流转。

文章目录

• 37-nextid变量法：32行BPMN里的流转控制
• • 一、32行的直线流程
  • 二、带退回的BPMN：网关+nextid条件
  • 三、为什么叫"变量法"而不是改连线
  • 四、approved变量的角色
  • 五、${applyUser}的处理人联动
  • 六、32行demo的价值

素材：browise-demo/src/main/resources/processes/apply-review-approve.bpmn20.xml（32行） FlowableProcessService.java L104-141

一、32行的直线流程

<process id="apply-review-approve" name="申请-复核-审批">
<startEvent id="start" flowable:initiator="applyUser" />
<userTask id="apply" flowable:assignee="${applyUser}" />
<userTask id="review" flowable:assignee="${reviewUser}" />
<userTask id="approve" flowable:assignee="${approveUser}" />
<endEvent id="end" />

<sequenceFlow id="s1" sourceRef="start" targetRef="apply" />
<sequenceFlow id="s2" sourceRef="apply" targetRef="review" />
<sequenceFlow id="s3" sourceRef="review" targetRef="approve" />
<sequenceFlow id="s4" sourceRef="approve" targetRef="end" />
</process>

三个特点：

assignee是UEL表达式——${applyUser}从流程变量取处理人。启动时传什么人、节点就分给什么人——处理人不在BPMN写死，启动参数决定（配置化处理人的入口在WorkflowConfigService的OpPerson/OpRole表——第43篇）。

没有网关——直线。没有条件表达式——所有sequenceFlow无条件。

那退回/驳回怎么走？——这个简化版确实走不了（直线流程complete只能往下走）。demo的32行是最小验证流程。真实的政务流程BPMN在网关上写nextid条件——下面是带退回的完整版长什么样。

二、带退回的BPMN：网关+nextid条件

把32行扩展成支持退回的版本：

<process id="apply-review-approve-v2">
<startEvent id="start" flowable:initiator="applyUser" />
<userTask id="apply" flowable:assignee="${applyUser}" />

<!– 复核节点后加排他网关 –>
<userTask id="review" flowable:assignee="${reviewUser}" />
<exclusiveGateway id="gw_review" />

<userTask id="approve" flowable:assignee="${approveUser}" />
<exclusiveGateway id="gw_approve" />

<endEvent id="end" />

<sequenceFlow id="s1" sourceRef="start" targetRef="apply" />
<sequenceFlow id="s2" sourceRef="apply" targetRef="review" />

<!– 复核后的三条路：默认前进/退回/结束 –>
<sequenceFlow id="s3" sourceRef="gw_review" targetRef="approve">
<conditionExpression xsi:type="bpmn:tFormalExpression">
#{nextid == null || nextid == 'approve'}
</conditionExpression>
</sequenceFlow>
<sequenceFlow id="s3_back" sourceRef="gw_review" targetRef="apply">
<conditionExpression>#{nextid == 'apply'}</conditionExpression>
</sequenceFlow>
<sequenceFlow id="s3_end" sourceRef="gw_review" targetRef="end">
<conditionExpression>#{nextid == 'endEvent'}</conditionExpression>
</sequenceFlow>

<!– 审批后同理 –>
…
</process>

网关条件全部读nextid变量——应用层设什么nextid、流程走哪条线：

三、为什么叫"变量法"而不是改连线

传统做法的困境——退回要“从当前节点画一条线回申请节点”：

问题1: N个审批节点 × 退回目标（发起人/上一节点/任意历史节点）= 连线爆炸
5节点流程全互通 = 20条退回线——流程图变蜘蛛网
问题2: 每加一种退回策略要改BPMN重新部署——生产流程定义变更要走审批
问题3: Flowable对"退回已完成的节点"没有原生API——回退到历史节点要手工操控execution

nextid变量法的解——连线只画一遍（网关的默认前进+通用退回线+结束线），流向由变量决定。N个节点每个网关固定三条出线，不随业务策略增长。

// 退回到"上一步"而不是"发起人"——只改应用层代码
runtimeService.setVariable(executionId, "nextid", 上一节点的taskDefKey); // 不是firstTask

// 退回到任意历史节点——从历史任务列表取任意一个的taskDefKey
List<HistoricTaskInstance> hist = historyService...list();
runtimeService.setVariable(executionId, "nextid", hist.get(k).getTaskDefinitionKey());

策略变化零BPMN改动——这就是已发布《政务工作流实战》系列讲的“退回不该画连线”的代码实现。

四、approved变量的角色

finishProcess: nextid='endEvent', approved=true
rejectProcess: nextid='endEvent', approved=false

两条线走到同一个endEvent——到达结束节点后，监听器/后置拦截器读approved判断“正常通过还是被驳回”——驱动业务侧的状态更新（通过→参保生效；驳回→通知发起人改材料）。

一个结束节点+一个布尔变量——不用画“通过结束/驳回结束”两个endEvent。流程图保持简洁，语义在变量里。

五、${applyUser}的处理人联动

退回申请节点后——flowable:assignee="${applyUser}"重新解析——applyUser变量在启动时设置的是发起人——退回后任务回到发起人手里。

backToPrevious里的第二行：

runtimeService.setVariable(executionId, "user", startUserId);

user变量是给“动态assignee节点”预留的——某些流程的节点不写死

a

p

p

l

y

U

s

e

r

而写

{applyUser}而写

applyUser而写{user}（运行时指定处理人）——退回时设user=发起人保证这类节点也回到对的人。

六、32行demo的价值

最小流程跑通链路——部署/启动/complete/待办/历史全流程验证。E2E测试的79个API用例有相当部分跑在这个32行流程上。“最小可验证样本”是框架开发的脚手架——比一上来画复杂流程图高效得多。真实的政务流程BPMN由ProcessModelService的buildEmptyBpmn模板生成+设计器编辑（第42篇）——但验证引擎行为，32行足够。

✅ 亮点：32行BPMN与带网关完整版的对照、nextid变量法解决连线爆炸/部署变更/无原生退回API三大困境、approved布尔区分同一条结束线的通过与驳回、${user}变量给动态assignee节点兜底、最小可验证样本的工程价值。与已发布《政务工作流实战——任意流转》呼应。扩展方向：第36篇方法地图、第41篇拦截器、第42篇流程设计器。