规则引擎在酬金结算系统的应用

［梁伟晟］

规则引擎在酬金结算系统的应用

［梁伟晟］

酬金结算是社会渠道管理的重要组成部分。介绍了规则引擎技术的原理，提出了规则引擎在酬金结算系统中的实现方案，给出了系统技术架构，详细讨论了酬金计算处理流程、模型设计、规则设计和测试。

酬金规则 规则引擎 酬金结算

梁伟晟

中国移动通信集团广东有限公司，博士，高级工程师，现主要从事业务运营支撑系统方案设计和开发管理工作。

1 概述

业务规则是描述和支持企业决策、营销策略和业务运营，影响和控制业务行为的规章条例。在渠道酬金结算中，酬金业务规则复杂、变动频繁。传统上，酬金规则融合在应用系统的代码当中，酬金规则制定、酬金规则应用开发、酬金实际结算相互分离。由于缺乏对酬金规则进行管理的方法和标准的规则语言，使得酬金结算的效率和准确性存在一定问题。

酬金结算是渠道管理中的重要环节，需要有一个灵活、高效的应用系统提供支持。通过引入规则引擎技术，将酬金规则与酬金结算处理流程分离，提供一种基于规则引擎的酬金结算体系，使得规则变化时，结算逻辑尽量不变，从而尽量减少系统的升级改造。同时，提供酬金规则的自动化编辑管理环境，方便管理灵活、易变的业务规则，使得酬金规则制定人参与到酬金结算处理的过程中。

一个完整的业务规则包括了条件和触发操作两部分内容。规则引擎包括三个部分：模式匹配器（Pattern Matcher）、议程（Agenda）和执行引擎（Execution Engine），如图1所示。模式匹配器负责将事实与规则进行匹配，从而决定哪些规则符合事实；议程负责管理模式匹配器挑选出来的与事实匹配的规则的执行顺序；执行引擎则负责执行规则和相关动作。规则引擎通过决定哪些规则满足事实或目标，并授予规则优先级，满足事实或目标的规则被加入议程。

图1 规则引擎

2 方案

为了简化业务规则变更的过程，提高业务规则的可管理性，业务规则管理模块被引入到酬金结算系统中，如图2所示。业务规则管理模块用一个或者多个规则引擎替换用程序编码或者抽象伪代码形式实现的业务规则，被替换的业务逻辑存储在程序外的规则库中，规则库中的规则可以通过图形化规则管理工具实现设计、修改、审核、测试和部署。通过业务规则管理模块实现对渠道酬金管理中业务规则的全程管理。

图2 系统架构

2.1 酬金计算处理

酬金计算首先要对业务数据建模。从业务规则分析出酬金结算的计算要素，建立起与规则库相匹配的数据模型。业务规则使用接近自然语言的规则语言编辑维护，保存在规则库中。酬金结算的原始数据来自生产系统，通过数据转换形成酬金计算所需要的业务数据。在计算酬金时，准备好的业务数据输入到规则引擎，规则引擎挑选出相应匹配的业务规则执行，运算得到酬金结果数据。酬金计算处理流程如图3所示。

图3 酬金计算处理过程

渠道运营业务数据庞大而且复杂，为了从中选择结算所需要的数据，必须充分理解实际业务需求。在抽取数据时，需要对数据进行预处理，设计数据中间表对数据进行抽取、清洗，例如清理异常和不相关数据，提取结算系统关心的数据，生成规则引擎所需要的数据对象。数据预处理有利于加快酬金计算处理过程。

酬金计算要素与数据抽取和业务建模密切相关，需要分析识别出业务规则中的计算要素。将业务规则需求以原子化拆解的方式，从中分离出各种计算要素。酬金业务规则通常由适用产品/业务名称、有效性校验规则、酬金标准、结算原则组成，如补/换卡业务规则是系统成功办理后次月结算2元。从业务规则中得到业务名称、成功办理、结算月份、结算金额等计算要素作为数据抽取和业务建模的基础。

2.2 XOM/BOM模型设计

执行对象模型（XOM）定义了业务规则会使用到或者作用到的应用程序类，是规则引擎执行规则过程中所使用的对象。业务对象模型（BOM）是XOM的一个映射，将XOM中的程序描述语言映射成业务描述语言，如：将agentName属性映射成“渠道名称”，将circle属性映射成“考核周期”，方便业务人员维护规则。XOM是规则执行的物理模型，BOM是规则执行的业务模型。应用程序与规则引擎之间使用业务对象模型BOM做接口，要求传入和传出的对象属性必须是固定的。

