规则引擎Rule Engine

    数据目的地

    更新时间：2019-06-14

    时序数据库(TSDB)

    如需视频教程，请点击这里。

    写时序数据可以划分成两个步骤：

    1. 对消息依据SQL进行过滤和变换
    2. 根据结果消息以指定的方式写TSDB

    一个输入MQTT消息经过第一步的过滤和变换后的结果消息，如果符合下述几种格式中的任何一种，或者多种，则消息会被写进TSDB。如果一个结果消息符合多种格式，则会以多种方式并行地写TSDB。

    每种格式，都需要在结果消息中明确的指定如下几个参数:

    • 度量(metric)，一个TSDB下面可以有多个度量，一个度量相当于MySql数据库中的表
    • 时间戳，每个数据点写入TSDB均需要明确地指定时间戳。部分格式可以指定输入消息时间戳的格式，其他情况下，系统会自动识别下述几种常见的时间戳格式
    • 域，如果不是默认域(value)的话，需要指定将数据存入哪个域。一个度量下面可以有多个域，一个域相当于MySql表中的字段
    • 值，就是写进TSDB的真正的数据。值分数值型、字符串型、以及byte型。特别说明，如果结果消息本身是字符串类型，但是可以理解成数值类型，那么可能优先以数值类型写。同一个度量同一个域，写的数据类型不能变
    • 一个或者多个tag, tag用来区分同一个metric下的数据，方便从TSDB中检索数据。例如，为了区分device_temperate度量下，温度是属于那个设备的，可以增加一个名为device的tag，tag的值为每个设备的编号

    时序数据库的metric, tag和域均有相应的命名规范。

    为了使数据符合TSDB的命名要求，规则引擎在如下几种情况，对metric, field name, tag name, tag value做如下默认的纠正：

    1. metric：长度不够时，补"_"，超长部分，截断；
    2. field name：长度不够时，补"_"，超长部分，截断；
    3. tag key：非法字符替换成"_"；首字符不为字母，补"L"；超长部分，截断；
    4. tag value：长度不够时，补"_"，超长部分，截断；

    系统能识别的常用时间戳格式如下所示：

    {"ts":1523427241000}
{"ts":1523427241}
{"ts":"1523427241000"}
{"ts":"1523427241"}
{"ts":"2018-03-25T07:05:26.847Z"}
{"ts":"2018-03-25 07:05:26.847Z"}
{"ts":"2018-03-25T07:05:26Z"}
{"ts":"2018-03-25 07:05:26Z"}
{"ts":"2018-03-25T07:05:26.847"}
{"ts":"2018-03-25 07:05:26.847"}
{"ts":"2018-03-25T07:05:26"}
{"ts":"2018-03-25 07:05:26"}

    根据消息格式的不同，以及是否写多域，写时序数据库分如下几种模式。

    单点(默认域)

    该方式将您的一个MQTT消息转化成一个点，写到某个度量(metric)中的默认域(value)中去。经过SQL变换后的消息，应该包含如下几个字段

    1. metric: 指明数据写到TSDB的度量名
    2. value: 数据部分，该字段也可以用'_value'代替
    3. timestamp: 写入时序数据库的时间戳，该字段也可以用'_timestamp'代替
    4. 一个或者多个tag: 任意名字，key作为tag的名字，value作为tag的值。

    举例

    结果消息的格式应该类似如下：

    {
	"metric": "device_temperature",
	"value": 35.6,
	"timestamp": 1534975332,
	"deviceid": "dev001", 
	"factory": "shanghai"
}

    上述消息中，deviceid, factory均作为tag。

    在实际中，设备上传的消息很可能不符合上述格式，此时可以通过查询字段的SQL语句来将消息变换成合法的格式。假如设备上传消息如下：

    {
	"temperature": 35.6,
	"ts": 1534975332,
	"deviceid": "dev001",
	"factory": "shanghai"
}

    则需要类似如下的SQL来转换：

    'device_temperature' AS metric, temperature AS `value`, ts AS `timestamp`, deviceid, factory

    'device_temperature' AS metric: 在结果消息中新增一个名为metric的字段，值为字符串'device_temperature'；

    temperature AS `value`: 通过AS语法，将temperature字段重命名成value；注意，value是SQL中的保留字，因此需要用重音符(back tick)引起来；这一句也可以写成: temperature AS _value, _value不是保留字，因此不需要重音符；

    ts AS `timestamp`: 将ts重命名成timestamp。注意，timestamp也是保留字，因此也需要重音符引起了。这句也可以写成：ts AS _timestamp；

    deviceid: 将输入消息中的deviceid SELECT过来，名字不变。

    factory: 将输入消息中的factory SELECT过来，名字不变。

    数组(默认域)

    该方式适合处理待写入数据位于JSON数组的情况，其他字段如metric, timestamp, tag可以在数组内，也可以在数组外。数据写入默认域(value)。

    该方式需要在结果消息中包含一个名为"_TSDB_META"的字段，描述以何种方式写TSDB。该字段描述了：

    • data_array: 待处理数组的JSON路径
    • value_field: 数据在数组中的相对路径
    • global_metric或者point_metric: metric的路径，如果metric在数组中，则用point_metric表示，每个点使用不同的metric；如果在数组外，则用global_metric表示，所有点使用同一个metric
    • global_time或者point_time: 时间戳的路径，如果时间戳在数组中，则用point_time表示，每个点使用不同的时间戳；如果在数组外，则用global_time表示，所有点使用相同的时间戳
    • global_tags和point_tags: tag的路径，如果tag在数组中，则用point_tags.tagX表示，每个点使用不同的tag；如果在数组外，则用global_tags.tagX表示，所有点使用相同的tag。其中tagX中的X为一个数字下标，如tag1, tag2, tag3等，不同的tag用不同的下标。当然，如果数据点既有独立的tag也有共同的tag，那么也可以point_tags和global_tags共存
    • 时间戳格式(可选)，如果时间戳为非标准格式，可以指定时间戳的格式，方便系统识别时间戳。在_TSDB_META.time_format字段中指定时间戳格式，如:"yy-MM-dd HH:mm:ss"。

    举例

    结果消息的格式应该类似如下：

    {
	"data": {
		"arr":[{
			"val": 23.4,
			"ts": 1534975332
		},{
			"val": 34.1,
			"ts": 1534975337
		}]
	},
	"deviceid": "device002",
	"factory": "shanghai",
	"name": "mymetric",
	"_TSDB_META": {
		"data_array":"data.arr",
		"value_field":"val",
		"point_time":"ts",
		"global_metric":"name",
		"global_tags":{
			"tag1": "deviceid",
			"tag2": "factory"
		}
	}
}

    假如设备上传的消息格式如下：

    {
	"data": {
		"arr": [{
			"val": 23.4,
			"ts": 1534975332
		}, {
			"val": 34.1,
			"ts": 1534975337
		}]
	},
	"deviceid": "device002",
	"factory": "shanghai"
}

    希望将data.arr这个数组的每个元素，val作为值，ts作为时间戳写进TSDB，则可以通过如下的SQL语句，使之符合数组的写入格式：

    *, 'mymetric' AS name, 'data.arr' AS _TSDB_META.data_array, 'val' AS _TSDB_META.value_field, 'ts' AS _TSDB_META.point_time, 'name' AS _TSDB_META.global_metric, 'deviceid' AS _TSDB_META.global_tags.tag1, 'factory' AS _TSDB_META.global_tags.tag2

    其中

    *：表示将输入消息的各个字段都SELECT过来

    'mymetric' AS name： 插入一个名为name, 值为'mymetric'的字段，方便后面用来作为metric

    'name' AS _TSDB_META.global_metric：将前面生成的name字段，用来作为全局的metric

    'ts' AS _TSDB_META.point_time：将数组中名为ts的字段，作为各个点的时间戳

    'deviceid' AS _TSDB_META.global_tags.tag1：将消息的deviceid字段，作为一个全局的tag

    整个对象(多度量默认域)

    适合将某个JSON对象下面的每个数值类型字段分别写到TSDB，字段名为metric，域为默认域(value), 值为数据。

    该方式需要在结果消息中包含一个名为"_TSDB_META_v2"的字段，描述以何种方式写TSDB

    • metric_nodes: 待处理对象的JSON路径
    • ts: 时间戳的路径
    • tags: 一个或者多个tag的路径
    • 时间戳格式(可选)，如果时间戳为非标准格式，可以指定时间戳的格式，方便系统识别时间戳。在_TSDB_META_v2.time_format字段中指定时间戳格式，如:"yy-MM-dd HH:mm:ss"。

    举例

    结果消息的格式应该类似如下：

    {
     "reported": {
         "memoryFree": 32,
         "cpuIdle": 87.3
     },
     "sys_time": 1532488110931,
     "deviceName": "myDeviceName",
     "_TSDB_META_v2": {
         "metric_nodes": {
             "node1": "reported"
         },
         "ts": "sys_time",
         "tags": {
             "tag01": "deviceName"
         }
     }
}

    如果设备上传的消息格式如下:

    {
     "reported": {
         "memoryFree": 32,
         "cpuIdle": 87.3
     }
}

    如果需要把reported对象下面的每个数值类型的属性（字符类型会被忽略）写入TSDB，可以通过如下SQL将消息变换成合法的格式：

    *,
