Event Trigger 绑定工作流与输入映射

事件触发器分为两个独立的 Bundle 资源类型：EVENT_TRIGGER 用于普通事件，DEVICE_EVENT_TRIGGER 用于设备事件。两者分别声明来源、过滤条件和动作，放入同一个 resources 列表；类型是完整资源身份的一部分，同名资源键不会合并。普通事件由 Event Center 执行，设备事件由 Relay 执行。模块声明事件、业务发布事件、触发器消费事件是三个步骤。新定义的 Module 来源、动作 Module 和表达式属性来源必须属于同一个 Bundle。外部服务通过本包 Module 属性配置接入。创建版本时完成作者检查，安装不重复远程语义校验；来源属性未绑定时保存空来源集合，不接收业务事件。沿用既有启停配置，不新增独立启用步骤。执行主体必填，首次默认安装人，升级、重放和属性更新保留原主体。

模块发布事件 → 已启用订阅匹配 source 与 condition → action.inputs 求值
  → Workflow Owner 直接受理已安装 Workflow → human 创建人工事项

主流程发布事件后可以结束，由触发器启动独立人工处理流程。subflow 会等待子流程，不能代替这个过程。

当 action.type 为 module_method 时，普通事件订阅和设备事件动作使用相同的原属性寻址规则：Event Center 或 Relay 根据事件输入选择条件分支、Map key 或 List 索引，再将原属性路径、方法和业务参数直接发送到 Gateway。Gateway 解析当前绑定并校验最终目标权限；消费者不读取绑定、不保存最终外部模块 businessId、不经 Backend 转发。业务参数保持独立，特殊字符按路径协议编码。未绑定、目标缺失或权限拒绝会明确失败，不自动补授权。

1. 解析当前资源与来源合同

先核对本机命令帮助，再从资源 Owner 的当前库存读取实际身份、版本与启用状态。安装列表和操作成功记录只证明审计结果，不能代替当前资源事实。Owner 读取失败应明确报错。

baijimu --version
baijimu runtime service list --help
baijimu runtime service get --help
baijimu bundle resource object create --help
baijimu runtime service list --workspace-id <WORKSPACE_ID> \
  --environment-key <ENVIRONMENT_KEY> --bundle-id <SOURCE_BUNDLE_ID> --json
baijimu runtime service get <SOURCE_BUSINESS_ID> --workspace-id <WORKSPACE_ID> --json

完整身份为 ResourceLocator = environmentKey/bundleId/resourceType/resourceKey。从 Owner 返回的归属解析 Locator，不把 Runtime businessId、显示名、内部 ID 或域名当作 Locator。零匹配、多匹配或查询失败时不能自行猜测。

确认来源 Module 的精确版本声明了所需事件与参数，目标 Workflow 已在同一 Runtime 中交付。workflow 动作直接使用完整 Workflow Locator；Event Center / Relay 负责编译事件映射并调用 Workflow Owner，调用地址从平台服务登记取得，作者无需配置 executor 模块或调用地址。Workflow Owner 使用目标工作流当前已交付的执行编译与保存的执行主体受理。启动使用 Owner 的当前精确版本，不能用草稿或市场最新版本代替。

2. 定义 source/action

本例使用原生 workflow 动作。action.inputs 直接是工作流输入对象，不包裹模块方法的 payload。示例身份和业务字段应按实际合同替换。

{
  "name": "处理模块事件",
  "source": {
    "type": "module",
    "resourceLocator": "origin/reports/MODULE/reporter",
    "event": "reportCreated"
  },
  "action": {
    "type": "workflow",
    "resourceLocator": "origin/reports/WORKFLOW/review",
    "inputs": {
      "reportId": "=event.data.reportId"
    }
  }
}

下载机器示例。示例由事件定义 Owner 的真实 DTO 解析与语义测试验证；文档检查锁定示例摘要与正文。

--definition 接收定义本身，不包裹 data、definition，不加入只读身份与时间戳。

旧顶层字段 triggerBusinessId、triggerService、triggerConnectorId、triggerEvent、triggerCondition、actionBusinessId、actionMethod、actionParamMappings、status 均不属于当前作者合同。启用状态与设备选择属于运行态配置，不能写入作者定义。

来源类型

动作类型

workflow 不接受 executor、method、调用地址、调用身份或作者 requestId。可选 metadata 与 inputs 一样按事件数据求值；initiatedByUserId、requestUserId、eventInitiator 是 Owner 保留审计字段。动作的执行审计由 Workflow Owner 生成，不冒充安装或升级操作人。

其他真实 DTO 机器示例：属性来源与模块动作、设备应用来源。两类事件都可以选择 workflow；一般模块方法调用继续选择 module_method，按照目标方法合同填写参数。历史模块包装示例 仅用于理解已有定义，新增工作流触发使用本页原生动作。

3. 映射与幂等

以 = 开头的映射字符串按 CEL 求值，其他字符串是字面量。对象与数组递归处理并保留 JSON 类型。event.data 是事件业务载荷，只有业务数据本身含 payload 时才读取 event.data.payload。

本例可把 action.inputs 替换为 "=event.data"，或仅映射所需字段。"userIds": "=event.data.userIds" 保留负责人数组；human 使用 Workflow 的 {{input.userIds}} 读取，规则见动态用户列表。workflow 的整个 inputs 表达式必须求值得到 JSON 对象；数组、null 或求值失败会明确拒绝本次投递。

