数据目的地
时序数据库(TSDB)
如需视频教程，请点击这里。
写时序数据可以划分成两个步骤：
- 对消息依据SQL进行过滤和变换
- 根据结果消息以指定的方式写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做如下默认的纠正：
- metric：长度不够时，补"_"，超长部分，截断；
- field name：长度不够时，补"_"，超长部分，截断；
- tag key：非法字符替换成"_"；首字符不为字母，补"L"；超长部分，截断；
- 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变换后的消息，应该包含如下几个字段
- metric: 指明数据写到TSDB的度量名
- value: 数据部分，该字段也可以用'_value'代替
- timestamp: 写入时序数据库的时间戳，该字段也可以用'_timestamp'代替
- 一个或者多个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的实例，具体操作步骤如下：
-
选择数据目的地为关系性数据库，点击创建连接配置，如下图所示
-
配置中配置需要规则引擎写入的RDS信息，其中名称可以任意填写唯一即可，主要用来标识这个配置的名称
- 配置结束后，下次使用可以选择已经配置好的连接配置，然后选择这个配置对应的库下面的某张表即可。
现在写入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步骤：
-
创建"连接配置"(物联网console → 平台通用功能 → 连接配置)，其中一个连接配置对应一个DB。
-
创建规则引擎
- 订阅物接入(设备型)的"$baidu/iot/shadow/{devicename}/update/snapshot"主题
-
提取其中的压力("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" } } }
-
- 订阅物接入(设备型)的"$baidu/iot/shadow/{devicename}/update/snapshot"主题
-
添加“关系型数据库”目的地
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。
步骤：
-
创建"连接配置"(物联网console → 平台通用功能 → 连接配置)
因为一个"连接配置"对应一个DB。我们可以简单复用上述INSERT模式中创建的连接配置。
-
创建规则引擎
-
订阅物接入(设备型)的"$baidu/iot/shadow/{devicename}/update/snapshot"主题
-
构建"_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 } } }
-
-
-
添加“关系型数据库”目的地
物接入(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中去。