规则生成引擎（精选八篇）
规则生成引擎 篇1
1 数据绑定对象(DBO)模式与Castor
使用ETJRDL描述的XML规则文件来记录系统中的规则信息,需要一种高效的方式处理这些XML文件,以获取系统业务逻辑处理需要的规则信息。这需要将XML文档数据转换为业务数据,也就是实现XML文档数据与内存中Java对象的映射。随着XML相关技术的发展,业界出现了很多处理XML的API,如将XML数据作为流式数据进行处理的SAX,在内存中为XML文档数据构造模型树的DOM及其专为Java开发人员定制的JDOM,以及对对SAX与DOM的API进行抽象进而产生的JAXP等。这些处理XML数据信息的API各有利弊但都不适合一般性的应用需求。最好有一种方法能在Java对象与XML之间方便的序列化与反序列化的工具来实现XML文档数据与Ja⁃va对象的映射。
使用DOM、SAX、JDOM等来实现对象序列化到XML文本时,代码会涉及XML文本的结构,也就是说,在代码硬编码XML文本节点时,这种方式不具备可重用性与灵活性。要达到良好的可重用性和扩展性,必须将XML和数据交互操作的细节封装起来,也就是数据绑定对象模式。
2 DBO模式有三个参与角色
数据对象:被序列化到XML或从XML反序列化的对象。
数据绑定对象:一个工具型的基本对象,抽象了XML序列化和XML API的具体使用细节。
XML序列化API:真正实现XML序列化的具体行为,如Castor等工具。
Castor是一种将Java对象和XML自动绑定的开源框架,它可以在Java对象、XML文档、SQL数据表以及LDAP目录之间绑定。Castor使用映射规则文件来实现,Castor是DBO模式的具体体现,它使用完全对象化的概念来实现XML数据与Java对象数据之间的相互映射,为系统中规则信息的持久化操作提供了有力的支撑。
3 规则生成与解析引擎的设计
规则生成引擎的设计思路
1)规则生成引擎用于将用户定义的群组信息转换成使用ETJRDL描述的XML规则文件,它实现用户定义的条件信息与系统中的规则信息的映射。因此,其输入是系统中的群组对象,输出是XML格式的规则文件。规则生成引擎解析群组条件,根据实际应用需求构建映射规则,将群组条件映射成为系统中的规则信息。
2)规则生成引擎模型
规则生成引擎实现群组定义信息到论文申报规则描述信息的映射,其映射模型包括三个模块,输入部分,规则生成模块和输出部分。输入为由用户定义的群组信息,输出为使用ETJRDL描述的XML规则信息文档。输入的群组信息经过有Castor框架构建的规则生成模块按照映射规则进行编组[java与XML数据绑定],生成符合要求的输出,即XML规则文档。
4 规则解析引擎的设计思路
1)规则解析引擎将系统中的XML规则文件转换成为业务实体对象,它实现规则信息与内存Java对象的映射。因此,其输入是XML格式的规则文件,输出是系统定义的业务实体对象。规则解析引擎依据XML规则文件中的数据构建业务实体对象,为业务逻辑层提供操作接口。
2)规则解析引擎模型
规则解析引擎实现论文申报规则描述信息到业务实体对象的映射,其映射模型包括三个模块,输入部分,规则解析模块和输出部分。输入为XML格式的规则文档,输出为业务操作实体对象。输入的规则信息XML文档经过由Castor框架构建的规则解析引擎按照映射规则进行解组[Java与XML数据绑定],生成符合要求的输入,即业务实体对象。
5 规则生成与解析引擎的实现
在规则生成与解析引擎实现的过程中,系统中使用DBO(Data Binding Object)模式。将由ETJRDL语言定义的XML部分文档节点封装成DBO模式中的数据对象;构造Rule Handle类作为系统数据绑定对象,它提供抽象了XML的序列化和XML API的具体使用细节;而XML序列化API则由Castor提供。规则生成与解析引擎的主要类如下:
位于Rule Engine包中的Rule Object类、Condition Object类以及Entity Object类是DBO模式中的数据对象,分别用于构造XML规则文件的节点。Rule Handle类提供多个静态方法作为XML序列化以及其他处理XML文档的API。位于Rule Engine包中的Rule Build类用来获取用户定义的群组信息并以此构造XML规则文件,Rule Resolve类用来获取XML规则文件并对其进行解析,生成实体对象。
主要接口说明:
规则生成引擎 篇2
关键词：规则引擎；Rete算法；JBoss Rules；Drools
0引言
任何软件开发过程都是从需求到设计再到编码的，企业应用系统也如此。在传统企业应用系统开发中，业务规则是由用户在需求分析阶段提供，内嵌在程序代码中，它使用复杂的if-else语句来构成，一旦开发完成，便不易变更。然而现实情况却是业务规则往往频繁地变更，往往在设计和编码完成后还在变化，每一项规则的变化都需要开发人员对那些复杂的if-else语句进行修改，这无疑增加了系统的更新成本。正因为如此，所以企业管理者希望业务人员能够直接管理应用系统中的规则，不需要程序开发人员的参与。但问题是，很多复杂的规则，对于开发人员也很难推导出算法和抽象出数据模型，且业务规则往往嵌在系统的各处代码中，不可能让非开发人员管理。于是规则引擎应运而生，它的出现给开发人员带来了解决上述问题的契机。
1业务规则及规则引擎
一个业务规则由一组条件和在此条件下执行的操作组成，它们表示业务规则应用程序的一段业务逻辑。业务规则通常应该由业务人员和策略管理者开发和修改，但有些复杂的业务规则也可以由技术人员使用面向对象的技术语言脚本来定制。业务规则的理论基础是：设置一个或多个条件，当满足条件时会触发一个或多个操作。
规则引擎是一种嵌入在应用程序中的组件，它起源于基于规则的专家系统(RBES)，而基于规则的专家系统又是专家系统的一个分支。专家系统属于人工智能的范畴，它模仿人类的推理方式，使用试探性的方法进行推理。并使用人类能理解的术语解释和证明它的推理结论。规则引擎的任务是把当前提交给引擎的数据对象与加载在引擎中的业务规则进行比较，激活那些符合当前数据状态下的业务规则。根据业务规则中声明的执行逻辑，对当前数据对象执行对应的操作。
业务策略规则决策引擎 篇3
一、决策规则调度技术-规则引擎
传统的业务处理系统一般是基于C/S架构, 即服务器接受客户端的请求, 进行业务逻辑运算, 操作数据库完成相应流程, 最后将结果返回到客户端进行显示;客户端需要安装特定的程序, 称为“胖客户端”。随着网络技术的发展, 越来越多的业务处理流程开始转移到以网络为基础的应用上, 由此出现了基于B/S分层架构的业务处理系统。在这种架构中, 大量的业务逻辑和各种运算作为中间层, 从客户端抽离出来, 形成专门的中间层应用服务器。客户端通过网络浏览器进行访问;而中间层作为处理系统的可重用组件, 当业务处理逻辑发生变化时, 只须修改相应的中间层组件即可, 这样就提高了业务处理系统的适应能力和扩展性。这两种系统架构如图1基于C/S分层架构和图2基于B/S分层架构所示。
图2所示的这种基于B/S分层架构的多层架构方式和以前的C/S架构相比, 有了更大程度上的灵活性和重用性, 但随着业务处理流程的复杂化, 这种架构也开始表现出一定的局限性, 主要如下:
(1) 虽然中间层组件更加清晰地表达了业务处理逻辑, 但业务模型和业务逻辑仍然混合在一起, 没有彻底将业务逻辑和代码逻辑分离开来, 在一定程度上仍然存在逻辑层次不清晰的弊病。
(2) 这些中间层组件虽然是可重用的, 但是当业务需求发生变化时, 需要经过编码、编译、发布等一系列步骤后才能适应业务逻辑的变化, 这使得业务处理系统的灵活适应能力不能充分发挥出来, 增加了升级、维护阶段的复杂程度。
规则引擎的出现解决了这些传统架构的弊端, 借助业务规则系统, 可以灵活地配置规则文件, 当系统的需求发生变化时, 只须修改业务规则, 而无须对整个系统进行复杂的升级修改。如图3为基于业务规则引擎的系统模型框图。
二、业务规则
一个业务规则包含一组条件和在此条件下执行的一组操作, 它们表示业务操作应用程序的一段业务逻辑。业务规则通常应该由业务分析人员和策略管理者开发和修改。业务规则的理论基础是:设置一个或多个条件, 当满足这些条件时会触发一个或多个操作。
运行时, 规则引擎必须对这些业务规则进行解释, 因而可以将规则引擎理解为一种高性能的专用解释程序, 其中包含ifthen命令, 可根据预先定义的规则对转换的值和对象进行分析, 然后返回修改后的值和对象, 或直接执行操作。
对于企业而言, 客户和整个市场情况的不断变更, 必须将这些变更归类为业务规则。业务规则专家组规定了业务规则的两个定义。其中一个定义与业务观点相关, 而另一个定义与IT相关:
1. 从业务的角度看, 业务规则是一种原则, 在特定活动或范围内作为指导、操作、实践或过程的行为规范。
2. 从IT的角度看, 业务规则是一个定义或限制业务某些方面的声明。业务规则旨在用于定义业务结构, 或者控制或影响业务行为。
三、规则引擎
什么是规则引擎?规则引擎是如何执行规则的?这就是称之为“什么”与“如何”的问题。专业组对规则引擎给出了这样一个定义:规则引擎由推理引擎发展而来, 是一种嵌入应用程序中的组件, 实现了将业务决策从应用程序代码中分离出来, 并使用预定义的语义模块编写业务决策;接受数据输入, 解释业务规则, 并根据规则做出业务决策。
当引擎执行时, 会根据规则执行队列中的优先顺序逐条执行规则实例, 由于规则的执行部分可能会改变工作区的对象数据, 从而会使队列中的某些规则执行实例因为条件改变而失效, 必须从队列中撤销, 也可能会激活原来不满足条件的规则, 生成新的规则执行实例进入队列, 于是就产生了一种“动态”的规则执行链。
规则条件匹配的效率决定了引擎的性能, 引擎需要迅速测试工作区中的对象数据, 从加载的规则集中发现符合条件的规则, 生成规则执行实例。
四、规则的灵活实现——词汇与规则部署
词汇表就是指包含规则条件及操作中使用的事实的用户定义名称的定义集合。词汇定义使得规则在某一特定的业务领域中更易于阅读、理解和共享。
在图4的词汇表定义器中可以看到词汇条目都被加盖上版本号, 然后发布到规则存储中。这就保证了词汇定义在调用过程中不会改变并保持了引用的完整性。
我们在规则引擎中根据需要定义词汇, 并赋予不同的版本, 在业务人员修改版本的时候, 甚至可以定义词汇生效的时间, 而不需要停止当时的规则引擎中的活动, 这样从技术角度, 只需完成最初词汇与规则的建立, 而词汇的内容, 也就是业务需求变动最多的地方与规则独立开来, 由业务人员自由调配, 从而真正实现了业务流程的灵活性。
五、小结
传统许多业务流程受到软件局限性困扰的主要原因大多是由于决策规则被准确地转换为程序代码后, 一旦软件投入正式运行, 对于基本代码的任何后续修改都将困难重重。
但在实际业务流程的使用中, 业务策略并不是静态的, 它们经常会变更, 同时与其关联的业务流程也会随之变更。正是由于这些变更, 故而有必要在实现和修改业务流程时保持灵活性, 从而在激烈的竞争中赢得一席之地。业务规则引擎可以实现所要求的这种灵活性, 从而确保工作流系统能够在各个应用中被广泛使用。
摘要：业务规则指导着所有业务流程中的决策行为, 业务规则就是一些条件标准, 系统根据这些标准对所有的事实变量进行评估, 从而决定恰当的业务操作。在传统的应用程序设计中业务规则被事先设计好并与流程密切相关, 无法分割。在新型的业务流程处理过程中, 通过规则决策引擎可以灵活有效的处理多变的业务策略, 并减少传统的开发方法所带来的局限性和低效性。
基于规则引擎的生产调度系统设计 篇4
关键词：规则引擎,生产调度,业务规则
0 引 言
生产调度系统是制造企业MES系统的重要组成部分,对应于生产管理系统的短期计划安排,主要目标是通过良好的作业加工排序,最大限度减少生产过程中的准备时间,优化某一项或几项生产目标,为生产计划的执行和控制提供指导。在不同的问题环境中,生产调度的优化目标也不同。在生产制造企业中影响生产调度的因素很多(比如设备、工人的生产技能等),这些因素样式复杂,种类繁多,灵活多变[1]。另外在不同的环境下,影响生产调度的规则数量、优先级都会发生变化。过去生产调度系统将业务逻辑与主体代码紧耦合,业务规则以“IF-ELSE-THEN”的形式被硬编码到代码中去,结果是线性、确定的执行路由,所有的约束和判断都按照建模时的约定执行。当业务规则发生变更时,唯一的途径是修改代码。这种形式无法适应制造企业生产规则的频繁变更,导致生产调度系统的开发、升级和维护成本急剧增加,甚至生产调度系统完全无法适应企业的实际需求[2]。因此生产调度系统在保证对目标优化的前提下,将业务逻辑与主体程序的分离,已成为生产调度系统首要解决的问题。本文着重阐述通过规则引擎技术将生产规则逻辑从生产调度系统分离,克服生产规则灵活变更导致生产调度系统无法适应企业生产策略变更的问题。
1 关键性技术规则引擎概述
规则引擎由推理引擎发展而来,主要目的是实现业务决策与应用程序的分离。规则引擎的核心是规则定义、规则解析、规则匹配和规则执行。因此规则引擎的核心组件由三部分组成:规则解释器、模式匹配器和议程[7]。规则解释器定义规则的编写格式,负责对规则文件进行校验、解析和执行。模式匹配器负责从规则库中过滤符合条件的规则,并提交给议程。议程负责对规则集进行重新组合,赋予优先级。
规则引擎主要具有以下优点:
1) 将业务规则与主体程序分离,业务规则的变更不会影响主体程序。
2) 部署方式多样,支持嵌入式,业务规则可以嵌入到主体程序中。
3) 规则编写格式简单有效,跨语言、跨平台。
规则引擎是业务规则管理系统BRMS(Business Rule Management System)的一部分,BRMS包括三部分, 即规则库,工作内存和规则引擎组成[8]。业务规则管理系统框架如图1所示。
2 基于规则引擎的生产调度系统介绍
2.1 规则引擎和开发平台介绍
目前开源和商业化的规则引擎软件已经很多,其中开源的Drools规则引擎比较著名。Drools是一个基于Charles Forgy的RETE算法的开源业务规则引擎,是著名的商业引擎JBOSS Rules的前身[3]。Drools虽然是为Java语言所设计的规则引擎,使用Java编写,但能同时运行在Java和.Net上。Drools的规则文件格式为XML文件格式,大大简化了规则文件的编写和规则引擎的解析和执行过程。因此本系统采用Drools规则引擎。
本系统采用.Net平台。.Net平台是由微软开发的,业界广泛使用的开发平台,集成了许多富客户端开发工具(asp.net,wpf, silverlight等)。.Net平台具有良好的扩展性和与系统平台无关的特点,在企业信息化过程中得到了广泛的应用。
2.2 系统技术架构和规则引擎
在制造企业中,生产策略的变更非常频繁并且影响生产调度系统的业务策略很多,而传统的生产调度系统将业务逻辑与生产调度逻辑紧密耦合,导致该系统的开发、维护都变得异常艰难[5]。因此如何将业务逻辑与主体程序分离,屏蔽业务策略变更对主体程序的影响,则成为生产调度系统的关键问题。
基于规则引擎的生产调度系统架构设计的核心是实现业务逻辑与应用程序解耦[6]。其实现方案可以分为以下几个步骤:
1) 生成业务规则 业务人员对影响生产调度的业务策略进行收集、抽象、归纳,按照规则文件格式生成业务规则。
2) 业务规则管理 业务人员通过规则管理平台实现对规则的存储、版本管理、废弃、冻结等工作。
3) 执行业务规则 应用程序中启动规则引擎读入规则集文件,进行规则解析,然后与工作内存中的实体进行模式匹配,匹配成功导入议程中,由议程对规则集文件进行排序,生成规则实例,接口引擎执行规则实例,执行结果导入到应用程序中。
通过以上步骤,该设计方案能够适应企业业务策略的频繁变更,隔离策略变更对应用程序的影响,同时又能与主体程序进行动态通信。主体程序又能动态感知业务策略的变更,同时将变更结果显示。
基于规则引擎的生产调度系统采用MVVM框架,该模式可以构建松散耦合、更加灵活、易于维护的WPF应用[9]。系统架构的主要层次为持久层和业务层。持久层采用Microsoft SqlServer、Oracle等 实现数据的持久存储。通过对象/关系数据库映射工具实现对象与关系表之间的映射,使开发人员不用面对繁琐的数据库操作;业务层收集和定义基本的业务规则,对业务规则进行逻辑组织,定义业务规则词汇,编写、测试业务规则以及部署业务规则。本系统架构如图2所示。
2.3 生产调度业务规则定义
在制造企业中,制约生产调度的业务规则很多,在不同的场景中业务规则的组合形式多种多样并且规则的优先级对生产调度结果起着制约作用,业务规则的表现形式也是不一[4]。如何定义规则格式则成为规则引擎首要解决的关键问题。
Drools的规则语法主要由属性(attribute),条件部分即左部(LHS)和动作部分即右部(RHS)组成。Drool的属性主要包括:Salience,agenda-group,no-loop,auto-focus等。LHS由一系列条件构成,只有所有条件都为真时才会去执行RHS。
Drools的规则语法如下:
在生产调度系统中,所有的业务规则都可以抽象为该格式。本文以工人的技能熟练程度为例来说明生产调度系统中的业务规则建模方式。
3 规则引擎的引入优势
与传统的生产调度系统相比,基于规则引擎的生产调度系统有以下几点优势:
1) 业务逻辑与主体逻辑的分离,模块之间更加松散耦合,易于开发、维护和升级。
2) 屏蔽业务策略的变化,具有更强的灵活能力和适应能力,能有效地适应策略变化。既定策略的改变不需要重新编译、发布等步骤。
3) 有效地延长应用程序的生命周期。
4) 开发过程更加离散,各个过程可以不同的开发者/团队进行开发、测试和部署。
传统的开发过程如图3所示,引入规则引擎后的开发过程如图4所示。
4 结 语
基于规则引擎的生产调度系统实现了主体应用程序与业务逻辑的分离,屏蔽生产策略变更对系统的影响。该解决方案可以有效降低生产调度系统的开发、维护和升级成本,延长软件生命周期,降低企业信息化成本。
参考文献
[1]罗三宝,薛安.基于规则引擎的突发性大气污染事故应急处理系统研究[J].北京大学学报:自然科学版,2012,48(02):296-302.
[2]闫欢,张宜生,李德群.规则引擎在制造企业MES中的研究与应用[J].计算机工程,2007,33(7):210-212.
[3]张渊,夏清国.基于Rete算法的JAVA规则引擎[J].科学技术与工程,2006,6(11):1548-1550.
[4]张哲,李敏波,陈光雨.基于规则引擎的电子采购逆向竞拍的研究[J].计算机工程与科学,2012,34(03):158-164.
[5]余文姣,黄梦醒,朱东海.基于改进规则引擎的农业知识推荐系统[J].计算机工程与设计,2012,33(6):2295-2299.
[6]邹正武,谭庆平,徐建军.基于规则引擎的柔性工作流管理系统[J].微电子学与计算机,2006,23(z1):127-129.
[7]庞伟正,金瑞琪,王成武.一种规则引擎的实现方法[J].哈尔滨工程大学学报,2005,26(3):385-389.
[8]陆歌皓,李仕金,吴超凡.Drools规则引擎在现代物流信息平台的应用[J].计算机科学,2011,38(10A):447-450.
规则生成引擎 篇5
应用系统中往往存在大量if ···then ···else结构的代码来完成对相应业务逻辑的判断与处理, 这种直接使用源码定义业务逻辑的方式很难适应外部业务逻辑的变化, 相应维护成本也将大大提高[1]。为了提高对业务逻辑定义与维护效率, 专门用于业务逻辑定义、解析与执行的规则引擎应运而生。Drools就是其中非常典型的一种[2]。然而Drools只能识别与处理基于DRL (Domain Rule Language) 格式定义的业务逻辑, 也就是说业务人员不能直接定义符合实际需要的业务逻辑, 而需要专业人员来完成;一旦规则本身发生变化, 需要在业务人员与专业人员之间进行大量的沟通与协调工作, 由此大大降低规则引擎在整个系统中的执行效。该问题解决的关键在于可由业务人员直接定义与维护相应业务逻辑。Drools也试图通过使用DSL (Domain Specific Language) [3]来解决该问题, 然而由于DSL只能解析与执行有限英文语句定义的业务逻辑, 因此其推广与应用非常有限。本文从领域逻辑入手进行领域逻辑的分析、规划、定义与解析, 从而提出领域规则元模板的概念;通过利用语言解析程序ANTLR来帮助业务人员基于领域规则元模板定义的业务逻辑到Drools DRL逻辑的转换, 从而有效地支持了业务人员对业务逻辑的直接定义与维护。
1 领域规则元模板定义
面向业务的逻辑描述方法与Drools可理解与执行的逻辑描述定义主要存在以下几点差异:
(1) 结构与语义方面。面向业务的逻辑定义通常用各种不同的自然语言描述, 由此导致面向业务的逻辑描述相应语句结构与描述内容不确定, 其相应语义也较模糊。面向规则引擎Drools的逻辑描述必须遵循严谨的结构以及语义定义才能被正确理解与执行。
(2) 描述方式方面。面向业务的逻辑定义通常可用“如果……那么……否则”的结构及其嵌套进行定义, 而面向规则引擎Drools的逻辑描述只能遵循非嵌套的ifthen描述形式。
为了在面向业务与面向Drools之间达成逻辑描述的一致性, 需要使用以下几个基本概念:
(1) 领域规则元模板。它是面向业务的逻辑描述中组成元素抽取的统称。这些领域规则元模板可以用于描述条件判断中的大小比较、赋值处理、嵌套结构句型等。领域规则元模板是不可再细分的逻辑单元, 它对应了严格的逻辑解析与执行方法。领域规则元模板通常由连接多个固定词汇与0到多个空白部分组成。
(2) 领域规则模板。它是在领域规则元模板基础上, 通过特定句型 (如ifthenelse及其嵌套) 及一定顺序约束组织起来的内容;它是一类具体业务逻辑的抽象。业务人员根据实际业务逻辑描述需要组织领域规则模板, 并在其领域规则元模板的空白部分输入或选择实际内容。
(3) 领域规则。它是由业务人员定义与维护的具体逻辑描述。
从面向业务的逻辑定义到面向Drools的逻辑定义, 需要完成以下几项基本工作:
(1) 领域规则元模板的定义与解析。需要由专业人员来定义与维护面向特定业务领域的领域规则元模板。除了维护领域规则元模板的组成结构, 还需要维护元模板的词法与语法解释。
(2) 领域规则模板的定义与解析。由专业人员来定义与维护领域规则模板的解析与处理。
(3) 面向业务的领域规则定义与解析。面向业务的逻辑描述由业务人员在系统提供的领域规则元模板与领域规则模板基础上完成;由领域规则元模板与领域规则模板解析程序将其转换为Drools可理解与执行的逻辑描述形式。
2 领域规则元模板及领域规则模板的解析
领域规则元模板以及领域规则模板的定义与解析属于基于自然语言的语句词法与语法解析问题。ANTLR[4]是目前一种被广泛认可与应用的词法和语法解析框架, 常被用于完成自定义数据库查询或编程语言的解析与执行。ANTLR可以对基于其语法表达的任意自然语句进行解析与处理, 相应文法文件定义了识别的范围与处理内容, 完成将满足特定约束的自然语句组成转换为面向Java或C++的对象。ANTLR对自然语句的解析分词法解析与语法解析两个步骤, 其中词法解析主要负责将输入的自然语句分解为相互独立的标识符、关键字、常量等组成单元, 语法解析即针对这些标识符、关键字及常量等组成定义其处理方法, 并可以对象的形式返回处理结果供其他应用程序使用。
与其他语言解析程序不同, ANTLR具有以下几个鲜明的特点:
(1) ANTLR支持广泛的字符定义。ANTLR对输入自然语句的识别以字符为基础, 不仅可识别基于ASCII编码的字符, 还可识别基于Unicode编码的字符;因此从理论上讲, ANTLR可识别与处理基于任何自然语言字符组成的自然语句。
(2) ANTLR支持多种编程语言。ANTLR的语法定义可被自动转换为包括Java、C、C++在内的多种编程语言, 从而可将ANTLR与开发者比较熟悉编程语言开发的应用程序相结合来完成对业务人员输入的自然语句组成的处理。
(3) ANTLR文法定义与维护比较容易。ANTLR是基于扩展巴科斯范式EBNF上下文无关的元符号表示文法而定义的;且目前ANTLR还提供了相应的可视化工具来查看相应文法定义的DFA结构, 由此可在开发者与业务人员之间快速达成一致。
3 基于ANTLR的Drools改进后规则系统开发框架及应用案例说明
基于ANTLR领域模板解析改进后的规则系统开发框架ADF如图1所示。
ADF开发框架主要由客户端、ANTLR解析、Drools处理三部分组成。其中客户端部分又分专业人员定义与业务人员定义两部分;专业人员需要定义面向业务的领域规则元模板、模板结构及其相应解析方法, 业务人员则在领域规则元模板的基础上定义具体面向业务的逻辑内容。ANTLR解析部分首先利用ANTLR完成对面向业务的领域规则元模板及模板的文法文件的解析, 生成词法解析与语法解析对象;然后通过调用该词法解析与语法解析对象的对象完成对业务人员定义的逻辑解析与处理, 生成对应的Java对象以及相应的DRL规则。Drools处理部分则利用已生成的DRL规则定义结合实际的事实对象, 最终完成实际逻辑的匹配、选择与执行, 并将实际逻辑运行结果存储到相应Java对象中, 以便被其他应用程序调用处理。以下通过对工作流任务分派领域中面向业务的逻辑定义、解析与执行来说明ADF开发框架的使用方法。
3.1 客户端部分实现方法
专业人员需要针对实际的工作流任务分配的多种具体表达形式总结出相应的领域规则元模板及模板内容, 并利用ANTLR完成相应模板的文法解析定义;在此基础上, 向业务人员提供易于操作与理解的工作流任务分派规则元模板、模板的操作界面。如一具体工作流任务分派领域业务逻辑描述如下:
以上面向业务的工作流任务分派逻辑是基于以下几个领域规则元模板完成的:
(1) 流程变量比较元模板:流程变量 (<流程变量名称元模板>) (<关系运算符>) (<INT>) , 其中<流程变量名称元模板>定义为包含“申请金额”、“审批者”、“申请代理机构”等类似选项的元模板;<关系运算符>定义为包含“等于”、“不等于”、“低于”、“高于”等类似选项内容的元模板;<INT>定义了用户输入金额必须为整型数值的信息。机构级别比较元模板与之类似, 这里不重述。
(2) 面向流程所属机构的职位分配元模板:流程所属机构的职位 (<职位元模板>) 。其中职位元模板定义为包含“主管”、“副主管”、“技术主管”、“财政主管”等选项信息。
(3) 直接任务分配模板:
把任务分配给<任务分配对象模板>
(4) 条件任务分配模板:
如果 (<条件组合模板>)
则 (<直接任务分配模板>|<条件任务分配模板>)
否则 (<直接任务分配模板>|<条件任务分配模板>)
其中<任务分配对象模板>可定义为包含<面向流程所属机构的职位分配元模板>、<面向流程所属机构的上级机构的职位分配元模板>等在内选项的模板。<条件组合模板>由可包含“与”、“或”的多个<条件元模板>组成, 其中<条件元模板>又定义为包含<流程变量比较元模板>、<机构级别比较元模板>等选项的元模板。
以面向业务的条件任务分配模板为例, 其在ANTLR文法文件中的定义为:
condition Allocation Template返回String Buffer类型结果, 结果存储在str变量中。C1、C2、C3、C4分别代表识别固定词汇“如果”、“则”、“否则”、“把任务分配给”。execute Template代表当条件满足或不满足时执行的模板内容, else Execute Template代表条件不满足时执行的模板内容, 它又由固定词汇C3连接execute Template构成。condition Allocation Template、condition Template、else Execute Template使用ANTLRWorks编辑定义时对应的ADF分别如图2、图3、图4所示。
在condition Allocaiton Template的识别过程中, 将从condition Template实际获得的结果赋值给变量p1, 将“则”后面通过execute Template实际获得的字符串信息赋值给变量p2, 将“否则”后面通过execute Template模板获取的字符串信息赋值给变量p3;如果p3部分的内容为空, 则意味着该规则不包含不满足条件的处理。本处condition Allocation Template返回的对象为String Buffer类型, 目的是为了将后面更好地组织后面识别出来的String类型对象。
基于ANTLR的规则元模板与规则模板定义文法文件需要声明以下几项内容:
(1) 给规则元模板、规则模板赋以相应的英文名称, 以便后续引用与共享。
(2) 规则模板与元模板中出现的中文固定词汇需要使用相应的Unicode编码表达。
(3) 可将用户选择引用的规则元模板中输入或选择的内容所产生实际内容直接赋值个一个变量, 以便进行后续处理;注意这些直接声明的变量返回的结果都是字符串类型, 因此如果需要其参与类似数值计算的运算, 还需要对其进行相应的类型转换。
(4) 为规则元模板或模板定义一个返回值对象以及返回类型信息。
(5) 采用特定编程语言 (如Java或C++等) 说明返回对象的创建以及返回对象与直接声明变量之间的运算关系。
3.2 ANTLR解析部分实现
ANTLR会根据开发者定义的规则模板文法信息自动生成对应的词法解析Lexer和语法解析Parser对象 (如以上实例将生成allocation Lexer和allocation Parser对象) 供应给程序调用。开发者编写应用程序调用allocation Lexer与allocation Parser解析业务人员输入的任务分配规则, 并将其归约为多个Token对象, 并在使用的每个模板前面添加了模板标识。专业人员还需要在ANTLR处理部分编写程序完成面向业务的规则到面向规则引擎的规则转换, 具体包含以下两个内容: (1) 完成汉语“如果……则……否则”嵌套表达结构到Drools的“whenthen”非嵌套结构的转换。 (2) 完成各规则元模板中处理的汉语描述到Java对象方法的转换。
3.2.1“如果……则……否则”嵌套表达句型到Drools的“whenthen”非嵌套句型的转换
ANTLR针对外部输入语句中包含的“如果……则……否则”嵌套句型分两步来完成:
1) ANTLR对“如果”、“则”、“否则”的嵌套识别
系统在词法匹配过程中如果匹配到“如果”这样的词汇, 则自动将其及后面的内容与condition Allocation Template模板的内容组成进行匹配;如果词法匹配通过, 则会自动将“如果”、“则”、“否则”后面的内容送入condition Template、execute Template以及else Execute Template中;其中else Execute Template可为null, 也就是说该任务分配语句只针对条件满足时进行分配的处理。由于execute Template本身就是一个condition AllocationTemplate, else Template最终也转换为execute Template, 因此condition Allocation Template很好地支持了输入语句“如果”、“则”、“否则”的嵌入表达。
2) ANTLR对“如果”、“则”、“否则”的嵌套处理
不管任务分配的具体执行内容是针对条件满足或条件不满足, 最终它们转换为execute Template规则模板句型, 但是需要在execute Template模板的语法定义中完成对条件节点、满足条件执行节点以及不满足条件执行节点的识别。具体完成步骤就是:在匹配到condition Template时, 自动创建一个condition Node类型节点, 代表该任务分配项执行时必须满足的条件;如果继续读到的是一个direct Allocation Template内容, 则为该conditionNode节点生成一个Terminal Node类型, 并将其定义为conditionNode节点的左孩子。如果匹配到的是一个condition AllocationTemplate, 则继续分析condition Allocation中的conditon Template部分, 并为其条件内容部分创建一个新的condition Node节点, 该节点定义为上一condition Node的左孩子;如果是在else ExecuteTemplate中匹配到condition Allocation Template, 则将为其condition Template的内容创建一个condition Node节点, 而该conditionNode节点为上一condition Node的右孩子;如此匹配直到将“如果”、“则”、“否则”匹配完毕, 并激发convertRule Tree方法。该方法主要完成基于condition Allocation Template生成的规则条件树到Drools规则的转换。具体方法是遍历到该规则条件树的节点直到遇到Teminal Node节点则回退, 并将该过程遍历到的condtion Node节点condition Template信息与其父condition Node节点中的conditon Template信息连接到Drools规则中的WHEN部分;将Terminal Node节点中direct Allocation Template的分配信息映射到Drools规则THEN部分。在回退过程中需要区分相应condition Node节点是其父condition Node节点的左孩子还是右孩子, 如果是左孩子, 则条件直接连接, 否则需要补充“not”关键词。
3.2.2 完成各规则元模板中处理的汉语描述到Java对象方法的转换
将通过结构转换获取的规则字符串变量rule中规则名称、condition、produce内容等分别进行处理。如condition中流程变量条件判断模板的内容转换为方法compare Variable (op1, op2, op3) 调用, 其中op1、op2、op3分别为相应模板三个需要用户填写或输入的内容。将produce中“分配给流程所属机构的职位”元模板汉语描述转换为对方法assign Work By Position (op1) 的调用, 其中op1为具体职位信息, 以此类推。
最终该面向业务的工作流任务分派逻辑转换的Drools规则内容如下:
3.3 规则引擎执行部分
规则引擎执行部分主要负责将经过解析与转换得到的基于DRL描述的工作流任务分派规则加载进来, 并根据实际业务流程产生的事实对象输入来完成任务分派规则的选择与执行。以上基于DRL描述的工作流任务分派规则在Drools规则引擎执行过程中会自动生成如图5所示的节点树, 以便加快匹配速度。
通过在规则引擎Drools前端引入ANTLR, 并利用ANTLR完成对面向业务人员提供的工作流任务分派规则元模板以及工作流任务分派规则模板的解析, 完成面向业务的工作流任务分派逻辑到Drools逻辑的转换, 最终由Drools在实际业务的驱动下完成与相应事实匹配的规则选择与执行。在未将ADF框架应用到某银行的工作流任务分派系统中之前, 相应银行信用审批流程中某审批条款的修改或增加需要由银行业务部在获得规则修改许可后向维护该审批系统的人员提出申请, 由维护人员与审批系统的开发单位进行协商, 然后由审批系统开发单位组织人员进行相应规则的Drools修改, 并做内部测试, 然后提交该银行审批系统维护人员共同测试, 通过后再在实际审批系统中应用。由此导致相应逻辑维护流程异常复杂, 需要在多个部门与人员之间进行沟通、设计、实践与测试;一条审批规则的修改大概需要经历6~12个月的时间才能修改维护成功, 大大降低了相应银行对政府政策以及市场需要的响应速度。ADF框架在相应银行信用审批系统的应用将规则维护任务完全交由银行业务部, 而审批系统的开发单位只需要维护规则模板ANTLR词法与语法的解析与转换。虽然最开始由于对ANTLR规则模板的解析与转换需要耗费大量的人力与物力来建设, 但是一旦建设成功后, 后期的维护成本大大降低, 后期的审批规则修改周期降低到1~2周, 使得相应任务分配系统的工作效率与质量得到大大提升。
4 结语
随着应用系统对于逻辑定义与维护要求的不断提升, 规则引擎将在企业应用系统中得到更广泛的应用。基于ADF框架开发的业务规则系统既充分利用了现有规则引擎Drools在规则选择、执行上的优势, 又通过ANTLR的引入可以将对面向业务的逻辑维护交由业务人员直接处理, 由此可以大大提升应用系统对规则的维护能力, 维护成本大大降低。通过利用ANTLR实现自然世界逻辑描述到计算机世界逻辑描述的部分自动转换, 为自然世界到计算机世界转换的广泛应用打下了坚实的基础, 也使得相应行业的规则识别与执行提升到一个新的高度。
摘要：针对Drools只能解析与执行由专业人员定义的业务逻辑问题, 提出基于语言解析程序ANTLR (Another Tool for Language Recognition) 的解决办法, 并给出相应改进后的开发框架ADF (ANTLR-Drools developing framework) 及其关键实施方法。业务人员可以利用ADF提供的领域规则元模板直接定义业务逻辑, 由基于ANTLR的元模板解析程序完成相应业务逻辑到Drools逻辑的转换。事实证明该框架的可行性和有效性。
关键词：Drools ANTLR ADF,领域规则元模板,元模板解析程序
参考文献
[1]王伟辉, 耿国华, 周明全.规则软件系统模式匹配算法研究综述[J].小型微型计算机系统, 2012, 33 (5) :913-920.
[2]Drools Introduction and General User Guide[EB/OL]. (2013-7-8) .http://docs.jboss.org/drools/release/6.0.0.Beta5/droolsjbpm-introduction-docs/html.
[3]Drools Expert User Guide[EB/OL]. (2013-7-8) .http://docs.jboss.org/drools/release/6.0.0.Beta5/drools-expert-docs/pdf/drools-expert-docs.pdf.
[4]Terence Parr.The Definitive ANTLR4 Reference[M].The Pragmatic Bookshelf.Dellas, Texas, Ralegh, North Carolina.2013-1.
[5]邓伟.基于Drools的领域专用语言应用研究[J].电脑开发与应用, 2012, 25 (2) :8-11.
[6]赵彤洲, 王海晖, 马帅军, 等.基于规则引擎的面向企业服务管理系统的设计[J].湖北大学学报:自然科学版, 2010, 32 (3) :265-268.
[7]Mark Proctor.Drools:A Rule Engine for Complex Event Processing[C].International Symposium on Application of Graph Transformation with Industrial Relevance 4th.2011.
[8]Chai Young Jung, Katherine A Sward, Peter J Haug.Executing medical logic modules expressed in Arden ML, using Drools[J].Journal of the American Medical Informatics Association, 2012, 19 (4) :56-67.
[9]Zhanlin Ji, Damien Meere, Ivan Ganchev, et al.Implementation and Deployment of an Intelligent Framework for Utilization within an InfoStation Environment[J].Journal of software, 2012, 7 (5) .
利用搜索引擎规则有效管理网店商品 篇6
目前网上的商品越来越多, 所以产品名称的关键词的设置非常重要, 这关系到企业的发展前景, 对产品名称的优化技巧主要可以从以下几个方面进行优化。
1 淘宝搜索排名规则
如何将自己的产品在站内的搜索排名靠前, 如何让顾客找到你的产品, 针对这些问题, 就要了解搜索排名的规则, 我以淘宝为例进行分析。
1.1 在淘宝首页中默认的搜索结果是以“人气”排名
为准的, 涉及“人气搜索”的主要因素是“卖家的信用、浏览量、收藏人气、好评率等”。通过对检索结果的测试, 在这些因素中, 其优先顺序是成交量、收藏人数、卖家信用、好评率、浏览量及产品下架时间。商家可以根据这些因素的优先性, 做一些促销活动, 例如, 买家收藏我的店铺, 赠送10个淘金币, 累计在本店购买数量超过3件, 有小礼物等方式来提高店铺的人气排名。
1.2 在淘宝的首页中搜索“店铺”, 是以结果“信誉”为依据的搜索结果, 即以买家信用的高低程度进行的排序。
1.3 在淘宝首页中以“我要买”为搜索条件的搜索结
果, 其影响因素有是“剩余时间”和“是否推荐商品”, 与产品的销售量、网店的浏览量、商品价格、买家的好评率、商品页面的排版布局、关键字频率和次数等因素没有任何关系。
2 商家对商品管理的优化策略
搜索规则了解后, 我们可以从“宝贝标题、上架时间、橱窗推荐、浏览量、收藏人气、销售量”等几方面的优化来提升产品的搜索排名。几个方面来应对搜索机制, 优化我们的商品。
2.1 宝贝标题的充分利用淘宝商品名称的容量是30
个汉字, 60个字节, 根据顾客的消费需求和定位, 在容量允许的情况下, 尽可能的选用更多的关键词, 扩大消费者的搜索范围, 提高产品的曝光率。
2.1.1 属性关键词将商品的名称或是俗称, 商品的类
别、规格等介绍商品的基本情况的字或者词, 根据消费者的搜索习惯和语言表达方式, 尽可能地设置不同的属性关键字搜索, 在这些关键词中选择常用1-2关键词进行使用。
2.1.2 促销关键词关于清仓、折扣、甩卖等信息关键
词, 这些关键词是消费者最为关心的, 可以有效地吸引到更多的关注, 提高商品和店铺的浏览量。
2.1.3 品牌关键词品牌是包括商品本身的品牌和店
铺的品牌, 增加商品品牌的关键词可以给顾客提供更为精准的搜索信息, 对于提高店铺的知名度和打造网货品牌都有很现实的意义和显著的效果。
2.1.4 评价关键词给顾客一种心理暗示, 一半都是正
面、褒义的形容词, 增加这类关键词不仅能够满足消费者寻找可靠的商品质量、可信的商家需求, 同时可以获得顾客的好感和认同, 大小顾客的顾虑, 让顾客做出成交的决定。
2.2 标题关键字的分割符号如果商品标题不进行分
割, 会使整个标题看上去一团糊涂, 比如“Bemega正品不锈钢真空保温杯男士女士水杯情侣杯子茶杯特价包邮”这个产品名称没有一个标点符号, 完全不断句, 显然有利于提高被搜索到的概率, 但是会让顾客看起来会是十分辛苦甚至厌烦, 所以, 必要的断句还是应该有的。
2.3 商品发布时间和橱窗优化在淘宝的搜索排名规
则中, “商品下架时间”也是搜索结果排名的重要因素, 下架时间越少, 排名越靠前。所以商品发布的时间优化也相当重要, 具体操作如下:
2.3.1 上架时间选择为七天选择7天下架一次要比
选择14天一次下架的机会大, 就可以获得较多的宣传机会。
2.3.2 在黄金时段上架商品通过对交易数据的统计
与分析, 10:00-12:00, 14:00-16:00, 19:00-23:00, 是交易量最多的时候, 可以每隔一段时间发布一个新的商品, 分隔开发布商品, 在这个黄金时间段内, 都有即将下架的商品获得靠前的搜索排名, 店铺会增加很多的流量。
2.3.3 橱窗推荐销售量大的产品当橱窗推荐位不够
使用的时候, 我们可以选择店铺中销量大的商品或是畅销商品, 如果商品的销量提升以后, 在搜索时也会增加商品的曝光度。对于竞争力度不是很大的商品, 不采用橱窗推荐位, 其搜索结果也会排在前面。
2.3.4 提高商品的收藏量与浏览量商品收藏量和浏
览量是搜索排名的两个非常重要的因素, 商家可以通过不同的方式来增加收藏人气和浏览量, 例如收藏后可以送不同价格的代金劵来增加收藏人气。
3 结论
顾客购物的目的不同, 但是购物的顺序基本上是一样的。在互联网上寻找商品的信息, 使用关键词搜索是最省力最快捷的一种方式, 在交易平台上面对海量的商品而言, 顾客想尽快地找到所需要的商品信息, 就会使用关键字进行查找。所以商家可以通过各种提升商品搜索排名的技巧, 提高商品曝光率, 提升商家的品牌知名度。
摘要：顾客在互联网上购买商品时, 会通过关键字的方式查找所需商品的信息, 所以对于商家而言, 要熟悉商品搜索引擎的规律, 依照规律对商品进行有效的管理, 以此提高商品的曝光率, 提升企业的品牌知名度。
关键词：搜索引擎,商品管理
参考文献
[1]罗岚.网店运营专才, 出版社南京大学出版社, 2010年3月.
[2]淘宝大学.网店推广.电子工业出版社, 2011年7月25日.
规则生成引擎 篇7
我们以国家电网公司为例, 来对电力行业基于规则引擎的数据质量治理应用工作进行介绍。国家电网公司于2013年5月成立了运营监控中心, 同年, 将国家电网公司的数据资产治理工作也划到了该中心。经过了近两年的建设, 以信息化应用为手段, 以全面监测业务为基础, 以专业分析为支撑, 运营监控中心初步掌握了公司核心业务流程和核心资源运行状况, 能及时发现公司经营活动中的部分风险点, 有效识别经营管理异动和问题, 及早研判各类风险、提出预警, 初步建成了形成发现问题、分析问题和协调解决问题的闭环管理机制。
随着运营监控中心全面监测业务的深入开展, 通过业务部门推送的数据的数据质量问题逐步的凸显了出来。面对种种问题, 国网运监中心的工作应该如何展开呢。
每项工作是按照一定的规章制度来展开的。这里所说的规章制度, 我们就可以理解成为一种规则。有了规则, 大家都按照规则来做事情, 事情办起来就会事半功倍。数据治理工作也是有其规则存在的, 只不过是由于国家电网公司过于庞大, 规则逻辑各部门不同, 各单位不同, 情况十分复杂, 如果用固定的一套行为规则让整个企业去执行, 执行的效果会与预想偏差甚远。这就要求基于规则的数据治理的实现必须能灵活的定义规则, 必须能灵活的在线调整规则。国家电网运营监控中心与其他业务部门是平级的, 其部门的性质决定了其不可能去给每个业务部门, 各业务条线梳理出一套适合每个业务部门的可行性规则, 因为从运监中心来讲, 它所对业务的了解绝对没有业务部门的人对业务了解的深刻。这样的话难道运监中心的工作就不做了?本文将依据运营监控中心的业务特点结合规则引擎技术, 论述国网运营监控中心将如何开展数据治理工作。
对于基于规则引擎的数据质量治理, 我们首先需要了解的是什么是规则引擎, 什么是业务规则?
规则引擎 (Business Rule Engine, BRE) 是一种嵌入在应用程序中的组件, 它的任务是把当前提交给规则引擎的数据对象与加载在规则引擎中的业务规则进行测试和比对, 激活那些符合当前数据状态下的业务规则, 根据业务规则中声明的执行逻辑, 触发应用程序中对应的操作。
业务规则是对企业或组织的业务进行描述、说明和规范的语句。笼统地说, 像日常生活中见到的业务手册、行业标准、管理章程、营销策略还有不成文的惯例都可以称为业务规则, 它们体现了一个企业或组织的精髓, 是公司赖以生存的资本。
二、主要步骤
开发人员在程序中使用规则引擎基本遵循以下5个典型的步骤:
(1) 创建规则引擎对象"
(2) 向规则引擎中加载规则集或更换规则集"
(3) 向规则引擎提交需要被规则集处理的数据对象集合
(4) 命令规则引擎执行
(5) 导出规则引擎执行结果, 从规则引擎中撤出处理过的数据
使用了规则引擎之后, 许多涉及业务逻辑的程序代码基本被这五个典型步骤所取代, 一个开放的业务规则引擎应该可以嵌入在应用程序的任何位置, 不同位置的规则引擎可以使用不同的规则集, 处理不同的数据对象"此外, 对使用规则引擎的数量没有限制。
三、主要技术
可以用五元组对业务规则进行形式化定义
({Event}, {Term}, {Condition}, {Consequence}, {Priority})
其中, {Event}是触发该业务规则执行的动作事件集合;{Term}是与该规则相关联的对象或术语;{Condition}是该业务规则需要匹配的条件集合;{Consequence}代表规则处理集合;{Priority}表示业务规则的优先级集合。
业务规则具有五项特性:原子性、独立性、简洁性、一致性、非冗余性。同时, 业务规则有四种主要的表现形式:
1、决策表:
以表格的形式表示业务规则, 每一行表示一条规则, 列表示条件或动作, 当所有条件满足时, 执行动作";2、决策树:将一组业务规则以树型结构来表示, 每一个分支表示一条决策路径, 叶子节点表示结果或动作";3、规则语言:使用类似自然语言的句法描述规则"可以有很多种规则语言, 每种语言适合解决某个特定领域的问题"规则语言可以提供较好的性能, 但比图形化的表示难于维护";4、脚本 (模板) :用于描述过程性的业务逻辑, 如:/IF, THEN, , ELSE, 0, 是决策表!决策树!规则语言的基础"。
综合考虑数据质量和业务约束间的关系, 业务规则可以从如下图所示15个约束规则方面来进行业务规则的梳理, 其中:
业务规则主要应用于专家诊断、电子政务、物流配送、电子商务、审计预警等多种业务信息系统中, 具体可以实现以下四方面的功能。
(1) 实现业务术语的定义。业务术语是一个领域的专业语言, 是该领域的人员彼此之间进行交流的工具, 是业务规则的最基本的组成成分。
(2) 陈述有关的事实或行为。
(3) 执行业务的行为约束。
(4) 进行知识的逻辑推理。
四、与传统方式对比
基于业务规则的开发方法是一种以业务规则为核心, 从业务规则角度进行分析问题和解决问题的信息系统开发方法。与传统的信息系统开发方法相比, 它具有以下四方面的优势:
1、系统开发简单:
许多软件开发厂商都提供了简单易用、功能强大、性能优越的业务规则开发工具, 内嵌规则引擎, 能够很容易地进行系统开发。
2、业务规则复用:
由于业务规则是按照标准的业务规则语言编写的, 而大多数商业化的业务规则产品都支持标准的业务规则语言, 故可以很容易地将业务规则库移植到其他的信息系统中, 同一条业务规则可以被多种事务复用。
3、业务更新方便:
不需要进入系统中修改程序代码, 使系统能够更快速、更及时地体现业务的变化。
4、维护成本低廉:
系统上线运行后, 管理业务规则的工作业务人员就可以完成, 并不需要专门的技术人员, 很大程度上降低了维护成本。
五、业务功能
基于规则引擎, 如何数据应用过程中进行数据治理。
1) 设计业务规则体系
围绕着运监中心全面监测、运营分析、数据资产管理要求的设计规划业务规则体系, 明确业务规则分类及业务规则管理要求。
2) 梳理业务规则, 构建业务规则库
通过对业务规则的梳理, 还原业务流程, 构建业务规则库, 从而形成基于业务的校验结果。
3) 优化完善数据接口
根据业务规则, 梳理6大专题的数据接口, 从数据的主动性、及时性、完整性、准确性方面优化完善数据接口, 实现6大专题数据基于明细数据, 按需、主动抽取, 强化基于底层数据的计算能力和对状态的在线监测和分析能力。
4) 构建轻量级的业务监测系统工具
根据业务规则的梳理成果, 对业界流行的规则引擎进行验证测试和压力测试, 选择最能满足未来需求的规则引擎, 良好的规则引擎, 支持复杂的逻辑判读并且有丰富的外围接口, 支持便捷的规则开发环境, 并且有强大的性能保证。
六、结语
构建基于规则引擎的数据质量治理体系以来, 初步实现对公司经营管理活动的在线监测与控制, 全面掌控公司经济运行状况, 增强业务管理的透明度, 增强公司的集团管控力和风险防控力, 为公司经营决策提供有力支撑, 为提高管理绩效和经济效益提供保障, 为建设“一强三优”的电网企业奠定基础。
摘要：数据的使用、管理及价值的最大化已越来越被人们所重视。目前, 电力行业的业务应用系统产生的海量业务数据已被企业管理层定义为数据资产的高度, 并将数据资产工作的管理划定到了专门的管理部门。从目前的管理效果和使用情况来看, 目前电力行业的数据质量情况不甚乐观。分析原因, 主要是管理方式太过于技术化, 或者说管理的规则太偏于技术, 不能与业务情况适时的相结合, 导致投入了大量的人力、物力治理的数据质量, 在应用层面效果仍不是很明显。数据的治理需要一套科学的治理规范和能与业务开展情况紧密结合的行为规则, 规则与业务的结合是数据治理工作的重点及难点。借助规则引擎机制来对电力行业的数据进行治理, 将对电力行业的数据质量提升工作带来质的飞跃。
规则生成引擎 篇8
在3G时代, 电信市场竞争相当激烈, 为留住客户或者争夺客户, 电信公司需要不断的推出新的业务或者对原来的业务进行优化调整, 以满足用户需求, 这就要求作为电信运营核心支撑系统的电信CRM系统必须具备快速的业务部署能力。而目前的CRM系统, 由于业务规则与系统功能硬绑定, 造成实现新业务或者需求变更时需要修改代码, 实现周期长, 开发成本高。因此我们需要根据CRM系统的特点, 设计一个能够应用在电信CRM系统中的电信CRM规则引擎, 以降低了系统的开发和维护成本, 提高需求支撑效率。
1 规则引擎技术
1.1 业务规则定义
一个完整的业务规则包括了条件和触发操作两部分内容。业务规则具有如下特性:原子性、申明性、准确性、一致性、非冗余性[1]。
电信业务规则是指在一定的业务场景中 (例如新建客户、订单录入、产品管理等) 被触发, 并通过管理和控制业务场景中涉及的业务实体 (例如客户、订单、产品等) 的属性、状态、行为和关系等来实现相应的业务逻辑。电信业务规则一般是由业务人员、配置人员以及开发人员来开发和维护, 其中复杂的业务规则一般是开发人员使用开发语言来定制。
1.2 规则引擎基本结构
规则引擎起源于基于规则的专家系统, 而基于规则的专家系统又是专家系统的其中一个分支[2]。
基于规则的专家系统结构如图1所示。推理引擎包括三个部分:模式匹配器、议程和执行引擎。模式匹配器的作用是负责将事实与规则进行匹配, 从而决定哪些规则符合事实;议程的作用是负责管理模式匹配器挑选出来的与事实匹配的规则的执行顺序;执行引擎则负责执行规则和相关动作[3]。
1.3 主流规则引擎与算法
1.3.1 JSR-94规范
过去大部分的规则引擎开发并没有规范化, 各自都有自己的API, 这样换一个规则引擎产品, 应用系统都需要重写业务规则以及调用规范引擎的代码, 代价比较大。2003年11月, 为了使规则引擎技术标准化, Java社区制定了Java规则引擎API (JSR94) [4]规范, 规范于2004年8月最终发布。
目前大部分的商用或者开源规则引擎均支持JSR-94规范, 如ILOG、Drools、JLisa, 但还有部分产品不支持此规范, 如Mandarax[5]、OFBiz Rule Engine[3]等。
1.3.2 Rete算法
Rete算法是在1979年Charles Forgy在论文中首次提出的, 它的基本思想是在模式匹配中利用推理机的时间冗余性和规则结构的相似性, 通过保留匹配过程得到的中间信息, 以空间代价来换取提高推理效率的一种模式匹配算法。因此Rete算法快速匹配的主要依据有两个:时间冗余性和结构相似性[5]。
1.3.3 Drools规则引擎
Drools是Jboss公司旗下一款开源的规则引擎, 是时下在Java开发人员中比较流行的一款开源规则引擎, 它符合JSR-94标准, 运行速度比较快, 而且提供了强大的Eclipse Plugin开发支持。Drools支持多种的冲突解决策略, 如优先级策略、后进先出策略、先进先出策略、随机策略、复杂性优先策略、简单性优先策略等, 而且允许灵活选择冲突解决策略[9]。
电信CRM系统定位和目标
电信CRM系统重点支撑以下业务目标:
(1) 系统能够满足电信客户和电信市场不断发展的需要, 为实现端到端的服务创造条件, 最大限度增加电信客户的满意程度。
(2) 实现综合、全面业务受理和处理。
(3) 对销售策略和销售渠道全面的支持, 保证企业各种经营方式的实施。
(4) 业务人员可操作的各种配置和定义功能, 包括:业务、产品、促销策略、价格、资源、流程、客户等的实体属性、各种实体关联等, 保证业务处理的灵活性。
(5) 个性化管理和服务, 同一个系统适应不同对象和不同阶段的业务要求。
(6) 对企业决策的支持和准备。
电信CRM系统功能架构
电信CRM系统的功能架构如图2所示。
自有与社会渠道管理:渠道是中国电信面向客户进行营销、销售和服务的载体, 是中国电信与客户进行交互的具体途径。渠道主要包括实体渠道、社会渠道、直销渠道和电子渠道。渠道管理提供针对渠道运营的管理支撑功能和客户接触交互支撑管理。渠道管理主要包括渠道信息管理、酬金考核管理、渠道工作支持和渠道交互支撑。
目前电信CRM系统架构
当前已经在生产上运营的电信CRM系统在系统架构上采用基于B/S模式的多层架构, 系统架构由展现层、应用层、信息存取层、信息资源层组成。CRM系统架构如图3所示。
3 电信CRM系统架构
展现层:展现层是CRM系统与接触渠道进行信息交互的平台, 通过界面集成技术将界面展现组件组合成用户界面。用户通过用户界面调用业务逻辑来实现业务功能。
应用层:这个层次是所有应用的基础。构件完成基本的系统或商务处理功能。这些功能通过服务向应用或外部提供。为了使构件提供的服务 (包括本系统和外系统甚至是企业外部的) 能够相互协调, 实现完整的业务功能, 就必须有构件运行环境和应用集成技术。
信息存取层:信息存取层实现系统的共享信息服务。该层实现对数据的封装, 并把封装后的数据转换成有价值的业务与系统信息, 向其上的应用层和其他相关外部系统提供一致的与业务逻辑无关的信息服务。
信息资源层:信息资源层负责系统的数据存储及维护数据的完整性与一致性。数据可以根据需要存储在数据库管理系统、文件、外部存储设备中。
4 基于规则引擎的电信CRM系统
4.1 现有架构的不足
与传统的C/S架构相比, 目前的多层架构将用户界面和内部逻辑分离, 使新应用的添加和变更比传统方式方便了许多, 因此能够适应大规模和复杂的应用需求, 并能有效降低建设和维护成本, 简化管理, 但是随着用户对需求的支撑速度要求的提高, 目前的架构还存在着一些不足。因为目前系统中管理和维护着大量的、各种复杂的业务规则, 但是按照目前的架构以及开发思路, 一般把实现客户需求的业务规则直接实现在应用代码中, 这样业务规则与系统功能硬绑定, 不但实现复杂繁琐, 而且后续维护困难。
4.2 引入规则引擎技术的电信CRM系统架构
为了能真正实现灵活性, 需要把业务逻辑与应用代码剥离。而规则引擎技术可以实现此目标, 因此可以在系统中引入规则引擎, 形成单独的业务规则层, 业务规则层向应用层提取规则判断服务, 应用层通过与规则层的交互实现业务逻辑的处理, 这个业务规则层与原来系统架构中的展现层、应用层和信息存取层、信息资源层就构成了基于规则引擎的CRM系统架构。基于规则引擎的CRM系统架构如图4所示。
通过业务规则层的引入, 使得整个CRM系统的各种应用能够使用一致的规则, 同时在业务规则变化时, 能够不用重新编写应用程序的代码, 就能很容易的修改和维护业务规则, 从而满足快速支撑用户多变的业务需求的需要。
5 结束语
本文首先对业务规则的概念以及规则引擎的原理进行了分析, 并介绍了JSR-94规范以及开源的Drools规则引擎。研究了电信CRM系统目前多层的系统架构, 并针对目前架构的不足之处, 提出了将规则引擎应用到CRM系统中, 并构建了增加业务规则层的多层技术架构模式。使得系统的应用变更更加方便, 从而提高了系统的开发效率并降低维护成本。
摘要：研究了电信CRM系统的功能架构。并针对目前系统架构的不足之处, 提出了将规则引擎应用到CRM系统中, 并构建了增加业务规则层的多层技术架构模式。使新应用的添加和变更比传统架构模式更加方便, 同时能够适应大规模和复杂的应用需求, 并有效降低建设和维护成本。
关键词：CRM,系统架构,规则引擎
参考文献
[1]Java规则引擎的工作原理及应用.http://java.chinaitlab.com/tools/380056.html
[2]李国乐.Java规则引擎与其API (JSR-94) .
[3]http://www-128.ibm.com/developerworks/cn/Java/j-Java-rules/.2005-7
[4]郭晓峰.规则引擎在新型农村合作医疗系统中的应用研究:[硕士学位论文].上海:东华大学, 2008
[5]张宇, 陈德礼.Drools规则引擎应用分析.福建电脑, 2007, (10) :11-12