移动结算系统开发示例
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
移动结算系统开发示例
一、业务需求
1、实现网间结算、网内结算、SP 业务结算
2、支持语音、数据、SP 服务的结算
3、统一维护结算规则
4、对结算话单进行批价
5、对结算规则的维护进行权限控制
二、业务规则包的结构
由于每种结算话单的话单格式与结算规则区别较大,并且在进行话单批价时能够明确知道要进行哪些批价规则运算。因此可以设计为3个规则集。即网间结算规则集、网内结算规则集、与SP业务结算规则集。每个规则集都可以进行单独的权限分配,可以进行单独的部署。
并在规则包的元数据模型上增加规则的创建人、生效与失效时间、以及规则状态。在权限的分配上可以确定某些角色只能创建规则、某些角色可以审核规则、某些角色可以发布规则。并且只有审核后的规则才可以被发布到生产系统上。
这些功能通过简单的扩展VisualRules 规则包的结构,并通过定制扩展规则包权限控制方法来实现。
三、系统建模与BOM 书写
以结算语音话单为例,对结算话单书写Java类,并把类导入到Rule Builder中创建BOM。编写的Java类如下:
public class AccountOrder implements Cloneable {
//0呼叫类型
public int callT ype;
//1原始话单呼叫类型
public String s1;
//2话单序号
public String s2;
//3主叫号码
public String s3;
//4被叫号码
……
public String s15;
//16入中继群号
public String s16;
//17出中继群号
public String s20;
//21入中继群对端运营商
public int inRelayprovider;
//22入中继群归属地费率区号
public int guessAccessT ype;
//23入中继群服务类型
public string s23;
//23入中继群对端运营商
public int hostWanderT ype;
/
//38被叫接入号
public String s38;
……
//43
被叫号码服务类型
public int payOrient;
//50
结算费用
public double payMoney;
//51
六秒数
public double callSixTime;
//52
分钟数
public double callMinuteTime;
//53
五分钟数
public double callFiveMinuteTime;
//54
文件预处理日期
public String s54;
//55
详单入库时间
public String s55;
……
//
以下为一些属性get方法
}
然后在工程菜单条的部署设置菜单项中设置BOM对应的业务类路径,然后在BOM话单导入到管理
器中把该话单导入到BOM中,然后进行编辑。
在BOM中设置可以应用到规则定义的属性或方法,通过,并设置属性或方法的中文描述,以便业务使用人员可以使用中文来选择属性或方法来定义规则。
并在BOM管理器中创建相关的Domain选择类,以便实现某些值的枚举选择,例如话单类型,运营商列表等,并对话单的某些属性设置为为这些Domain。
四、书写规则
根据定义好的结算话单BOM模型在Rule Builder中书写结算规则,见下图:
对移动网间语音结算类型根据结算方运营商类型来组织规则,然后在规则编写时可以通过下拉列表来选择属性或有返回值的方法进行条件判定,对符合条件的来设置如何结算。
五、与应用进行集成
与应用集成采用J2SE的方式,创建规则引擎,在运行时把结算话单放入到规则引擎中,执行规则,最后得到批价好的话单。
……
//实例化规则引擎接口
RuleEngine engine = RuleEngineFactory. newInstance().getRuleEngine();
//传入规则包的参数值(传入数据)
engine.put(“accountOrder”,o);
//根据规则包调用名执行规则包
engine.excute (“网通IP落地”);
//取回规则包的参数值(传入数据)
engine.get(“flagleader.rules.firedRulesCount”);
……
这时accountOrder已经是批价完毕了。
六、应用系统的后续使用
这样系统构建完毕后,就可以交付给业务人员或维护人员使用了。业务人员
可以通过Web Builder来访问规则,包括新建规则、规则变更、查询规则等工作。
七、总结
使用VisualRules规则管理系统来开发规则集中的电信行业BSS系统具有以下优点:
1、缩短系统开发周期:使用基于VisualRules的系统开发对于IT人员更多的是关注系统架构,确定好系统架构之后的开发变得比较简单,可以直接集成VisualRules提供的丰富的组件与工具。
2、使系统更加易用:在系统开发过程中业务人员可以很容易地同技术人员一块构建系统,并及早地对系统进行验证,增加了系统的稳定性与可用性。
3、业务变更真正交付给业务人员/维护人员:系统在使用过程中的变更可以直接由业务人员/维护人员来实现,无需再走一个复杂的变更请求到技术人员。
4、变更被控制与管理起来:通过实现规则的生命周期的管理与直接使用规则包的版本管理和变更日志功能,所有的业务变更都可以通过授权、书写、审核、发布流程进行控制,并且变更历史被记录在规则包中,可以跟踪变更的轨迹。
5、变更由原来的产品发布周期变为业务发布周期:业务人员/维护人员可以直接通过变更规则来实现业务的变更,无需再通过变更代码、变更测试、系统变更版本发布的流程。只需执行业务规则变更、业务规则测试、新业务版本发布的流程,缩短了新业务的发布周期,增强了市场反应的敏捷性。
6、降低了整体拥有成本:使用VisualRules构建的业务支撑系统缩短了系统上线时间,并且系统更加稳定,更易于使用与维护,降低了系统的整体拥有成本。