发表于 2018-09-12

| 分类于 Edge Computing

| 0

| 阅读次数:

SupportingServices - RulesEngine：

• Refrence Implementation
• Rules Engine as Export Service Client
• Rules Engine Direct Connect to Core Data
• Rules Client and High Level Interaction Diagram
• Rules (Defined), and Data Model
• Rules Engine Configuration
• Data Dictionary

1. Refrence Implementation

Rules Engine微服务提供了参考实现，边缘事件触发机制。Rules Engine服务能够监控传入的传感器或设备数据(监控数据是否处于目标范围内)，以及触发设备即时驱动。因此，Rules Engine在网络边缘处或附近提供“智能”，以获得更快的响应时间。

该实现使用Drools（https://www.drools.org/）规则引擎作为核心。Drools是JBoss社区提供的开源规则引擎。这种微服务可以被第三方提供的许多其他边缘分析功能替换或扩充。

2. Rules Engine as Export Service Client

参考实现Rules Engine为一种自动导出服务客户端。当服务启动时，它会自动调用Export Client Registration microservice，将自身注册为来自Core Data的所有设备和传感器读书数据的客户端。作为Export Service客户端，参考实现rules engine通过Export Distribution微服务接收所有事件和数据。基于数据而言，参考实现rules engine监视通过Export Distribution微服务接收的每个事件和数据，并且rules engine 通过Core Command微服务触发对设备的动作（其随后通过Device Services 传送请求与实际设备通信）。

3. Rules Engine Direct Connect to Core Data

在对时间非常敏感的用例或环境中，连接的“对象”正在生成大量数据。因此，将Rules Engine微服务与Core Data的数据直接相连也是合适的。也就是说，不在通过Export Servies，直接调用Rule Engine Service。

rules engine已针对此选项进行了编程。默认情况下，rules engine 微服务将自身注册为export service的客户端。可以关闭此自动注册，并且规则引擎可以直接连接到Core Data的ZeroMQ发布数据。注意：由于Core Data中的ZeroMQ管道是一种发布 - 订阅机制，它允许多个订阅者。当规则引擎作为订阅者连接时，Core Data实际上同时发布给两个客户端或订阅者：Export Services和Rules Engine。为了将规则引擎与导出服务（作为客户端）断开连接并将其直接连接到Core Data，必须更改以下规则引擎微服务配置参数（在application.properties中找到）：

export.client=true    # this is normally false by default and is the indication to the Rules Engine micro service to register itself with the Export Services
export.zeromq.port=5563    # this port is set to 5566 when connecting to the ZeroMQ pipe out of Export Services.
export.zeromq.host=tcp://[core data host]    # this is set to the export distro host when connecting to the ZeroMQ pipe out of Export Services

4. Rules Client and High Level Interaction Diagram

Rules Engine微服务附带一个RESTful服务，可以添加和删除新规则。RESTful API允许将在JSON中定义的新规则动态添加到规则引擎（通过REST POST）。提供的JSON数据由微服务转换为Drools规则文件（.drl文件）。每个规则都必须与用于标识规则的唯一名称相关联，Drool文件包含此标识符。同时，也允许请求通过名称删除规则。

注意：由于Drools中的问题，删除的规则仅清空其内容。规则的名称（以及代表它的文件）仍在系统中。因此，在rule engine微服务停止并且物理删除空Drool文件之前，不能重用规则名称。

5. Rules (Defined), and Data Model

Rules Engine微服务直接通过REST API或间接使用客户端UI提供规则。

规则由4部分定义：name，log entry，condition 和 action。

该名称唯一标识规则。

• log entry

日志条目或简称日志是，在满足规则条件并触发操作时，发送到日志的文本。

• condition

该条件指定要监控的数据（来自通过Export Services 提供的事件/数据）。具体而言，规则的条件元素指定要监视设备的设备ID或名称，并完成值检查（或简单地“检查”），即对该设备上收集的传感器值检验。设备ID或名称必须与Core Data 发送到Export Service 的Event对象中指定的设备ID或名称匹配，然后转发规则引擎服务（通过ZeroMQ）。

值检查需指定监控传感器的参数，测试以应用于该参数。ValueCheck参数必须与CoreData提供的事件关联的读取名称之一匹配（并且也是合法的ValueDescriptor名称）。例如，在恒温器传感器上，Reading可能会报告当前温度。因此，读取名称将是“temperature”，并且为了规则，测试来自该传感器读数的数据，对同一设备的值检查也必须包含“温度”参数。operand1、operation和operand2必须在参数范围指定一个等式，以此决定是否触发行为。例如，

parameter:  temperature

operand1:  value

operation:  >

operand2: 72

因为事件读取中的数据可以以字符串形式存在，ValueCheck operands 可以且应该使用Java语法指定，以创建用于比较的适当类型数据。如果温度读数在Core Data中表示为字符串，则相同的ValueCheck将指定如下：

parameter:  temperature

operand1:  Integer.parseInt(value)

operation:  >

operand2: 72

最后，规则中的行为需指定: 在指定的设备或传感器上触发哪个命令，以及将哪些数据或参数发送到设备。实际调用是通过REST形式的Core Command微服务完成的。因此，该操作必须指定以下项：

• 要调用的设备标识符(per Metadata)
• 要对设备执行的命令标识符(per Metadata)
• 将数据作为Command调用的一部分进行提供

因此，作为调用的一部分提供的数据是要在Command POST调用的主体中提供的JSON数据。action属性的示例如下：

device：56325f7ee4b05eaae5a89ce1（元数据中设备或传感器的标识符）

command：56325f6de4b05eaae5a89cdc（每个元数据与设备关联的命令ID）

body：{“value”：“3”}（REST消息体中提供的JSON数据）。

在JSON中创建规则以通过规则引擎客户端提交POST时，整个规则将表示如下所示：

{"name":"motortoofastsignal", "condition": {"device":"562114e9e4b0385849b96cd8","checks":[ {"parameter":"RPM", "operand1":"Integer.parseInt(value)", "operation":">","operand2":"1200" } ] }, "action" : {"device":"56325f7ee4b05eaae5a89ce1","command":"56325f6de4b05eaae5a89cdc","body":"{\\\"value\\\":\\\"3\\\"}"},"log":"Patlite warning triggered for engine speed too high" }

6. Rules Engine Configuration

SupportingServices-RulesEngine

7. Data Dictionary

参考文献
SupportingServices-RulesEngine