低代码与工作流引擎集成

三层分工：
  数据层：存什么（数据模型）
  界面层：怎么录入/查看（表单/页面）
  流程层：谁在什么时候做什么（工作流）

流程层的输入输出：
  输入：表单提交的数据 + 触发条件
  输出：任务分配 + 状态变更 + 通知

BPMN 2.0：
  优点：标准、表达力强、有工具生态
  缺点：复杂、学习曲线陡、低代码用户难理解

简化 DSL：
  优点：易读易编辑、贴合低代码场景
  缺点：表达力有限、无标准

折中：
  内部用简化 DSL 建模，可导出 BPMN
  或直接采用 BPMN 子集（仅顺序/分支/并行/会签）

{
  "id": "leave_flow",
  "version": 3,
  "start": "submit",
  "nodes": {
    "submit":   { "type": "start", "form": "leave_form", "next": "mgr_approve" },
    "mgr_approve": {
      "type": "task",
      "assignee": { "type": "manager", "of": "{{ initiator }}" },
      "next": "days_check"
    },
    "days_check": {
      "type": "gateway",
      "branches": [
        { "when": "{{ form.days > 3 }}", "next": "hr_approve" },
        { "when": "else", "next": "end" }
      ]
    },
    "hr_approve": {
      "type": "task",
      "assignee": { "type": "role", "value": "hr" },
      "next": "end"
    },
    "end": { "type": "end" }
  }
}

interface FlowNode {
  type: 'start' | 'task' | 'service' | 'gateway' | 'parallel' | 'timer' | 'end';
  assignee?: AssigneeRule;      // task
  branches?: Branch[];          // gateway
  service?: ServiceRef;         // service
  duration?: string;            // timer（如 PT72H）
  next?: string | string[];
}

模式 A：流程内嵌表单
  每个节点可指定一个表单，用于该节点的输入
  适合：不同节点填不同信息（申请填 A，审批填 B）

模式 B：流程引用表单
  流程只引用一个主表单，节点做只读/编辑切换
  适合：单一单据的审批

模式 C：表单驱动流程
  表单提交即触发流程，流程无独立表单
  适合：简单的一次性审批

{
  "mgr_approve": {
    "type": "task",
    "form": {
      "ref": "leave_form",
      "mode": "readonly",
      "editableFields": ["approveComment"]
    }
  }
}

会签（all）：所有人同意才通过
或签（any）：任一人同意即通过
依次（sequential）：按顺序逐个审批
加签（add）：审批过程中临时增加审批人

{
  "hr_approve": {
    "type": "task",
    "assignee": { "type": "role", "value": "hr" },
    "approvalMode": "all",
    "strategy": {
      "onReject": "toStart",
      "onTimeout": "escalate",
      "escalateTo": { "type": "role", "value": "hr_lead" }
    }
  }
}

表达式来源：
  表单字段：{{ form.amount }}
  流程变量：{{ variables.level }}
  上下文：{{ initiator.dept }}
  系统：{{ now }}

求值语义：
  按顺序匹配，第一个为 true 的分支胜出
  else 分支兜底

function evaluateGateway(node: FlowNode, ctx: FlowContext): string {
  for (const branch of node.branches ?? []) {
    if (branch.when === 'else') return branch.next;
    if (evaluateExpr(branch.when, ctx)) return branch.next;
  }
  throw new Error(`gateway ${node.id} no branch matched`);
}

CREATE TABLE wf_instance (
  id            varchar(36) PRIMARY KEY,
  def_id        varchar(64) NOT NULL,
  def_version   int NOT NULL,
  tenant_id     varchar(36) NOT NULL,
  business_key  varchar(64),          -- 业务单据 id
  status        varchar(20) NOT NULL, -- running/completed/terminated
  current_node  varchar(64),
  variables     jsonb NOT NULL DEFAULT '{}',
  started_at    timestamptz NOT NULL DEFAULT now(),
  ended_at      timestamptz
);

CREATE TABLE wf_task (
  id            varchar(36) PRIMARY KEY,
  instance_id   varchar(36) NOT NULL REFERENCES wf_instance(id),
  node_id       varchar(64) NOT NULL,
  assignee      varchar(64),
  status        varchar(20) NOT NULL, -- pending/approved/rejected/canceled
  created_at    timestamptz NOT NULL DEFAULT now(),
  acted_at      timestamptz,
  comment       text
);

CREATE INDEX idx_task_assignee ON wf_task(assignee, status);

状态流转：
  instance: running → completed / terminated
  task:     pending → approved / rejected / canceled

超时场景：
  - 节点超时提醒（3 天未审批 → 发提醒）
  - 节点超时自动处理（5 天 → 自动通过/升级）
  - 流程级 SLA（整体 7 天未完成 → 告警）

实现：
  方案 A：数据库轮询（扫 due 时间到期的任务）
  方案 B：延迟队列（Redis ZSet / MQ 延迟消息）
  方案 C：调度框架（Quartz / Temporal）

-- 方案 A：扫到期任务
SELECT id FROM wf_task
WHERE status = 'pending' AND due_at <= now()
ORDER BY due_at LIMIT 100;

{
  "notify": {
    "type": "service",
    "service": {
      "kind": "http",
      "method": "POST",
      "url": "/internal/api/notify",
      "headers": { "Authorization": "Bearer {{ secrets.notifyToken }}" },
      "body": { "to": "{{ task.assignee }}", "title": "待审批" },
      "retry": { "max": 3, "backoff": "exponential" },
      "timeout": "PT10S"
    },
    "onError": "continue"
  }
}

失败策略：
  - 重试：网络抖动，指数退避
  - 跳过（continue）：非关键步骤
  - 挂起（suspend）：关键步骤失败则暂停流程等人工处理
  - 终止（terminate）：不可恢复错误

版本策略：
  1. 新实例用新版本，旧实例继续用旧版本（推荐）
  2. 强制所有实例升级（危险，可能不兼容）
  3. 双版本并行（灰度，按比例分流）

实现：
  实例持久化时记录 def_version
  引擎按实例的 def_version 加载对应定义

function loadDefinition(defId: string, version: number): FlowDefinition {
  // 版本化加载：确保运行中实例不受新版本影响
  return definitionStore.get(defId, version);
}

必备能力：
  - 实例视图：当前节点、停留时长、处理人
  - 任务视图：待办、超时、异常
  - 流转日志：每次状态变更的时间与操作人
  - 死信/异常队列：失败自动节点的重试入口
  - 看板：各节点平均耗时、超时率