CURRENT_TIMESTAMP AS sys_time,
'myDeviceName' AS deviceName,
'reported' AS _TSDB_META_v2.metric_nodes.node1,
'sys_time' AS _TSDB_META_v2.ts,
'deviceName' AS _TSDB_META_v2.tags.tag01

    其中，CURRENT_TIMESTAMP AS sys_time 这一句是将系统当前时间作为sys_time字段，方便后面作为写TSDB的时间戳。如果一个消息中，有多个对象需要写入，可以增加类型如下语句:

      'another_object' AS _TSDB_META_v2.metric_nodes.node2,
  'another_object2' AS _TSDB_META_v2.metric_nodes.node3
  ...

    固定结构(多域写入)

    多域写入方便将多个数据，当作完整的一组数据写入TSDB，好比MySql中一行中的多个字段，读取的时候可以一起返回。典型的例子有经纬度数据。该方式适合JSON格式相对固定的消息，并且可以精准控制哪些字段存TSDB。

    该方式需要在结果消息中包含一个名为"_TSDB_META_v3"的字段，描述以何种方式写TSDB，指明如下几个参数：

    • ts: 时间戳路径
    • metric: 度量的路径
    • tags: 一个或者多个tag的路径
    • fields: 每个域在消息中的路径

    举例

    结果消息的格式应该类似如下：

    {
     "ts": 1531929753,
     "carid": "car0001",
     "gps": {
         "longitude": 121.34,
         "latitude": 30.12
     },
     "bin":"010aff",
     "metric": "carlocation",
     "_TSDB_META_v3": {
         "ts": "ts",
         "metric": "metric",
         "tags": {
             "tag1": "carid"
         },
         "fields": {
             "field1": "gps.longitude",
             "field2": "gps.latitude",
             "hexAsBytesField0": "bin"
         }
     }
}

    如果设备上传的消息格式为：

    {
     "ts":1531929753,
     "carid":"car0001",
     "gps": {
         "longitude": 121.34,
         "latitude": 30.12
     },
     "bin":"010aff"
}

    需要把gps下面的longitude和latitude分别当作两个域，写入到名为carlocation的metric中去；把bin字段的HEX String表示的二进制数据，以bytes的方式写TSDB，则可以通过如下SQL语句进行变换：

    *,
