BPM Workflows

任务中心 — 审批与任务

AuraBoot 内置 BPM Workflow 支持,用于审批流、Task 路由、SLA 跟踪与状态流转编排。当一条记录不应在缺乏人工审核或流程逻辑的情况下直接从一个状态切换到另一个状态时,BPM 十分有用。

如果你要看完整可运行样例,直接读 BPM 端到端示例。该页以 workflow-demo 的 wd_leave_approval 为主线,覆盖设计器、运行时、任务中心、Rule 与 SLA。

核心概念

概念	描述
Process definition	Workflow 模板,通常基于 BPMN
Process instance	与记录绑定的运行中 Workflow
Task	流程中的人工或自动化步骤
Assignment rule	Task 所有者的选取方式
Gateway	Workflow 中的条件分支
SLA	截止时间与升级行为

Workflow 与 Command 的关系

AuraBoot 将 Workflow 与 Command 视为互补:

User clicks Submit
  -> state transition command validates and changes record
  -> workflow instance starts
  -> approval task is assigned
  -> approver completes task
  -> next command changes record again

Command Pipeline 仍是数据变更的唯一可信源。BPM 负责协调下一步由谁、在何时执行。

示例:请假审批

wd_leave_request(draft)
  -> wd:submit_leave_request
  -> wd_leave_validation 前置校验
  -> wd_leave_approval 流程实例
  -> wd_leave_routing 路由规则
     -> days < 3  : task_manager_approve
     -> days >= 3 : task_hr_approve
  -> taskResult approved/rejected
  -> record-update-task 回写 wd_req_status
  -> notification-task 通知申请人

状态流转 Command

{
  "code": "wd:submit_leave_request",
  "type": "state_transition",
  "modelCode": "wd_leave_request",
  "stateField": "wd_req_status",
  "fromStates": ["draft", "rejected"],
  "toState": "submitted",
  "postActions": [
    {
      "type": "start_process",
      "processKey": "wd_leave_approval",
      "businessKey": "${recordId}",
      "variables": {
        "days": "${payload.wd_req_days}",
        "type": "${payload.wd_req_type}",
        "recordId": "${recordId}",
        "applicantUserId": "${payload.wd_req_applicant}"
      },
      "storeInstanceIdIn": "wd_req_process_instance"
    }
  ]
}

分派策略

策略	适用场景
Fixed user	始终路由到一个已知所有者
Role-based	任何拥有该 Role 的用户都可领取
Field-based	路由到记录所有者、经理或指派人
Department head	从组织结构解析
Sequential	按顺序经过多个用户

SLA 行为

{
  "slaKey": "wd_manager_approve_sla",
  "targetType": "NODE",
  "targetKey": "task_manager_approve",
  "processKey": "wd_leave_approval",
  "nodeId": "task_manager_approve",
  "deadlineMode": "FIXED",
  "deadlineValue": "PT30S",
  "warningRules": [
    { "beforeSeconds": 10, "eventType": "sla_warning", "notifyTargets": ["assignee"] }
  ],
  "escalationTargetType": "role_parent",
  "escalationTargetValue": "wd_manager"
}

workflow-demo 使用 PT30S 只是为了 E2E 能快速观察 overdue;生产环境应改成真实时长。SLA 细节见 BPM SLA 示例。

任务中心操作

人工任务进入 /bpm/task-center,由统一端点处理:

操作	端点
待办 / 已办	`GET /api/bpm/tasks/todo` / `completed`
通过 / 驳回	`POST /api/bpm/tasks/{taskId}/approve` / `reject`
委托 / 转办	`POST /api/bpm/tasks/{taskId}/delegate` / `transfer`
加签 / 回退 / 抄送	`POST /api/bpm/tasks/{taskId}/add-sign` / `rollback` / `cc`

转办与委托是不同审计动作:委托会校验可委托权限并记录 recordTaskDelegate,转办记录 recordTaskTransfer。截图和 E2E 应覆盖「更多菜单 → 转办」弹窗。

哪些场景适合用 BPM 建模

适合的候选场景:

审批流
多方评审
由升级驱动的工作
含人工决策的状态生命周期
需要审计历史的流程

不适合的候选场景:

单步 CRUD 更新
纯后台自动化
仅 UI 的向导步骤
应当作为 Command 前置条件实现的逻辑

验证清单

构建 Workflow 时:

先定义记录生命周期。
为每个生命周期步骤创建状态流转 Command。
将 Workflow Task 绑定到这些 Command。
定义分派规则。
为提交、批准、驳回与管理添加 Permission。
测试 happy path、驳回路径以及未授权路径。
检查时间线与审计输出。
覆盖任务中心的转办、委托、驳回、撤销、SLA 逾期等 sad path。