事件映射不能读取尚未启动的 Workflow context。原生 Workflow 的表达式求值失败会明确失败，不以 null 或默认值继续启动。输入和元数据必须得到对象。同一订阅/消费组与事件重试复用 Owner 自动生成的稳定请求标识，作者不声明 requestId。Workflow Owner 持久化受理后返回准确请求与目标的回执，事件 Owner 才记成功或确认设备消费；已受理不代表业务步骤已完成。回执丢失后的重试返回原执行，不重复创建实例。

工作流不可用、目标或输入冲突、授权失败、超时及回执不匹配均保持显式失败，沿用各事件 Owner 原有重试规则；不回退到 executor 模块。

4. 创建定义、版本与交付

baijimu bundle resource object create <bundle> event-trigger --workspace-id <WORKSPACE_ID> \
  --resource-key issue-opened --definition @event-trigger.json --json

baijimu bundle resource object get <bundle> event-trigger --workspace-id <WORKSPACE_ID> \
  --object-id <TRIGGER_KEY> --json
baijimu bundle resource object version create <bundle> event-trigger --workspace-id <WORKSPACE_ID> \
  --object-id <TRIGGER_KEY> --version <TRIGGER_VERSION> --json

身份取自 Owner 创建结果或对应资源的查询结果。已有定义用 bundle object update 提交完整定义，再发布后继版本，不覆盖不可变版本。来源 Module、直接动作 Module、表达式属性来源及 Workflow 动作的目标 Workflow 必须属于本 Bundle；外部服务通过本包 Module 属性配置接入，不声明 Bundle 安装依赖。human 的 IssueDefinition 选择遵循对应 Workflow 作者合同。遵循严格 SemVer，新功能、破坏性变更及首次发布的准确版本需要单独确认。

设备事件使用通用资源命令，类型明确填写 DEVICE_EVENT_TRIGGER；不能通过普通事件入口提交 device 来源：

baijimu bundle resource create <bundle> --workspace-id <WORKSPACE_ID> \
  --resource-type DEVICE_EVENT_TRIGGER --resource-key device-message \
  --definition @device-event-trigger.json --json
baijimu bundle resource version create <bundle> --workspace-id <WORKSPACE_ID> \
  --resource-type DEVICE_EVENT_TRIGGER --resource-key device-message \
  --version <TRIGGER_VERSION> --json

部署时 Backend 将精确资源引用、动作和配置发给登记的 Runtime Owner；Runtime Owner 读取该精确版本的定义，完成必要的编译与物化。设备选择和启用状态仍由 Runtime Owner 保存，不能放入 Bundle 定义。

将精确资源版本纳入根级 resources，按修订更新数据库，再从返回的准确修订创建 Bundle Version，再安装或升级目标 Runtime。完整流程见项目清单和版本与交付。

5. 错误详情与验收

输入错误返回 HTTP 200 的 CModel 业务失败，errorCode=BUNDLE_RESOURCE_ERROR。data 包含安全的 message、retryable: false、requestId；还包含 fieldPath、reason，可确定时包含 expected。旧字段路径为 definition.triggerBusinessId，原因是 UNKNOWN_FIELD。响应 x-request-id 与正文一致。内部错误通过请求标识查日志，不返回数据库、地址、凭据或完整请求值。

不能仅凭草稿保存、版本创建、Bundle 发布或安装账成功认定事件链路完成：

1. 从各 Runtime Owner 回读触发器、Workflow、Module 与 Issue 的当前精确版本、归属和启用状态。
2. 用真实业务操作发布符合合同的事件，记录事件 ID 与业务关联 ID。
3. 查询 Workflow 实例及执行记录，核对映射值、对象/数组类型、元数据与启动请求标识。
4. 核对 human 事项输入与当前 IssueDefinition 合同；提交符合输出类型的结果，确认流程继续。
5. 同一事件重试不重复启动，不同订阅与事件不能误合并。

baijimu runtime bundle resource workflow list --workspace-id <WORKSPACE_ID> --application-runtime-id <APPLICATION_RUNTIME_ID> --json
baijimu runtime bundle resource workflow get --workspace-id <WORKSPACE_ID> <INSTANCE_ID> --json
baijimu runtime bundle resource workflow executions --workspace-id <WORKSPACE_ID> <INSTANCE_ID> --json

事件发布、触发工作流、创建事项、人工完成分别按实际记录验收。

继续阅读：模块事件、工作流、人工事项与 human。

旧草稿迁移

直接跨包的 Module 来源或动作不能继续用于创建新版本。将外部服务改为本包 Module 的 Interface 属性引用，再在 Runtime 配置该属性。Workflow 动作的资源身份也应属于本包。历史不可变内容保持原样，不能通过重写旧版本进行迁移。

历史以 EVENT_TRIGGER 发布的设备定义不能原地改写。迁移需要创建独立的 DEVICE_EVENT_TRIGGER 身份并发布 Bundle 后继版本；Runtime 存量、原凭据和消费进度按已审核的迁移清单处理，不因重新安装而重签凭据或重放历史事件。

原生 Workflow 动作迁移需从作者源创建后继事件版本与 Bundle 版本，不能重写历史不可变定义。存量订阅/消费组通过 Owner 审核迁移保留原 ID、配置、消费进度和已受理请求身份；作者不能复制历史 requestId 表达式到新动作。已受理 Workflow 的执行与审计保留，不因切换入口而重新启动。