'carlocation' AS metric,
'ts' AS _TSDB_META_v3.ts,
'metric' AS _TSDB_META_v3.metric,
'carid' AS _TSDB_META_v3.tags.tag1,
'gps.longitude' AS _TSDB_META_v3.fields.field1,
'gps.latitude' AS _TSDB_META_v3.fields.field2,
'bin' AS _TSDB_META_v3.fields.hexAsBytesField0

    单点(非默认域)

    如果多个域的数据分别上传，则需要通过该方式把一个点的数据写到指定域中去。

    该方式需要在结果消息中包含一个名为"_TSDB_META_v4"的字段，描述以何种方式写TSDB，

    指明如下几个参数：

    • ts: 时间戳
    • metric: 度量名称
    • field: 域的名字
    • value: 值
    • tags: 一个或者多个tag

    举例

    结果消息的格式应该类似如下：

    {
     "_TSDB_META_v4": {
         "metric": "DeviceTemperature",
         "field": "temperature",
         "value": 34.6,
         "timestamp": 1532483765,
         "tags": {
             "deviceid": "IMEI201807_002"
         }
     }
}

    说明，_TSDB_META_v4对象与其他格式不同，他不引用外部的路径，而是最终的数据。 假如设备上传的消息格式如下：

    {
     "ts":1532483765,
     "deviceid":"IMEI201807_002",
     "temperature": 34.6
}

    需要把temperate的数值写入到名为temperature的域，而不是默认的value域，则可以通过如下的SQL进行变换：

    'DeviceTemperature' AS _TSDB_META_v4.metric,