例如渠道信息的XOM设计

class ccp AgentInfo

～agentName：string

～agentLevel：string

～agentID：string

～agentDistrict：string

+getAgentName（）：string

+getAgentName（string）：void

+getAgentLevel（）：string

+getAgentLevel（string）：void

+getAgentID（）：string

+getAgentID（string）：void

+getAgentDistrict（）：string

+getAgentDistrict（string）：void

+AgentInfo（string，string，string，string）

+AgentInfo（）

渠道信息的BOM设计

对应XOM类 AgentInfo 渠道信息

agentName ｛this｝ 的｛渠道名称｝

agentLevel ｛this｝ 的｛渠道级别｝ 普通渠道；优质渠道；其他渠道

agentID ｛this｝ 的｛渠道编码｝ 即业务受理渠道ID

agentDistrict ｛this｝ 的｛渠道区域｝

2.3 规则设计

表达和定义业务规则有多种方法，最好的方法是将它看作业务流程中的决策点，以决策表的形式表现，特别是组合判定条件复杂的业务规则。业务规则是以“if-thenelse”类型的逻辑描述的，其中if（如果）是所满足的一组特定业务条件，then（那么）是所执行的特定操作，else（否则）是可以执行的其他某些操作。酬金规则通常有一些基础的考核条款，是所有酬金类型必须满足的稽核条件。将基础考核条款设计为公共业务规则，所有酬金计算先调用公共业务规则，再调用酬金类型对应的规则，公共业务规则不满足即可判定考核不通过。这样可以简化规则维护，加快酬金计算处理的过程。

如业务规则：按照首期酬金判定的主要使用号码成功发放第一笔酬金后，主要使用号码不得更换，否则后续酬金不予发放；每期酬金在稽核时均要求号码状态为正常使用，且上月ARPU不低于30元，否则酬金不予发放。转化为类自然语言的规则是：

如果

'当前客户状态数据'的主号码更换是"N"

并且 '当前客户状态数据'的号码状态正常是"Y"

并且 '当前客户状态数据'的arpu值大于等于 30

并且 '当前客户状态数据'的退销售标记是"N"

那么

设置 '基本条件考核' 为 "通过"

否则

设置'基本条件考核' 为 "不通过"

2.4规则测试（如图4所示）

在业务规则部署之前，规则开发人员需要对规则集合进行整体测试，以确保上线的规则的绝对正确。业务规则测试包含两方面的工作：调试测试和验证测试。其中，调试测试是规则集合开发过程中的测试，主要目的是测试规则的技术正确性；验证测试是规则部署之前的最后测试，主要目的是测试规则的业务正确性。另外为了评估业务规则新版本的影响，还需要进行版本对比测试，通过输入相同的业务数据，对比不同规则版本的酬金计算结果。

图4 规则版本模拟比对

3 结束语

在酬金结算系统引入业务规则引擎后，系统设计的关注点在于管理灵活、易变的业务规则，酬金规则制定人参与到酬金结算处理的过程中。我们对规则引擎应用到酬金结算系统进行了探索，提出了在酬金结算系统的实现方案。在实际应用中运用和管理好业务规则，将会充分发挥业务规则引擎技术的优势，使得系统对业务的推广提供更好的支撑，对市场的需求做出更迅速的响应。

1 费立君，姜元东.规则引擎在电信行业信控系统中的应用［J］.黑龙江科技信息，2013年第14期

2 丁渊.规则引擎技术分析及在电信计费系统中的应用［J］.邮电设计技术，2011年第7期

3 廖焕祥.基于电信全业务话单处理的规则引擎［J］.网络安全技术与应用，2014年第11期

4 王冬久.电信运营商社会渠道酬金支撑体系建设探索［D］.北京邮电大学，2013

图5 家庭基站部署方案

图6 异构多基站部署方案

参考文献

1 LTE-Advanced关键技术详解，林辉，焦慧颖，2012，人民邮电出版社

2 4G移动通信技术权威指南，Erik Dahlman Stefan Parkvall Johan Skold 堵久辉译，2012，人民邮电出版社

3 LTE-A和下一代无线网络-信道建模与传播，张建华，田磊，刘光毅译，2015，电子工业出版社

（收稿日期：2016-03-11）

10.3969/j.issn.1006-6403.2016.08.005

2016-08-03）