规则引擎审核需要多久：聊聊规则引擎的调研及实现全过程
规则引擎审核需要多久：聊聊规则引擎的调研及实现全过程本来这部分应该是最理想型 奈何参考了相关的源码 扩展定制并不容易之前有用过beautifyfly处理过相关流程图多泳道组合式流程显示 后来在vue扩展封装时发现X6及XFlow的封装扩展性都挺好 且相关的样例很完美的解决了运行态、保存、节点属性等问题 规则引擎用例mxgraph 作为老牌的流程图等绘制组件，可能名声不显 但提起processOn基本应该都听过 相关功能就是基于此组件进行开发完成的 这个组件也进行深入的集成改造处理 于是我用Vue尝试了相关的初步搭建和处理，在过程中发现交互部分有一些交互硬伤需要进行比较多的完善和修改 时间上来不及 且美观度需要进行较大的调整，且文档说明不够规范清晰
摘要本期主要以规则引擎业务实现为例 陈述在陌生业务前如何进行业务深入、调研、技术选型、设计及实现全过程分析 如果你对规则引擎不感冒、也可以从中了解一些抽象实现过程。
诉求从硬件采集到的数据提供的形式多种多样 会有库直连 MQtt传输 其他设备网关传输，接口API传输等多种形式 且传输的数据结构不具备通用性，即数据运行时为变化状态 进行的操作包含数据预处理、逻辑判断、预警、保存等诉求，扩展诉求包含函数、异常处理、完成监控、任务调度等
业务深入这个过程主要结合需求和现状进行分析
- 需求主要指当下最紧要需要解决的问题及后续可能存在的扩展进行初步的评估 界定清楚需求主干及优先级 包括时间要求等
- 现状主要指当前人员支持情况及配置人员技术掌握情况进行分析 便于结合人员及技术情况作为评判依据，有效的组合人员的“刀尖”共力去完成任务
- 业务深入 如果这项工作之前没有相关的设计开发经验 通过常规的沟通很容易对当前业务的复杂度及逻辑产生误判 闭门造车、想当然等虚假结果导向，因此业务深入 不仅仅指的是理解业务 还需要多找一找相关处理的开源项目或是理论，充分的理顺要点及过程后 相关的设计及开发才不会偏离太远。
以thingsboard为例先简单理解设备网关的概念 这对后续的规则引擎处理有引导作用
规则引擎用例
- 在保存到数据库之前对接收的遥测数据或属性进行验证和修改。
- 将遥测或属性从设备复制到相关资产以便可以汇总遥测。例如：可以将多个设备中的数据汇总到相关资产中。
- 根据定义的条件对报警进行创建、更新、清除。
- 根据设备生命周期事件触发操作。例如：如果设备处于在线/离线状态，则创建警告。
- 加载所需的其他处理数据。例如：在客户设备或租户属性中定义的设备的playload温度阈值。
- 调用外部系统的REST API。
- 发生复杂事件时发送电子邮件并使用“电子邮件模板”中其他实体的属性。
- 在事件处理期间要考虑用户的偏好。
- 根据定义的条件进行RPC调用。
- 集成第三方消息队列等。
- node-red 同样的相类似的thingsboard及jetlinks也均是基于node-red的前端进行改造重构开发的
- IoTSharp
- 相关Mqtt网关消息推送 经过对以上开源相关软件的分析 多多少少均存在一些制约因素 不符合预期的扩展改造目的
- thingsboard 目前代码耦合性比较高 牛身上取牛心，少不了庖丁解牛，规则引擎只是其中一部分 (国外软件使用习性不同 有些点不好理解) angularjs java
- Node-RED 配置交互比较清晰 也有可进行调度 但用的是js做的服务端 移植比较麻烦。
- IoTSharp 与物联网网关匹配 经过验证 接收网关数据，一些常规操作可行 但框架用的是angularjs netcore 与中台技术线不匹配
mxgraph 作为老牌的流程图等绘制组件，可能名声不显 但提起processOn基本应该都听过 相关功能就是基于此组件进行开发完成的 这个组件也进行深入的集成改造处理
于是我用Vue尝试了相关的初步搭建和处理，在过程中发现交互部分有一些交互硬伤需要进行比较多的完善和修改 时间上来不及 且美观度需要进行较大的调整，且文档说明不够规范清晰
之前有用过beautifyfly处理过相关流程图多泳道组合式流程显示 后来在vue扩展封装时发现X6及XFlow的封装扩展性都挺好 且相关的样例很完美的解决了运行态、保存、节点属性等问题
本来这部分应该是最理想型 奈何参考了相关的源码 扩展定制并不容易
bpmn-js之所以会参考该项 主要考虑到流程与规则主干部分其实是一致的，只不过一个是人工驱动、一个是程序全驱动
- 当前考虑组件范围：物联网规则引擎、业务编排、流程编排
- 优先实现物联网规则引擎 同时在设计开发层间兼容预留业务编排及流程编排的扩展性
- 共性：基础公共逻辑 节点顺序及父子关系无关性
- 输入特性：global.payload（全局变量）、flow.payload（流程变量）、msg.payload(入参数变量)、（环境变量）、（表达式）
- 节点属性：每个节点均有其特殊属性，如:mqtt、swich判断节点均有其特殊属性配置 可与共性分开处理
- 业务编排:（重点在http及数据库交互特点不同上）
- 流程编排:(现有开源等相关流程引擎集成开发时的槽点不太适合现有多元化改造) 可考虑自实现，满足当前业务简单实现，便于后期自动化处理时的扩展调整。
- 配置还原问题：需要处理前端配置的线条等问题
- 服务端处理需求关心的是节点顺序及节点属性配置，全局配置等内容 因此：节点和线条需要区分类型，线条数据对服务端没意义，但在显示时有意义
- debug模式、数据执行过程还原 调试问题。
- 具体执行时执行日志监控问题
- 前端部分流程及配置关系初步清晰后，服务端flow结构化数据，对整体结构实现保存、查询、根据结构化数据执行逻辑顺序。
- 节点处理，细化节点属性编辑 服务端实现节点功能执行，输入 输出，后续根据需要依次抽提业务场景，实现相关节点功能。
- 关于页面调试预演逻辑处理细化 涉及整体的执行日志输出及执行状态返回。
- 关于输入端讨论：其他同类型规则引擎，目前仅考虑物联网网关（即Mqtt） 实际物联网的接入场景比较多，是否考虑介入端的多样性 若都放入数据中台 是否对一些个例项目不甚友好（结合当前能源项目）
相关节点设置
-- 流程表
DROP TABLE IF EXISTS dc_flow;
CREATE TABLE dc_flow(
flow_id VARCHAR(32) NOT NULL COMMENT '流程标识'
flow_name VARCHAR(255) COMMENT '流程名称'
cron VARCHAR(255) COMMENT '任务调度表达式'
flow_desc VARCHAR(255) COMMENT '流程描述'
parent_flow_id VARCHAR(255) COMMENT '父流程节点ID'
flow_payload VARCHAR(255) COMMENT '预设值参数验证'
flow_type INT COMMENT '流程类型'
flow_type_name VARCHAR(255) COMMENT '流程类型名称'
last_execute_time VARCHAR(255) COMMENT '上次执行时间'
next_execute_time VARCHAR(255) COMMENT '下次执行时间'
execute_count VARCHAR(255) COMMENT '执行累计次数'
enabled VARCHAR(1) DEFAULT 1 COMMENT '是否生效'
tenant_id VARCHAR(32) COMMENT '租户号'
revision VARCHAR(32) COMMENT '乐观锁'
created_by VARCHAR(32) COMMENT '创建人'
created_time DATETIME COMMENT '创建时间'
updated_by VARCHAR(32) COMMENT '更新人'
updated_time DATETIME COMMENT '更新时间'
PRIMARY KEY (flow_id)
) COMMENT = '流程';
-- 流程节点表
DROP TABLE IF EXISTS dc_flow_node;
CREATE TABLE dc_flow_node(
node_id VARCHAR(32) COMMENT '节点标识ID'
node_name VARCHAR(255) COMMENT '节点名称'
node_type VARCHAR(255) COMMENT '类型（区分节点，线条）'
node_code VARCHAR(90) COMMENT '节点类型(程序判断编码)'
parent_node_id VARCHAR(32) COMMENT '父节点ID'
node_desc VARCHAR(255) COMMENT '节点描述'
sequence INT COMMENT '节点顺序'
json_data VARCHAR(900) COMMENT '节点属性'
source_id VARCHAR(255) COMMENT '源节点（主要针对线条）'
target_id VARCHAR(255) COMMENT '目标节点（主要针对线条）'
position_x DECIMAL(24 2) COMMENT '节点x布局点位'
position_y DECIMAL(24 2) COMMENT '节点y布局点位'
zindex VARCHAR(255) COMMENT '层级深度'
category_name VARCHAR(255) COMMENT '预留分组名称'
category_id VARCHAR(255) COMMENT '预留分组'
shape VARCHAR(255) COMMENT '形状（前端）'
tenant_id VARCHAR(32) COMMENT '租户号'
revision VARCHAR(32) COMMENT '乐观锁'
created_by VARCHAR(32) COMMENT '创建人'
created_time DATETIME COMMENT '创建时间'
updated_by VARCHAR(32) COMMENT '更新人'
updated_time DATETIME COMMENT '更新时间'
PRIMARY KEY (node_id)
) COMMENT = '流程节点表';
-- 流程执行节点过程
DROP TABLE IF EXISTS dc_flow_item;
CREATE TABLE dc_flow_item(
item_id VARCHAR(255) COMMENT '流程节点ID'
item_name VARCHAR(255) COMMENT '节点名称'
flow_id VARCHAR(32) COMMENT '流程id'
flow_node_id VARCHAR(32) COMMENT '流程节点id'
parent_node_id VARCHAR(32) COMMENT '父节点执行id'
state VARCHAR(1) COMMENT '执行状态'
start_time DATETIME COMMENT '开始时间'
end_time DATETIME COMMENT '结束时间'
telemetry_data_id VARCHAR(32) COMMENT '过程数据id'
node_payload VARCHAR(255) COMMENT '节点执行属性'
content VARCHAR(255) COMMENT '执行内容备注'
tenant_id VARCHAR(32) COMMENT '租户号'
revision VARCHAR(32) COMMENT '乐观锁'
created_by VARCHAR(32) COMMENT '创建人'
created_time DATETIME COMMENT '创建时间'
updated_by VARCHAR(32) COMMENT '更新人'
updated_time DATETIME COMMENT '更新时间'
PRIMARY KEY (item_id)
) COMMENT = '流程执行节点过程';
复制代码总结
目前相关的调研及前端部分的实施已经初步完成 相关实施按照过程及任务拆解已初步得到验证实施的可行性 这其中也考虑了比较多服务端因素 最终确定为react java组合的形式 之所以没再坚持vue主因是该页相对比较独立 技术线统一其实没那么重要 优先以验证可行性及执行度为准则，另外一方面考量就是节点的属性编辑交互性较强，综合权衡之后还是决定背靠antd pro-compoment去加快这个实施过程。
另外所有相关的调研内容都是实际挨个进行部署测试功能验证过给出的相关分析，所以选型其实要做的工作是包含有验证的 只有过程丰满，才能将目标和结果的差距缩减到最短。 后续相关的细节及内容会在随后的更新适时补充，因篇幅和时间的限制 一些细节和问题也没完全阐述 有疑问可在评论中讨论.