'temperature' AS _TSDB_META_v4.field,
temperature AS `_TSDB_META_v4.value`,
ts AS `_TSDB_META_v4.timestamp`,
deviceid AS _TSDB_META_v4.tags.deviceid

    不固定结构(多域写入)

    对于像物影子的消息，每次上报的属性名称和个数不固定，但希望将某个对象下面所有的字段都以多域的方式写TSDB。Bool类型字段默认转化成0和1存储，可选地开启存储字符串类型字段。

    该方式需要在结果消息中包含一个名为"_TSDB_META_v5"的字段，描述以何种方式写TSDB，指明如下几个参数：

    • ts: 时间戳
    • metric: 度量名
    • tags: 一个或者多个tag
    • fields: 该对象下面的每个子属性分别作为不同的域，写TSDB
    • saveStringFields: 可选bool字段，指明是否将fields下面的字符串属性也存TSDB，默认为false

    举例

    结果消息的格式应该类似如下：

    {
    "_TSDB_META_v5": {
        "metric": "mymetric",
        "ts": 1535865771,
        "fields": {
            "temperature":25.6,
            "status":true,
			"pressure":"high"
        },
        "tags": {
            "deviceName": "device001",
			"model": "2018"
        },
		"saveStringFields": true
    }
}

    假设规则引擎订阅物管理主题$baidu/iot/shadow/+/update，收到类似如下的消息：

    {
	"reported": {
		"temperature":25.6,
		"status":true,
		"pressure":"high"
	}
}

    以系统当前时间作为时间戳，从输入主题中提取影子名作为tag，则可以通过如下的SQL进行变换：

    reported AS _TSDB_META_v5.fields, CURRENT_TIMESTAMP AS _TSDB_META_v5.ts, true AS _TSDB_META_v5.saveStringFields,  'shadow' AS _TSDB_META_v5.metric, SUBSTRING(topic(), 19, position('/update' in topic()) - 19) as _TSDB_META_v5.tags.deviceName

    关系型数据库（RDS）

    写入关系型数据库需要首先在百度的RDS付费并购买相应的实例，以及建好相应的库和表。

    注意：表的列名必须和IoT Hub中的json格式的payload的各个key一一对应，并且大小写敏感，否则无法写入。

    具体RDS的操作请参考RDS相关的产品文档。

    第一次配置使用RDS需要先配置RDS的实例，具体操作步骤如下：

    1. 选择数据目的地为关系性数据库，点击创建连接配置，如下图所示

    2. 配置中配置需要规则引擎写入的RDS信息，其中名称可以任意填写唯一即可，主要用来标识这个配置的名称

    3. 配置结束后，下次使用可以选择已经配置好的连接配置，然后选择这个配置对应的库下面的某张表即可。

    现在写入RDS支持insert和upsert：

    • insert：适合记录所有消息。比如一个传感器不断上传自己的状态，如果需要将所有数据都写入RDS就适合用insert。其中这里面每一行数据有一个自增的主键。具体可以参考控制台里的sql模版。
    • upsert：适合更新某一个设备的属性。规则引擎如果发现一个新的主键，会insert，如果这个主键已经存在，则更新整行数据。具体适合一些需要反向查询的场景，比如我们有100个传感器，每个传感器有5个属性，我们需要定期按照某个属性的特征，反向查询传感器的ID，这种就比较合适用upsert。这种用法相当于把设备的影子按列进行展开。具体可以参考控制台里的sql模版。

    insert应用举例

    在这个示例中，设备会上报两个信息：压力("pressure")和温度("temperature")，我们将设备的数据转存到RDS，以便兼容我们现有的技术栈。

    前提：

    假定已经在RDS创建了一个名为“mysql57”的MYSQL类型实例，并在实例中创建账号("account")及数据库("test_db") 并在DB中创建Table("test_table")如下：

    CREATE TABLE `test_table` (
  `id` int(10) NOT NULL AUTO_INCREMENT,
  `pressure` varchar(40) NOT NULL,
  `temperature` double(10,2) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

    步骤：

    1. 创建"连接配置"(物联网console → 平台通用功能 → 连接配置)，其中一个连接配置对应一个DB。

      image.png

    2. 创建规则引擎

      1. 订阅物接入(设备型)的"$baidu/iot/shadow/{devicename}/update/snapshot"主题 image.png

      2. 提取其中的压力("pressure")和温度("temperature")信息，构建"RDS_META"的格式

        • 物接入(设备型)的"$baidu/iot/shadow/{devicename}/update/snapshot"主题输入如下：

          { "reported": { "temperature":25.6, "pressure":"high" } }

        • 规则引擎SQL如下：

          reported.temperature AS RDS_META.columns.temperature, reported.pressure AS RDS_META.columns.pressure

        • 产出如下：

          { "RDS_META":{ "columns":{ "temperature":25.6, "pressure":"high" } } }

    3. 添加“关系型数据库”目的地

      image.png

    upsert应用举例

    设备上报数据写到RDS里，我们希望根据给定的key，优先选择UPDATE现有记录，没有找到匹配的记录时再进行INSERT操作。这样我们可以简单的通过属性查询到对应的设备，如Select * From table WHERE temperature > 50

    在这种示例中，设备会上报4个字段：temperature(温度), pressure(压力), devicename(设备名称), customerid(用户ID)，其中devicename(设备名称)和customerid(用户ID)作为key

    前提：

    我们在数据库("test_db")中创建Table("upsert_test")如下：

    CREATE TABLE `upsert_test` (
  `id` int(10) NOT NULL AUTO_INCREMENT,
  `devicename` varchar(40) NOT NULL,
  `customerid` int(10) NOT NULL,
  `temperature` double(10,2) NOT NULL,
  `pressure` varchar(40) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `unique` (`devicename`,`customerid`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2944 DEFAULT CHARSET=utf8

    其中`devicename` + `customerid`做为一个组合UNIQUE KEY。

    步骤：

    1. 创建"连接配置"(物联网console → 平台通用功能 → 连接配置)

      因为一个"连接配置"对应一个DB。我们可以简单复用上述INSERT模式中创建的连接配置。

    2. 创建规则引擎

      1. 订阅物接入(设备型)的"$baidu/iot/shadow/{devicename}/update/snapshot"主题

        image.png

      2. 构建"_RDS_META_"的UPSERT格式

        • 物接入(设备型)的"$baidu/iot/shadow/{devicename}/update/snapshot"主题输入如下：

          { "reported": { "temperature":25.6, "pressure":"high", "devicename":"mydevice001", "customerid":2 } }

        • 规则引擎SQL如下：重点在于作为key的`devicename`，`customerid`字段须在Table中建立为一个组合UNIQUE KEY

          reported.temperature AS RDS_META.columns.temperature, reported.pressure AS RDS_META.columns.pressure, reported.devicename AS RDS_META.keys.devicename, reported.customerid AS RDS_META.keys.customerid

        • 产出如下：

          { "RDS_META":{ "columns":{ "temperature":25.6, "pressure":"high" }, "keys":{ "devicename":"mydevice001", "customerid":2 } } }

    3. 添加“关系型数据库”目的地

      image.png

    物接入(IoT Hub)

    将结果消息转发到另外的物接入主题中去，可以是到同一个实例、也可以到另外一个实例；可以是固定主题、也可以动态主题。

    目的地主题可以是任何合法的主题，规则引擎有特权将消息转发到任何主题，但如果您需要订阅该主题，请确保您使用的设备有该主题的订阅权限，有必要时需要去物接入中配置权限。

    固定主题

    结果消息转发到预先定义的固定的主题，主题不能包含通配符:+#。可以选择不同的物接入实例，进而达到跨项目(实例)转发消息的能力。

    动态主题

    目的地主题并不固定，而是通过另外一个SQL语句从输入消息中SELECT出来，因此可以将不同的消息转发到不同的主题中去。该方式只能在同项目(实例)中转发，不能跨实例。

    假如有如下两条消息：

    {
	"device": "device001"
}
{
	"device": "device002"
}

    并且主题选择器为：'destination/' || device，那么系统转发前，通过"SELECT 'destination/' || device"来计算真正的目的地主题，并且将上述两个消息分别转发到destination/device001, destination/device002两个不同的主题中去。其中"||"为字符串串联操作符。

    BIN2JSON

    视输入消息为二进制byte array，将其转化成Hex String，附上元信息，组合并且输出JSON格式消息。如Modbus RTU数据通过DTU透传到云端，可以通过该目的地将消息转化成物解析希望的格式(该格式可以在轮训设置右侧的上传格式中查看)。

    举例

    如果某个设备向MQTT主题/device/dtu/pub/topic发布了二进制消息0103020AFF，规则引擎将输出类似如下的JSON消息：

    {
    "msg":"0103020AFF",
    "_meta_": {
        "topic": "/device/dtu/pub/topic",
        "clientid":"device01",
        "clientip": "/180.2.3.4:51789",
        "qos":0
   }
}
    • msg：为消息内容的Hex字符串表示
    • _meta_.topic：为输入消息的MQTT主题
    • _meta_.clientid：为输入消息的发布者ClientId
    • _meta_.clientip：为输入消息的发布者的IP及端口
    • _meta_.qos：为输入消息发布者发布所使用的QoS

    百度消息服务(Kafka)

    将结果消息转发到指定的Kafka主题。转发的key为null，默认的partitioner，因此，如果您的主题有多个分区，消息会均匀的发送到各个分区中去。

    函数计算(CFC)

    将结果消息作为输入调用指定的函数计算(CFC)，并且可选地将CFC的返回转入另外一个MQTT主题。

    函数计算仅接受JSON格式的输入，因此需要确保结果消息是JSON格式的。

    规则字典

    将结果消息写入到规则字典。规则引擎的结果消息需要包含如下JSON结构：

    	{
		"_DICT_META": {
			"k": "<the key>",
			"v": <the value, of any type>
		}
	}

    _DICT_META.k的值为规则字典的key，必须为字符串类型； _DICT_META.v的值为规则字典的value，类型可以是数值，可以是字符串，也可以是JSON对象；

    举例1 假设规则字典存储的就是简单数值，即一个计数器，每当设备上报的alarm字段为1，则将字典中的计数器加一。

    规则字典内容为：

    key value
    car001 36

    设备上报消息为:

    {
	"id": "car001",
	"alarm": 1
}

    SQL如下：

    SELECT lookup_num(id) + 1 AS _DICT_META.v, id AS _DICT_META.k WHERE alarm = 1

    产出如下：

    {
	"_DICT_META:{
		"k": "car001",
		"v": 37
	}
}

    举例2 假设规则字典存储是一个JSON格式，包含一个计数器和一个告警状态，每当告警状态从0变为1时，则将字典中的计数器加一。

    规则字典内容为：

    key value
    car001 {"cnt":36, "alarm":0}

    设备上报消息为:

    {
	"id": "car001",
	"alarm": 1
}

    SQL如下：

    SELECT CASE alarm WHEN 1 THEN lookup_num(id || '.cnt') + 1 ELSE lookup_num(id || '.cnt') END AS _DICT_META.v.cnt, alarm AS _DICT_META.v.alarm, id AS _DICT_META.k WHERE alarm <> lookup_num(id || '.alarm')

    产出如下：

    {
	"_DICT_META:{
		"k": "car001",
		"v": {
			"cnt": 37,
			"alarm": 1
		}
	}
}

    百度对象存储(BOS)

    将每个结果消息以追加(append)的方式写到百度对象存储(BOS)文件中去，并且以日为单位生成不同的文件。

    文件名的格式如下：

    <uuid>_yyyy-MM-dd_N.ext

    其中uuid为一个随机id; yyyy-MM-dd为当前日期，每天会生成一个新的文件；N为一个0开始的编号，每天从0开始，当一个文件的大小超过5GB时，生成新的文件，编号加一。

    短信(SMS)

    如果需要将结果消息以短信的方式发送，则需要选择一个短信接收人。

    短信接收人是一个组合概念，在平台通用功能下面的短信接收人子菜单中创建。

    短信仅接受JSON格式的输入，并且经过SQL变换后的结果消息需要与短信接收人中的短信模板匹配。

    如果短信模板中有var1, var2两个变量，那么结果短信的JSON需要，并且仅需要包含var1, var2两个key。

    举例

    假如短信模板为：

    物联网设备${devid}的温度值过高，最新值为${temp}

    则结果消息只含有device, 和temp两个key，如：

    {
	"devid": "device01",
	"temp": 34.5
}

    如果设备输入的消息为：

    {
	"deviceid":"device01",
	"temperature": 34.5
}

    则可以通过如下SQL进行变换，使之符合SMS的格式要求：

    deviceid AS devid, temperature AS temp

    规则引擎(RULE)

    规则引擎的消息可以转到不同的规则中去。

    固定的规则引擎

    结果消息转发到预先创建好的规则。

    动态规则引擎

    目的地规则并不固定，而是通过另外一个SQL语句从输入消息中SELECT出来，因此可以将不同的消息转发到不同的规则中去。

    假如有如下一条消息：

    {
	"ruleName":"testRule1",
	"temperature": 34.5
}

    并且动态规则引擎为：ruleName，那么系统转发前，通过"SELECT ruleName"来计算真正的目的地规则，并且将上述消息转发到规则testRule1中去。

    上一篇
    操作步骤
    下一篇
    SQL手册