用户指南 05 · 业务闭环场景

用真实场景串起全部能力。每个场景：业务背景 → 流程定义要点 → API 调用序列。

场景一：请假审批（标准闭环）

业务规则

• 员工发起请假 → 组长审批 → 经理审批
• 组长/经理不同意 → 退回发起人，可修改重提
• 重新提交后重新走审批

流程定义要点

start → apply(applicant) → 组长审批(leader) → 经理审批(manager) → end

调用序列

① 发起（自动完成申请节点）
   POST /wf/processInstance/startAndExecute
   { "processDefineId": 2, "operator": "user1" }

② 组长审批通过
   POST /wf/processTask/execute
   { "processTaskId": 100, "operator": "leader", "submitType": 1 }

③ 经理不同意 → 退回发起人（submitType=6，实例保持进行中）
   POST /wf/processTask/execute
   { "processTaskId": 101, "operator": "manager", "submitType": 6 }
   # 效果：第一个任务节点重执行（参与者=发起人），user1 收到新待办"发起申请"

④ 发起人重新提交
   POST /wf/processTask/execute
   { "processTaskId": 102, "operator": "user1", "submitType": 0 }

⑤ 组长/经理依次审批 → 流程完成

审批记录（完整闭环）

发起申请   user1    已完成
组长审批   leader   已完成
经理审批   manager  已完成（退回操作）
发起申请   user1    已完成（重新提交）
组长审批   leader   已完成
经理审批   manager  已完成

退回发起人（submitType=6）不改变实例状态——保持进行中直到最终完成；若用 submitType=2（拒绝）则实例直接进入 45 已拒绝。行为表见设计原理 06 §3-4。

场景二：报销审批（决策分支）

业务规则

• 填写报销单 → 金额 ≤1000 总监审批即可；金额 >1000 需经理审批

流程定义要点

start → apply(applicant) → 填写报销单(leader)
      → decision1 ──amount > 1000──▶ 经理审批(manager) ──▶ end
                  └─amount <= 1000─▶ 总监审批(director) ──▶ end

决策边：

{ "id":"e3", "sourceNodeId":"decision1", "targetNodeId":"task2",
  "properties":{"expr":"amount > 1000"}, "text":{"value":"金额>1000"} }

调用序列

① 发起时带金额变量
   POST /wf/processInstance/startAndExecute
   { "processDefineId": 3, "operator": "user1", "amount": 5000 }

② 填写报销单 → 自动路由到经理审批（amount=5000 > 1000）
   { "processTaskId": ..., "operator": "leader", "submitType": 1 }
   # 经理收到待办

场景三：并行会签

业务规则

• 三个部门主管同时会签，全部同意才通过

流程定义要点

{
  "id": "countersign",
  "type": "snaker:task",
  "properties": {
    "assignee": "userA,userB,userC",
    "performType": 1,
    "countersignType": "PARALLEL"
  }
}

调用序列

① 启动 → 自动完成 apply → 同时生成 3 个会签任务（同一 taskName）

② userA / userB / userC 各自处理（顺序无关）
   { "processTaskId": ..., "operator": "userA", "submitType": 1 }
   # 完成 1 个后：还有 2 个进行中 → 等待

③ 全部完成 → 流程推进到 end → 完成

串行会签（SEQUENTIAL）

同样配置但 countersignType: "SEQUENTIAL"：只生成 userA 的任务，A 完成 → 生成 userB 的任务 → B 完成 → 推进。

场景四：并行分支合并（fork/join）

业务规则

• 发起后财务审核与法务审核并行，都通过才进入终审

流程定义要点

start → apply → fork1 ─┬→ 财务审核(checker) ─┐
                       └→ 法务审核(reviewer) ─┴→ join1 → 老板终审(boss) → end

调用序列

① 启动 → 自动完成 apply → fork 生成 2 个并行任务

② checker 完成（join 等待中）
③ reviewer 完成（join 放行 → 生成老板终审）

④ boss 完成 → end

场景五：抄送

引擎 SPI 预留 createCcInstance / updateCcStatus，demo 未内置接口。接入方式：

① 流程完成/任务完成事件中，业务方调用 createCcInstance(instanceId, creator, actorIds...)
② 被抄送人在"我的抄送"列表查看（业务层查询 wf_process_cc_instance）
③ 已读回执：updateCcStatus(instanceId, actorId)

场景选择速查

想演示	用哪个流程（demo 预置）
单级审批	简单审批流程
多级审批 + 驳回退回	多级审批流程 / 含驳回流程
金额决策路由	决策表达式流程
并行分支	并行分支合并流程
并行会签	并行会签流程
串行会签	串行会签流程
全组合	混合模式流程（fork+join+decision）