規則引擎--移動結算系統開發

一、業務需求

1、 實現網間結算、網內結算、SP 業務結算

2、 支持語音、數據、SP 服務結算

3、 統一維護結算規則

4、 對結算話單進行批價

5、 對結算規則的維護進行權限控制

二、業務規則包的結構

由於每種結算話單的話單格式與結算規則區別較大,並且在進行話單批價時能夠明確知道要進行哪些批價規則運算。因此可以設計爲3個規則集。即網間結算規則集、網內結算規則集、與SP業務結算規則集。每個規則集都可以進行單獨的權限分配,可以進行單獨的部署

並在規則包的元數據模型上增加規則的創建人、生效與失效時間、以及規則狀態。在權限的分配上可以確定某些角色只能創建規則、某些角色可以審覈規則、某些角色可以發佈規則。並且只有審覈後的規則纔可以被髮布到生產系統上。

這些功能通過簡單的擴展VisualRules 規則包的結構,並通過定製擴展規則包權限控制方法來實現。

三、系統建模與BOM 書寫
以結算語音話單爲例,對結算話單書寫Java類,並把類導入到Rule Builder中創建BOM。編寫的Java類如下:
public class AccountOrder implements Cloneable {
//0呼叫類型
public int callType;
//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 guessAccessType;
//23入中繼羣服務類型
public string s23;
//23入中繼羣對端運營商

public int hostWanderType;


/
//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構建的業務支撐系統縮短了系統上線時間,並且系統更加穩定,更易於使用與維護,降低了系統的整體擁有成本。

http_imgload.jpg(88.72 KB)

下載次數:0

2011-7-6 16:24

http_imgload.jpg

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章