4. 数字线程中的自动化触发机制

数字线程把需求、设计、工艺、制造、检验、运维等阶段的数据串成一条可追溯的链路。链路本身不会自己动起来，真正让数据在环节之间流动、让任务在正确时刻被唤醒的，是自动化触发机制。可以把触发机制理解为数字线程的“神经反射”：某个条件满足，系统就自动执行预定动作，例如生成工单、推送变更、启动仿真、通知责任人、回写检验结果。本节围绕事件驱动架构、消息队列、规则引擎、条件触发、定时触发与外部系统回调触发六种机制展开，重点说明它们各自解决什么问题、如何组合使用，以及落地时的关键参数与判断依据。

一、事件驱动架构：以“发生了什么”为中心

事件驱动架构（EDA）的核心是把系统间的协作从“主动调用”改为“事件通知”。当设计端完成一次ECN变更，它不直接去调用MES的接口，而是发布一个ecn.released事件；下游的工艺、制造、质量系统各自订阅自己关心的事件并做出反应。这样发布者不需要知道谁在消费，消费者也不需要轮询数据库，耦合度显著降低。

一个典型事件包含：事件类型、事件ID、发生时间、来源系统、业务主键（如物料号、工单号）、载荷数据以及版本号。例如：

{
  "eventType": "ecn.released",
  "eventId": "evt-20240612-0087",
  "occurredAt": "2024-06-12T10:23:41+08:00",
  "source": "PLM",
  "bizKey": "MAT-8842",
  "payload": {
    "ecnNo": "ECN-2024-0612",
    "changeType": "material",
    "affectedItems": ["MAT-8842", "MAT-8843"],
    "effectiveDate": "2024-06-20"
  },
  "schemaVersion": "1.2"
}

设计要点有三：一是事件要“薄”，只携带必要标识和关键字段，避免把大对象塞进消息体；二是事件要可追溯，事件ID和业务主键必须能反查到源头；三是事件要幂等，消费者重复收到同一事件时结果一致，通常用事件ID做去重键。

二、消息队列：让事件可靠地流动

事件驱动需要载体，消息队列（MQ）就是最常用的载体。它解决三个问题：削峰、解耦、可靠投递。数字线程中常见的队列选型包括Kafka（高吞吐、可回放）、RabbitMQ（灵活路由）、RocketMQ（事务消息）等。无论选哪种，都要关注以下参数：

• 投递语义：至少一次（at-least-once）最常用，配合消费端幂等实现“效果上恰好一次”。
• 分区键：用物料号或工单号做分区键，保证同一业务对象的变更按顺序被消费。
• 重试与死信：消费失败重试3次后进入死信队列，由人工或补偿任务处理，避免消息丢失。
• 积压监控：消费延迟超过阈值（如5分钟）即告警，防止数字线程“断流”。

举例来说，当ecn.released事件进入Kafka的plm.ecn主题，工艺系统消费后生成工艺变更任务，制造系统消费后冻结相关工单。若制造系统暂时不可用，消息在队列中保留，恢复后继续消费，不会因为一次故障导致变更丢失。

三、规则引擎：把“判断逻辑”从代码中抽出来

事件和消息解决了“怎么传”，规则引擎解决“收到之后怎么判断”。数字线程中的触发条件往往复杂且经常变化，例如“当变更涉及安全件且影响已交付批次时，必须触发质量评审”。如果把这类逻辑硬编码在消费者里，每次业务调整都要改代码、重新发布。规则引擎把条件写成可配置的规则，由引擎在运行时匹配。

一条规则通常由三部分组成：条件（when）、动作（then）、优先级（priority）。例如：

rule "安全件变更触发质量评审"
when
  $e : ECNEvent(changeType == "material",
                safetyRelated == true,
                affectedDeliveredBatch == true)
then
  triggerTask("QUALITY_REVIEW", $e.bizKey);
  notifyRole("质量工程师", $e.ecnNo);
end

规则引擎的价值在于：业务人员可以调整阈值和条件，而不必等待开发排期；同时规则可以集中管理、版本化、灰度发布。需要注意的是，规则数量增多后要建立冲突检测和优先级排序，避免同一事件被多条规则重复触发或互相覆盖。

四、条件触发、定时触发与外部回调

条件触发是规则引擎的轻量形态，适合单一判断，例如“当检验结果NG且缺陷等级为A时，自动创建不合格品处理单”。它通常由事件流中的过滤算子实现，延迟低、实现简单。

定时触发解决“时间到了才做”的问题。数字线程中大量任务具有时间属性：变更生效日到达时切换BOM版本、每日凌晨同步ERP物料主数据、每周一生成质量周报。定时触发常用cron表达式描述，例如0 0 2 * * ?表示每天凌晨2点执行。关键是要处理“错过执行”的情况：如果系统在预定时间不可用，恢复后应补执行还是跳过，需要根据业务语义明确。对于生效日切换这类任务，通常采用“补偿扫描”，即恢复后查询所有已到生效日但未切换的记录并补做。

外部系统回调触发用于跨企业或跨平台协作。当供应商在外部平台完成发货，平台通过HTTP回调通知本企业的数字线程，携带发货单号、批次、数量等信息。回调接口必须做签名校验、时间戳防重放、幂等处理，并设置合理的超时与重试策略。若回调失败，应提供主动查询接口作为兜底，避免只依赖回调导致状态不一致。

五、六种机制如何组合

这六种机制不是互斥选项，而是分层协作。事件驱动架构定义“谁发布、谁订阅”的协作模式；消息队列提供可靠传输；规则引擎负责复杂条件判断；条件触发是规则引擎的轻量补充；定时触发处理时间维度；外部回调打通企业边界。一个完整的变更场景可以这样组合：PLM发布ECN事件 → Kafka按物料号分区投递 → 规则引擎匹配“安全件且已交付”规则 → 触发质量评审任务并通知责任人 → 若变更生效日为未来某天，则由定时任务在生效日凌晨执行BOM切换 → 供应商发货后通过回调更新到货状态。

六、落地时的关键判断

选择触发机制时，可以用三个问题快速判断：第一，触发是“瞬时发生”还是“到点发生”？瞬时用事件，到点用定时。第二，判断逻辑是简单过滤还是多条件组合？简单用条件触发，复杂用规则引擎。第三，触发源是否在企业外部？是则必须设计回调加主动查询的兜底。此外，无论哪种机制，都要保证可观测性：记录触发时间、事件ID、规则命中情况、执行结果和耗时。当数字线程出现“该动的没动”时，能沿着触发链快速定位是事件没发出、消息没消费、规则没命中，还是动作执行失败。建议为每条触发链设置端到端延迟指标，例如从ECN发布到工单冻结完成不超过2分钟，超过即告警，这样才能让自动化真正可信。