事件与幂等契约

事件结构

BPM 回调使用业务标识与对外实例标识，不要求所属应用保存底层引擎标识。

{
  "eventId": "11111111-1111-4111-8111-111111111111",
  "tenantId": "22222222-2222-4222-8222-222222222222",
  "bizType": "example.payment-request",
  "bizId": "PAY-2026-001",
  "instanceId": "33333333-3333-4333-8333-333333333333",
  "type": "process.approved",
  "occurredAt": "2026-10-09T02:00:00Z",
  "actor": "44444444-4444-4444-8444-444444444444",
  "result": { "status": "APPROVED" }
}

示例用于说明形状。接收端必须按注册契约校验业务类型和结果，不以通知文案推断业务状态。

接收处理

1. 验证服务 JWT、租户、客户端归属与能力 scope。
2. 校验 eventId、业务对象和当前允许的状态变化。
3. 在所属应用本地事务中登记事件 ID 并更新业务结果。
4. 已处理的重复事件不重复执行业务动作，返回成功。
5. 事务提交成功后返回 2xx；失败返回相应错误供发送方重试。

HTTP 回调携带 Idempotency-Key: <eventId>。去重记录与业务变化需要同一事务，避免“记为成功但业务没提交”。

投递与重试

超时、网络错误和非 2xx 会触发重试；业务已经提交但响应丢失也会重投。BPM 同实例前一事件未成功时，后续事件不先行投递。

服务执行节点使用任务 ID 作为幂等键；人工重试沿用原键。请求结果未知时先查原记录，不能换键反复创建业务副作用。

HRM 身份事件

HRM 以发件箱单向投影人事事实，IAM 收件箱维护连续身份事件版本、计划生效与取消。身份事件版本和人事业务修订版本分别管理。

业务失败恢复

审批通过只代表流程决定。支付、文件发布或身份同步等后续失败，由所属应用按自己的补偿与恢复规则处理；不要用再次同意审批掩盖业务失败。

审批接入 · 人事同步