跳到主要内容

规则链基础配置

1. 关于规则链​

系统为开发者提供了规则链库，可用于自行配置消息的转换、过滤、计算和转发逻辑。

2. 创建规则链​

系统默认提供一条根规则链（Root Rule Chain）供用户使用。通常不建议直接修改根规则链，而是先将其导出，再重新导入为一条新的规则链，并在新规则链上进行修改和配置。

首先按照如下步骤导出根规则链。点击导出后，系统会自动下载一个 JSON 文件。

1730343544790-113.png

然后把导出的配置重新导入系统。点击导入后，系统会直接跳转到新导入规则链的配置页面，此时只需点击右下角的 Apply Change 按钮即可。

重新回到规则链列表后，就可以看到新导入的规则链。

1730344152898-509.png

1730344348542-260.png

3. 修改规则链​

你可以按如下步骤修改规则链的基础信息，例如重命名上一节导入的规则链。

1730344632740-435.png

1730345137320-999.png

1730345353615-959.png

4. 删除规则链​

可以按如下步骤删除新创建的规则链。

注意：系统默认提供的根规则链不能删除。

1730346321550-495.png

5. 配置规则链​

如果需要配置规则链，可按如下步骤进入规则链的配置页面。

1730346571913-889.png

1730346890962-926.png

1730347084731-765.png

1730347231071-931.png

由于之前创建设备时默认使用的是 Root Rule Chain，所以下面的示例都以根规则链中的常用节点为例进行说明。

6. 常用节点说明​

6.1 Filter 节点​

6.1.1 Check fields presence​

该节点用于检查消息体或 metadata 中某些字段是否存在，并根据检查结果分流消息。主要配置项包括：

  • Name：节点名称；
  • Message field names：需要在消息体中校验的字段名；
  • Metadata field names：需要在 metadata 中校验的字段名；
  • Check that all specified fields are present：是否要求所有字段同时存在；
  • Explanation：补充说明。

该节点有两个出口：true 和 false。

1730353965218-437.png

6.1.2 Script​

该节点允许通过编程实现自定义过滤逻辑。配置中最核心的是 Function Filter，函数参数包含 msg、metadata 和 msgType，返回值应为布尔值。

该节点同样有 true 和 false 两个出口。

1730354366308-318.png

6.1.3 Switch​

该节点允许通过代码实现分组和分流。Function Switch 返回一个字符串数组，每个字符串对应一个分发路径。

例如：

if (msg.temperature > 25) {
  return ['High temperature'];
} else if (msg.temperature < 18) {
  return ['Low temperature'];
} else {
  return ['Normal temperature'];
}

这段代码定义了三个出口：High temperature、Low temperature 和 Normal temperature。因此在连接下一个节点时，也要对应创建这些出口标签。

1730355203367-790.png

1730355288161-463.png

6.2 Properties 节点​

6.2.1 Calculate delta​

该节点用于计算当前消息与上一条消息之间的数据差值，并据此调整和分发消息内容。常见配置项包括：

  • Input value Key：要计算增量的字段；
  • Output value Key：计算结果写入消息体时的字段名；
  • Decimals：增量计算精度；
  • Use cache：是否缓存上一条数据；
  • Tell Failure if delta is negative：如果增量为负，是否按失败处理；
  • Add period between messages：是否记录消息间隔；
  • Exclude zero deltas from outbound message：是否过滤掉增量为 0 的输出。

该节点有三个出口：Success、Failure 和 Other。

1730356036784-417.png

6.2.2 Customer attributes​

该节点用于把客户（Customer）的属性值加入到消息 metadata 中，例如取客户属性并映射到新的 metadata 字段中。

如果设备所属客户未配置，则会从 Failure 出口输出。

1730357095598-358.png

1730357340823-311.png

6.2.3 Customer details​

该节点用于把客户详细信息（如国家、城市、地址、邮箱等）加入到消息中，可选择写入 metadata 或写入消息体。

1730357528275-219.png

6.2.4 Tenant attributes / 6.2.5 Tenant details​

Tenant attributes 和 Tenant details 的逻辑与客户属性 / 客户详情类似，只是数据来源改为租户（Tenant）。

1730964386323-616.png

6.2.6 Fetch device credentials​

该节点用于把设备凭据（如密钥、Token 类型）加入消息并传给下游节点。可选择写入 metadata 或消息体。

1730965249482-406.png

6.3 Transformation 节点​

6.3.1 Copy key-value pairs​

用于在 data 与 metadata 之间复制字段。

1730965445070-151.png

6.3.2 Delete key-value pairs​

用于删除 data 或 metadata 中指定字段。

1730965545372-196.png

6.3.3 Rename keys​

用于重命名 data 或 metadata 中的字段。

1730965632561-703.png

6.3.4 Deduplication​

用于在给定时间窗口内进行去重，可配置：

  • 时间间隔；
  • 去重策略（First Message / Last Message / All Messages）；
  • 输出消息类型和队列。

6.3.5 Script​

用于通过代码自定义消息转换逻辑。函数返回值通常为：

{msg: newMsg, metadata: newMetadata, msgType: newMsgType}

6.4 Action 节点​

6.4.1 Math function​

该节点用于执行数学计算。可以选择系统内置函数，也可以配置自定义表达式。参数可来自属性、时序数据、常量、消息体或 metadata。计算结果可写回属性、时序数据、消息体或 metadata。

6.4.2 Create alarm / Clear alarm​

这类节点用于创建或清除告警。可配置：

  • 告警类型；
  • 告警级别；
  • 告警详情内容；
  • 告警触发或清除条件。

6.4.3 Delay​

用于按设定时间延迟消息下发。可以配置固定延时，也可以从消息体 / metadata 动态读取延时时长。

6.4.4 Generator​

用于周期性生成消息，可配置：

  • 消息数量；
  • 时间间隔；
  • 实体类型；
  • 队列；
  • 自定义生成函数。

6.4.5 Log​

用于输出调试日志。你可以通过 Function Log String 自定义日志格式。

6.5 External 节点​

6.5.1 Kafka​

用于把消息转发到 Kafka，可配置：

  • Topic pattern；
  • Key pattern；
  • Bootstrap servers；
  • 重试次数；
  • 批大小；
  • 缓冲时长；
  • acks；
  • Key / Value serializer；
  • 其他 Kafka 属性；
  • 是否把 metadata 写入 Kafka headers。

6.5.2 MQTT​

用于把消息转发到 MQTT Broker，可配置：

  • Topic pattern；
  • Host；
  • Port；
  • Connection timeout；
  • Client ID；
  • Clean session；
  • Retained；
  • Enable SSL；
  • Credentials（Anonymous / Basic / PEM）。

6.5.3 REST API Call​

该节点用于把消息转发到外部 REST API。通常需要配置：

  • 请求地址；
  • 方法类型；
  • 请求头；
  • 请求体映射；
  • 超时；
  • 鉴权方式。

7. 建议​

  • 不要直接在 Root Rule Chain 上进行破坏性改动；
  • 新规则链建议先从导入根规则链开始；
  • 复杂逻辑优先通过脚本节点验证，再逐步拆分到多个通用节点；
  • 修改规则链后记得检查出口路径和下游连接是否完整。