规则定义、审批与运行状态
运营人员维护一条规则时，需要同时表达“条件是什么”“哪些设备有资格参与”“绑定哪种业务”和“修改是否已经审批”。这些信息并不适合压在一个状态位中，因此数据库把规则正文、范围关联、业务关联和消息记录分开保存。
条件与可视化编辑
rule_liteflow_chain 保存一条规则的中文别名 name、运行链名 chain_name、执行表达式 el_data、编辑器 JSON json_data、应用名、作用范围、业务类型、路由和命名空间。id 是业务关联使用的数据库编号，chain_name 是 LiteFlow 执行时使用的链标识，不能互换。管理 Service 校验别名和链名重复，并在更新时禁止修改既有链名；实库没有相应唯一索引，仅应用层检查。
rule_field_definition 定义编辑器可以展示的设备字段：name 是字段名，alias_name 是显示名称，type 是整型字段类型标识，available_operators 是可用比较组件列表。旧注释中的 string/number/time 是类型语义，不是该整型列直接保存的文本值。可用组件通过 RuleCmpInfoTypeHandler 序列化为 JSON 字符串，实际列为 varchar(4096)，不是原生 JSON 列。
比较节点实现位于 rule-api 的 component/bool/，例如等于、包含、范围、空值比较；编辑器通过 FlowBus.getNodeMap() 列出已注册组件，再由 ExpressGenerator 生成和校验 EL。本次实库没有 liteflow_script 或单独“条件实例表”；脚本表配置处于注释状态。具体节点与比较参数主要存在 EL/编辑器 JSON 中，不能套用通用 LiteFlow 示例凭空添加脚本表。
设备上下文 DeviceRespRuleDTO 继承 device 的 DeviceRespDTO，输入来自业务方；DeviceContext 将其展开为属性集合。若条件涉及 heartbeatTime，DeviceNodeBoolean 按需从设备 Redis 心跳读取一次。提供的配置 getDeviceOnRule=false 表示不默认重新向规则中心获取设备信息；数据库中的规则字段定义不存储设备实时值。
草稿和当前有效规则并存
| 字段 | 业务意义 |
|---|---|
enable | 当前规则是否启用，运行匹配要求为 1 |
bpm_status | 审批流程所处状态，不能用它代替运行启用位 |
valid | 业务变更阶段：0 未生效、1 已生效、2 已生效待修改、3 已生效待移除、4/5 待启用/待禁用标记 |
draft | 原生 JSON，保存 BpmDraft<RuleLiteflowChainDO> 的待批准变更，与仍然有效的主字段共存 |
has_mac | 是否挂有 MAC/资源/渠道等设备范围，参与候选规则筛选，不等于数据库 MAC 行计数 |
需要审批时，已生效规则的关键字段变更写入草稿并保留当前有效值；新规则可处于 valid=0。无需审批或具备跳过审批权限时，Service 直接更新定义和缓存。参与草稿追踪的字段由 @IncludeInBpmDraft 决定：当前标注了 elData/route/namespace/enable，jsonData 的草稿注解已注释，不能把全部字段一律写成审批版本快照。
BPM 事件监听器按 (businessType,businessId) 找到绑定规则。审批未通过的分支只更新流程状态；审批通过后才落地新增/修改/删除关系、拷贝草稿字段、清理缓存并广播规则变化。业务删除审批通过时会解绑规则。一个业务可以关联多条规则，一条通用规则也可参与多个业务，因此审批逻辑不能只按单个链 ID 理解。
发布、加载和执行不是同一个状态
提供的 LiteFlow SQL 读取配置加载满足以下条件的记录：application_name='ik_v2'、deleted=0、enable=1、EL 非空。此 SQL 未过滤 valid 或 bpm_status。另一方面，实际 RuleRunUtil 匹配先从有效业务关系取得候选规则，再检查规则 enable=1、valid!=0 和地区限制。因此“进入内存链”不能直接等同于“对业务有效”。
规则变更通过 RuleAlterEvent 广播；消费端 EL 非空时创建/更新内存链，EL 为空时移除链。运行路径中，规则若没有 EL，只要设备范围、启用/有效性和地区检查通过，就按匹配成功处理，支持仅用范围圈选的规则。EL 非空时执行链并以响应成功状态判定；异常记录日志，该条不加入命中集合。
编辑器另有两种适配路径：具备 SQL Parser 类时使用 SqlBizServiceImpl 写库，缺省 BizServiceImpl 只操作内存 FlowBus。SQL 编辑器保存逻辑与带审批的管理 Service 不是同一实现。文档仅描述这些入口存在，未核验当前页面暴露范围及运行注入结果，也不假定它们具有相同审批保障。
待审批消息为什么落库
rule_bpm_no_start_message 记录规则已产生待审批变更后发给业务服务的通知。发送前生成 message_key，写父记录和序列化消息，再发送 Kafka。业务反馈可按相同消息键和不同重试主题形成子记录：parent_id 关联父记录，retry_topic/status/retry_count 表示各条处理进度，异常 字段用于追踪失败。
这个表的“消息唯一标识”不是数据库唯一约束：实库只有主键。同一个 message_key 允许对应不同反馈/重试记录；状态更新方法先查消息键再匹配主题，不能将每行理解为独立业务变更。管理端支持忽略待处理或失败消息，以及根据保存的内容重发；“提交重发”不等于业务方已经处理成功。
规则编辑检查回调当前有 Spring Cloud Bus 监听器；旧 RuleCanEditCallbackConsumer.java 整文件已注释，不能把它列成运行中的 Kafka 消费者。待审批消息通知和编辑检查回调是不同链路。
源码与配置证据
| 证据 | 位置 |
|---|---|
| 定义、草稿标注与状态字段 | B/dal/dataobject/chain/RuleLiteflowChainDO.java:20,57,74,85 |
| 创建、更新、唯一性检查 | B/service/chain/RuleLiteflowChainServiceImpl.java:107,190,313 |
| 字段定义及组件 | B/dal/dataobject/fielddefinition/RuleFieldDefinitionDO.java:19；B/editor/service/impl/SqlBizServiceImpl.java:47；A/component/bool/DeviceNodeBoolean.java:27 |
| 设备属性与按需心跳 | A/api/dto/DeviceRespRuleDTO.java:18；A/context/DeviceContext.java:47 |
| 适配器选择 | B/editor/config/LiteFlowEditorAutoConfiguration.java:38；B/editor/util/SqlConnectFactory.java:21 |
| SQL 加载条件 | 仓库根 doc/数据库设计管理/nacos/liteflow.yaml:15,21,35 |
| 匹配与广播消费 | A/util/RuleRunUtil.java:573；A/event/RuleAlterEventListener.java:32 |
| 审批结果落地 | B/listener/BpmRuleStatusListener.java:41；B/service/bpm/BpmService.java:68,185 |
| 消息入库、反馈及重发 | B/util/RuleUtil.java:195；B/service/bpmnostartmessage/RuleBpmNoStartMessageServiceImpl.java:94,149 |
字段物理结构见 ik_rule 字典。