１规则管理关键问题分析
１．１业务规则的实现方式（１）对于有一定规律性、规律稳定，且大量出现的业务规则，归纳其共同规律进行固化建模，并在系统中固化规则触发点、判断逻辑及处理逻辑，然后通过数据驱动．比如：教学信息管理、学生信息管理、教材管理、毕业档案管理等．（２）对于个性化、出现频度不高的业务规则，大多数是通过一段固化代码加部分参数化配置实现．但由于个性化业务规则总量大、易变性等特点，很容易导致规则代码膨胀、代码重写率高、系统性能下降，增加了系统维护的成本且无法满足需求快速支撑的要求，也降低了系统的易用性．针对上述两种实现方式，第一种方式目前已较成熟，且具有效率高、代码稳定等优点，但分散的配置缺乏一个统一的规则视图．第二种方式是目前规则管理的问题焦点，对于这部分业务规则的管理目前业界已呈现了部分规则引擎［３］，如：ＩＢＭＩＬＯＧ、ＪｂｏｓｓＤｒｏｏｌｓ等，但对于规则引擎如何与ＣＲＭ系统结合，建立行之有效的ＣＲＭ业务规则引擎是本文重点考虑的内容．１．２解决的思路（１）如何满足多样化、个性化的条件组合要求．针对这个问题需要引入业务规则语言以及技术规则语言等定义来解决规则组合复杂问题，本文采用Ｄｒｏｏｌｓ所带的规则语言来定义规则．（２）规则条件和规则操作中引用的业务领域对象数据如何获取和操作．针对这个问题需引入元模型管理，以使ＣＲＭ系统对自身业务对象有个自我认知的能力．目前ＣＲＭ各个功能都已经定义了形式化、通用化的信息结构图，如学生选课管理已经定义了选课信息结构图（ＳａｌｅＩｎｆｏＳｃｈｅｍａ），因此本次规则管理的订单元模型直接以订单提交的接口协议作为规则输入元模型，以实现规则处理过程订单信息的动态访问能力．（３）如何满足不同的规则处理的动作要求，如界面提示、中断当前流程、改变当前流程，特别是业务规则如何与界面操作衔接问题．本文的设计思路是规则引擎根据规则配置和业务对象元模型数据计算出需界面调用的规则逻辑，界面应用在关键点植入规则代码调用逻辑．如：客户对象属性取值约束，在客户对象的业务元数据上配置客户各属性的取值约束规则，客户保存时将客户信息传给规则引擎判断，规则引擎处理后输出相关界面操作信息，然后由前台根据返回的信息触发调用．该问题的关键点在于规则引擎需要统一规范前台规则处理标准，前台应用按标准植入相关调用代码．
２ＣＲＭ业务规则引擎架构设计
２．１总体架构基于以上关键问题的考虑，本文提出一个应用于ＣＲＭ系统中使用Ｊａｖａ语言实现的ＣＲＭ业务规则引擎架构，如图１所示．一个比较完整的ＣＲＭ业务规则引擎是由规则管理器、规则执行管理器、规则处理器、规则库、参考数据接口共同协作构架而成［４］．规则管理器负责对规则的管理和维护．规则执行管理器负责根据当前事件及相关条件提取出规则集以及业务事实提供给规则处理器．规则处理器负责实现规则判断功能．参考数据接口则是给规则处理器调用，负责提供在规则判断过程中所需要的外部数据信息．２．２模块分析２．２．１业务规则管理器业务规则管理器主要是对规则进行维护，并提供规则的读写、更新、查询等功能．在系统中主要由规则事件管理、规则目录管理、业务规则管理三个功能实现．规则事件管理需要支持规则事件的增加、删除、修改和查询，同时支持配置规则事件关联的条件参数．规则事件必须包含规则事件标识、规则事件名称等基本信息．规则目录管理是具有多个层级的业务规则的列表之间的管理，中国数字化校园管理内部能够通过此列表，管理所有的业务规则．规则目录管理需要支持业务规则目录的增加、更新和删除，支持多层级的业务规则目录，即第１级目录下可以包含第２级目录，能够为不同的业务目的编制不同的业务规则目录．业务规则配置管理需要支持业务规则的增加、删除和修改，支持业务规则关联条件的增加、删除和修改，支持根据各种条件查询业务规则．业务规则配置必须包含规则标识、规则名称、规则描述、规则类型、状态、创建时间、创建人等基本信息．２．２．２规则执行管理器规则执行管理器在架构中的作用主要是实现在ＣＲＭ应用和规则处理器之间进行通信，当业务流程中的某一环节需要进行规则判断时，应用程序调用规则执行管理模块提供的接口，传入当前环节相应的信息及业务数据信息，然后规则执行管理器根据当前事件及相关条件对应查询出需要判断的规则列表，将规则列表及业务事实传给规则处理器，由规则处理器进行规则判断，最后将规则处理器的处理结果返回给应用系统，由应用系统根据处理结果作进一步的处理．２．２．３规则处理器规则处理器是ＣＲＭ业务规则引擎的核心，主要实现根据业务事实对规则进行推理，选出可执行的规则，根据优先级按顺序执行．对于此功能的实现，一种是自行从头开发，但自行开发不但耗费时间，而且系统性能不一定比目前已有的、商用的或开源的规则引擎产品来的高，因此本文考虑基于已有的规则引擎产品来实现规则处理器功能，所以如何选择一个合适的规则引擎产品既能够能根据ＣＲＭ系统特点进行二次改造，又能够满足ＣＲＭ系统性能要求是首要考虑的问题．经过综合考虑分析，对规则引擎选型，本系统选择Ｄｒｏｏｌｓ规则引擎来实现规则处理器功能，处理流程如图２所示．规则处理器的执行入口为工作内存，以事实为出发点，通过模式匹配算法在规则库中寻找出相对于事实条件为真的规则来执行，如果有多条规则满足条件，则将这些规则放入冲突集，运用冲突解决机制加以处理．为了能与ＣＲＭ系统的系统流程以及界面操作衔接，规则处理器在进行规则处理时，除了支持修改业务对象信息外，处理结果还需要支持以下几种方式：（１）要求界面弹出错误信息，限制受理；（２）要求界面弹出提示信息，可继续受理；（３）对页面上的控件进行置灰、隐藏、替换名称；（４）弹出问答信息，由管理员选择选项之后再进行下一步处理．支持的下一步处理需要有：限制受理、继续受理和调用另一个规则进行处理．２．３规则冲突解决策略当事实对象进入工作内存时，可能会匹配到很多规则，如果这些规则之间存在冲突，则需要按顺序执行，因为规则不同的执行顺序可能会产生不同的执行结果．本系统采用Ｄｒｏｏｌｓ所带的优先级策略来解决此问题，在ＤｒｏｏｌｓＲｕｌｅｓ中可以给每条规则定义一个ｓａｌｉｅｎｃｅ属性，取值为整数值，正负均可，默认值为０，取值越大，表示这条规则的优先级越高．优先级策略就是根据每条规则的ｓａｌｉｅｎｃｅ属性取值来决定冲突规则集中每一条规则的执行顺序，即当多条规则同时符合要求时，ｓａｌｉｅｎｃｅ设定的值越高，表示规则优先级越高，此规则就优先被触发执行．２．４系统性能优化策略对于数字化校园管理ＣＲＭ系统来说，由于数字化校园管理业务相当复杂，需要运行的业务规则相当多，而且系统实时性要求高，因此引入业务规则引擎后，系统的性能情况相当重要，不能因为提高了开发速度而减少了维护代价，却使系统的性能大幅度下降，这是数字化校园管理系统所不允许的．本文除了通过业务规则模型的设计，使得在调用规则引擎时能够方便快速的查询出与当前规则事件及相应条件有关联的规则，从而只将需要判断的规则送到规则引擎判断，而不是将系统所有的规则都给规则引擎去过滤和判断，以此来提高规则引擎的工作效率，同时本文还考虑采用一些机制来辅助提高ＣＲＭ业务规则引擎的性能．（１）采用缓存机制以提高规则处理速度．由于数字化校园管理业务规则众多，因此在每个规则判断时，规则执行管理模块都需要从数据库中提取规则文件包，然后再送给规则引擎进行预编译，然后再执行，其效率就会低很多．因此本系统考虑在ＣＲＭ系统加载时就将规则库中的规则文件先进行预编译，然后将预编译的规则信息存储到系统缓存中，在规则判断时，规则处理器先从缓存中读取规则集，如果缓存中读取不到，则再从数据库中读取．（２）通过构建外部参考数据操作框架以减少规则判断时的内存损耗．Ｄｒｏｏｌｓ所使用的Ｒｅｔｅ算法是以空间代价换取执行效率的，事实将在工作内存中存储起来，如果有的在规则判断时依据的事实非常多，比如有一个学生选课业务规则：“某个学生要求加入某个教师开设的课程时，要判断此课程已选学生数据是否已经超过该课程最大选课人数，如果超过，则不能加入”．此时规则判断的事实依据是选这门课的所有学生对象，如果将所有的事实都加载到工作内存中进行规则判断，则此时应用服务器的内存消耗将非常大，系统性能将直接下降．图３是规则引擎引用外部参考数据进行规则处理的原理图．因此规则引擎需要支持既可以处理来自于应用程序的普通Ｊａｖａ对象，也可以在规则推理时提取外部的数据加入到工作事实中，以提高规则处理性能．如上述例子，在系统调用规则引擎判断时，只要传入当前该课程所选课学生信息以及该课程的最大学生数，而在规则推理时提取此课程目前已经加入的学生总数，这样加载到内存的事实就不会很多，同时规则判断时的内存消耗量也就不会很大．
作者：张天星 单位：福建船政交通职业学院 信息工程学院
