从案例角度解析建模平台动态规则引擎
源宝导读：明源云ERP建模平台提供了强大的页面联动规则引擎，原来需要编写代码完成的联动控制逻辑，现在只需要点点鼠标，通过配置完成。本文从实际案例的角度出发，介绍原始的代码逻辑如何转化为引擎规则的过程。
一、背景
明源云ERP建模平台提供了强大的规则引擎机制，开发或者实施人员只需要通过简单的界面配置就可以完成必填、显隐、颜色等界面交互控制，从需要代码开发转为界面配置，极大提高了业务的交付效率。
在行业中也存在类似规则配置解决方案，但是大部分支持简单的基于代码转换可视化配置，界面也十分复杂，并且缺少如业务参数、关键字等业务应用场景。所以我们如何深入的结合业务特性并且将界面的学习和使用成本降低到最小，就是我们面临的挑战。
本文从实际案例的角度出发，介绍原始的代码逻辑如何转化为引擎规则的过程。
二、规则引擎整体架构
设计时（Design-Time）：用于规则的可视化配置，配置内容将会存储到配置文件中；
条件配置：规则对应的业务判断逻辑，如“表编辑模式”；
行为配置：将条件绑定到控件对应的组件属性或行为上，如保存按钮在”表单编辑模式“时显示；
元数据（Metadata）
元数据作为设计时和运行时的桥梁，用于存储设计时布局、字段配置、条件配置信息，通过元数据配置文件进行存储，在运行时解析元数据文件输出布局及规则配置；
运行时（Runtime）：解析规则配置，将规则和用户行为绑定， 转化为对应代码可执行逻辑；
解析引擎：将设计时中的规则条件、行为配置等解析为可执行函数，保障执行性能；
事件映射：将组件事件、用户操作等交互行为和规则执行函数绑定，触发事件时执行对应规则逻辑；
执行器：在组件触发事件时构造数据上下文，将上下文对象传递到解析引擎生成的可执行函数中，根据函数执行结果分发到对应组件行为；
三、通过代码实现规则业务
案例：折扣管理中折扣方案应用楼栋或者整栋楼或者单栋楼，涉及到隐藏规则及必填校验规则
“应用范围”为“整个项目”：
“应用范围”为“指定楼栋”：
通过脚本代码如何实现
首先我们尝试将需求转为代码实现设计：
当”应用范围“为”整个项目“时，楼栋名称隐藏，并且取消必填；
当”应用范围“为”指定楼栋”时，楼栋名称显示，楼栋名称为必填。
假设我们通过代码来实现上述场景的逻辑，首先我们会订阅“应用范围“的值更改事件，在事件中判断应用范围为”指定楼栋“时设置楼栋名称显示及必填。
// 订阅应用范围值更改事件
usedScope_valuechanged:function(e){// 获取楼栋名称控件var bldList = appform.get('BldList');switch(e.value){case 'all': // 应用范围：整个项目bldList.hide();bldList.setRequired(false);break;case 'one': // 应用范围：指定楼栋// 显示楼栋列表bldList.show();// 楼栋列表设置为必填bldList.setRequired(true);break;}
}
四、规则设计时配置
基于代码实现我们可以将逻辑抽象为两个部分：
条件：当”应用范围“等于”指定楼栋“
行为：”楼栋名称“设置”必填、显示“都属于对应执行的行为
如果我们需要将条件再做一次抽象，作为可视化界面可配置的，首先我们将条件翻译为代码：
// 当”应用范围“为”指定楼栋“
if(data.usedScop == 'one'){// todo
}
我们可以从代码中得出条件包含以下几点：
条件数据来源类型 ：条件匹配会有不同的数据来源，一般是当前表单的数据中某个字段，也有场景是通过URL参数或者业务参数作为判断条件；
条件数据来源值：这里的值是字段名称 ”userScope“；
操作符：用于比较的方式，这里是”=“等于符号，其他操作符还有大于、小于、为空判断等等；
匹配值类型：匹配值常见为固定值或者URL参数值等；
匹配值：匹配值类型对应的值，如果是固定值这里是对应的固定值文本。
我们这里的示例中只有一个条件，实际过程中条件一般会有多个并且还有不同逻辑的组合，所以我们需要考虑多个条件组合及复杂的判断逻辑。
规则行为配置
条件配置完成后，条件需要和对应控件行为做关联，如“隐藏、必填”等，具体配置逻辑如下：
“楼栋名称”控件显隐规则：如果“应用范围为指定楼栋”则“显示”：
绑定控件：楼栋名称；
绑定行为：显隐行为；
对应条件：应用范围为指定楼栋；
行为：显示。
五、规则运行时解析机制
刚才提到的条件及行为都属于设计时的配置或描述，那么在界面运行时如何应用这些配置呢，需要对配置进行解析绑定到对应控件上。
1、将规则配置解析为对应表达式：
// 通过new Function 将规则生成为可执行函数
function rule(e){return e.data.useScope == 'one';
}
2、将规则行为绑定到控件上：
// 订阅应用范围值更改事件
var control = appform.get('usedScope');
control.on('valuechanged', invokeRule);
3、控件触发值改变时执行规则：
//执行规则
function invokeRule(e){var result = rule(e);//执行行为invokeAction(e, result);
}
4、执行组件行为：
function invokeAction(e){var action = e.action;switch(action){case 'show':if(result){e.control.show();}else{e.control.hide();}break;}
}
六、小结
通过这个模型我们在必填、颜色、加粗、编辑模式、显隐等场景都实现了通过可视化配置，已经满足了80%的交互场景配置。后续面向更加复杂通过在线编码支撑，在规则条件上增加代码段在线编码，如API数据源、算法逻辑等，这样就可以通过规则引擎配置全面托管系统的交互逻辑配置，实现交互简单场景可视化配置、复杂场景低代码开发。
------ END ------
作者简介
文同学： 产品经理，目前负责建模平台的规划工作。
也许您还想看
【复杂系统迁移 NET Core平台系列】之界面层
.NET Core MVC扩展实践
如何解决大批量数据保存的性能问题
招商城科走进武汉研发中心，现场编码解锁平台内核技术