基于BRMS的“旅游一卡通”計費系統的設計
文章出處：http://www.katarog.com 作者：張燕玲 潘正運 王莉 人氣： 發表時間：2012年01月23日
隨著科技不斷進步和信息化時代的到來，旅游行業的管理也在不斷地進行信息化的革命。單個獨立的應用系統已經不能滿足旅游系統綜合管理的需求，而對“旅游一卡通”系統的開發將有效地整合卡應用系統的信息資源，使游客在河南旅游時可以通過簡單的一張卡實現所有消費。但是由于“旅游一卡通”系統涉及到吃、住、行、游、購、娛6大要素，旅游行業間的競爭也越來越激烈，各個運營商要不斷地推出新的服務，有針對性地向用戶提供各種新的計費規則，及時回應競爭對手的策略變換。所有這些需求使得“旅游一卡通”系統的業務規則復雜多變，能否對其實行有效的管理就極大地依賴于“旅游一卡通”計費系統的有效支持。
在許多傳統的計費系統中，由于業務規則以程序代碼的方式“固化”在系統中，缺乏真正的靈活性，使運營商要推出新的服務或推出新的優惠計劃時，必須通過IT人員編寫代碼的方式來修改規則，然后經過繁復測試才能部署實施。這導致業務策略的變動周期非常的漫長。同時，由于業務規則是面向技術人員的程序代碼，使業務策略無法被業務人員真正的掌握和管理。而本文提出的一種基于業務規則管理系統的計費系統可以使業務規則與程序代碼分離，使得對業務規則能夠進行有效地管理和靈活的運用。
1 業務規則管理系統
1.1 業務規則管理系統概述
業務規則管理技術是伴隨著面向對象技術、軟件構件技術、人工智能、數據庫、XML(數據庫的表示)等相關技術的發展而出現的，具有規則管理、規則部署、規則分析、規則定制和設計功能。業務規則管理系統是一組工具集，包括：
(1)規則引擎(Rules Engine)：規則引擎是執行業務規則的軟件組件，它嵌入在程序中，是業務規則管理系統的核心元素。規則引擎的類型有：簡單型，數據中心型和面向事務型。
(2)規則庫(Rules Repository)：規則庫用于存儲規則和規則元數據(Meta Data)以及與規則有關的屬性。它提供一組工具用于存儲、分類、查詢、版本控制、權限控制、測試、提交等，規則的狀態和有效性可以跟蹤。
(3)規則語言框架(Rules Language Framework)：規則語言一般分為兩類:“面向程序技術”的規則語言，使用者是技術人員；“面向業務”的規則語言，使用者是業務人員。規則語言框架是為定制“面向業務”的規則語言提供支持。
(4)規則集成開發環境(Rules IDE)：一般規則集成開發環境只有規則編輯器，而高級的規則集成開發環境可以實現對規則和規則庫的管理：如規則的創建、分類、檢索、修改、版本控制、權限管理。
BRMS的模塊結構如圖1所示。
1.2 BRMS的基本原理
BRMS的基本原理是用一個或多個規則引擎替換“固化”在計費程序不同位置的業務規則(邏輯)的程序代碼。被替換的業務規則(邏輯)存儲在程序之外的規則庫中；規則庫中的規則可以通過圖形化規則管理工具實現定制、修改和部署，如圖2所示。
1.3 基于BRMS的系統開發
基于BRMS的系統開發可以劃分為3個階段：
(1)設計階段：這個階段與傳統的系統開發不同點在于，除了技術架構(包括規則引擎的位置安排)和基礎數據結構的設計之外，最主要是完成業務對象模型(BOM)的設計，為業務規則的開發提供必要的“詞匯”；定義規則的組織結構；設計業務規則的模板。
(2)開發階段：這個階段包括業務規則開發和系統程序的開發。
(3)部署階段：這個階段主要是業務規則服務的部署。業務規則服務(Rule Service)分布在系統的不同位置上，每個提供規則服務的模塊都嵌入了規則引擎，不同的規則服務可能使用不同的規則集。在這階段中，部署人員需要通過系統提供的方法或規則管理工具把不同的規則集部署到系統的對應位置上，使規則引擎可以訪問到它們需要的規則集。
2“旅游一卡通”計費系統的設計
“旅游一卡通”計費系統是利用BRMS技術對系統進行設計的，這樣可以使業務規則在系統外被定制，運營商無須開發人員介入，就可以讓他們的業務人員創建和修改規則。
在旅游計費系統中，業務規則時刻扮演著非常重要的角色。它能很好地把繁雜的計費規則，如優惠、折扣規則等提取到系統之外進行管理，同時配合高性能的規則引擎和友好的規則用戶界面，使得業務人員能夠迅速地根據市場的變化而改變它們的促銷策略。
2.1 系統總體結構
本系統在ILOG JRules上進行總體設計，選用J2EE為系統開發部署平臺，如圖3所示。JRules是由ILOG公司開發的一套業務規則管理系統的通用軟件，它可以為系統的開發提供圖形化的界面，具有完備的功能；J2EE平臺為設計、開發和部署業務規則應用程序提供了一種基于組件的方法。整個系統分為前臺Web客戶端顯示模塊和后臺處理模塊兩個部分。Web客戶端有兩種界面：
(1)針對業務定制人員的Web Rule Builder編譯器。業務人員通過在規則編輯器中編寫規則，然后將編輯的內容提交到后臺計費規則管理模塊中，由計費規則管理模塊對計費規則庫進行更新；另一方面，計費規則管理模塊可以通過遠程調用接口調用規則服務組件，將更新的規則直接作用于應用程序，以便于前臺規則使用人員使用新的規則對客戶進行計費處理。
(2)面向規則使用人員的Web App Portal。規則使用人員通過應用程序接口于計費規則會話Bean進行交互，同時激活規則服務組件對規則庫進行操作，取出符合需求的計費規則返回給應用程序接口，前臺計費業務人員根據相應的計費規則從客戶的“旅游一卡通”IC卡中扣除相應的金額。
圖3 BRMS旅游計費系統的總體結構
2.2 系統業務對象模型BOM(Business Object Model)的建立
業務規則模型的設計是基于規則系統的非常關鍵的步驟，它直接關系到整個系統是否能夠真正靈活地運轉起來。業務模型是由一組類(Class)構成，每個類包含屬性(Property)和一些方法(Method)。類的屬性、類與類的關系將會出現在業務規則的條件部分(Condition)，類中的屬性值與導入到引擎中的許多規則的條件進行匹配，如果某些對象(或對象之間的關系)滿足某個規則的條件的定義，那么引擎將觸發規則的執行部分。
2.2.1 業務對象的分析
“旅游一卡通”系統是一個復雜的消費系統，它不僅涉及消費者，而且整個旅游行業的所有企業，包括酒店、餐飲、旅行社、景區景點等都是組成這個系統的關鍵要素。建立完善的旅游計費系統就必須抽象出這些獨立業務對象的共性，建立統一的、具有共同特征的業務對象實體。在本系統的設計中，抽象出了以下業務對象：
(1)客戶(Customer)對象：這里的Customer對象是特指利用“旅游一卡通”進行消費的游客，是消費的主體。Consume對象在消費過程中可以享受相應的免費資源、折扣和優惠措施。在系統中該對象具有一定的類型屬性，根據不同的企業所定義的屬性值是不同的。
(2)企業(Enterprise)對象：Enterprise對象是指組成“旅游一卡通”系統的旅游部門，包括酒店、旅行社、景區景 點等。
(3)消費項目(Consume)對象：由于各個行業部門不同所以其中包含的消費項目也是大相徑庭的，所以將消費項目(Consume)單獨抽象為一個業務對象，使之與Enterprise對象相關聯。
(4)折扣方案(Discount)對象：折扣是計費系統中比較復雜的一項業務規則，它主要的特點就是經常變動。對于不同的客戶采取的折扣也是不同的。并且單位采取折扣的時間是有限制的，所以該對象具有時效性和有效性。
(5)優惠方案(Privilege)對象：優惠是計費系統的另一個重要組成部分，它同樣具有時效性和有效性。
2.2.2 業務對象模型的建立
各個業務對象之間存在著復雜的關聯。客戶這個業務對象是整個系統的消費主體，其消費行為通過“旅游一卡通”直接與所有系統中的企業對象實體相聯系。客戶在系統中消費時可能和多個企業對象相聯系，所以抽象其業務對象屬性CustomerEnterprise[]與消費企業對象進行關聯。
企業這個業務對象實體是整個計費系統得關鍵所在。因為系統中的企業是完全獨立的個體，在實施計費策略時是大不相同的，而且對于單個CustomerEnterprise對象內部不同消費項目的計費策略也不完全相同。每個CustomerEnterprise包括若干消費項目Consume，通過屬性Consume[]與消費項目實體相關聯；企業可能對所有的消費項目，也可能針對某消費項目實施折扣、優惠等方案，所以不單單是企業而且消費項目都與折扣、優惠和免費對象實體相關。它們通過屬性FreeItem[]與免費資源對象的關聯，通過DiscountPlan[]對象屬性與折扣方案對象關聯，通過PrivilegePlan[]與優惠方案對象關聯。
根據以上分析抽象系統的業務對象模型如圖4所示（略）。
2.3 規則引擎的嵌入和使用
業務規則引擎的嵌入和使用步驟。可以按照下面的基本步驟實現規則引擎的嵌入和使用(采用ILOG JRules的API)：
(1)創建一個規則引擎對象(這是ILOG JRules)提供的對象。
// Create an ILOG rule engine
IlrContext myEngine = new IlrContext();
(2)從規則庫中取得與計費相關的規則包，并加載到規則引擎中。(注意：這里折扣規則包存儲在名字是“Discount-rules”的文件中，優惠規則包存儲在“Privilege-rules”如果規則包保存在數據 庫中，需要使用其它的API)
//get the IlrRuleset associated with myContext
IlrRuleset myRuleset＝myContext.getRuleset()；
//Add rules to myRuleset
myRuleset.parseFileName(“Consume-rules”)；
myRuleset.parseFileName(“Discount-rules”)；
myRuleset.parseFileName(“Privilege-rules”)；
myRuleset.parseFileName(“FreeItem-rules”)；
(3)使用引擎的API，向規則引擎導入客戶對象(Customer)，企業對象(Enterprise)，該客戶的消費方案(Plan)，該客戶的優惠方案(Privilege)，折扣方案(Discount)和該客戶相關的有效免費資源(FreeItem)。引擎將對導入的所有對象的屬性值與當前加載的規則包中的優惠規則進行匹配比對，把匹配的規則放在一個規則執行隊列中。
myEngine.insert(Customer);//提交客戶信息
myEnterprise.insert(Enterprise);//提交企業信息
for (int ii=0;ii<…; ii++
{ //提交與企業相關的消費項目信息
myEngine.insert(Consume[ii]);
}
for (int ii=0;ii<…; ii++
{ //提交該客戶相關的免費資源信息
myEngine.insert(freeItem[ii]);
}
for (int ii=0; ii<……; ii++) {//提交該客戶相關優惠方案信息
myEngine.insert(Privilege [ii]);
}
for (int ii=0; ii<……; ii++) {//提交該客戶相關折扣方案信息
myEngine.insert(Discount[ii]);
}
(4)使用引擎的API，通知引擎執行規則執行隊列中的規則實例，即觸發規則執行部分的方法。在引擎逐個執行規則的過程中，會出現這樣一些可能操作：一些對象的屬性值將會被修改(如免費資源的可用量會減少)；有些新的對象被創建，如新的免費資源被生成等。引擎會在每個規則被執行之后會自動作這樣的檢驗：當前狀態下，“規則執行隊列”中等待執行的規則是否還滿足條件，剔除不滿足條件的等待執行的規則；同時檢查規則包中原來沒有在“執行隊列”的規則是否符合當前狀態的規則，如果有則把它們加入到“執行序表(Agenda)”中。引擎最終會清空“執行隊列”。
// execute the rules on the agenda
myEngine.fireAllRules();
使用引擎的API把引擎中的對象取出并導出(如回存數據庫等)
// retrieve updates objects from engine
myEngine.getObjects();
// output code…
…
// empty engines for next time use
myEngine.removeObjects(); //從引擎中撤除所有對象，為下一//個優惠處理作準備。
3 結束語
本文對BRMS系統在“旅游一卡通”計費系統中的應用與開發進行了研究。本系統的設計大大簡化了對“旅游一卡通”計費系統業務規則的開發與管理，該系統是目前比較符合實際的較為理想的“旅游一卡通”計費系統。它的應用必將極大地提高旅游市場計費業務規則的管理效率，具有廣闊的市場前景。
