本發(fā)明涉及電信業(yè)務工單處理領域，尤其涉及了一種業(yè)務工單的處理方法及系統。

背景技術：

現有技術中的業(yè)務工單處理方法存在以下缺點：

1、用戶業(yè)務工單中可能存在大量垃圾業(yè)務工單，當前臺業(yè)務量很大或有批量操作時，需要解析的業(yè)務工單數量增多，使得業(yè)務工單解析速率緩慢；同時，由于數據庫中業(yè)務工單數量過多，造成對數據庫的操作響應極慢，影響正常營業(yè)，甚至中斷營業(yè)；

2、在業(yè)務繁忙時，業(yè)務工單進入消息中間件以及策略中心后可能會滯留一段時間才能得到執(zhí)行，即存在業(yè)務工單積壓的可能，但有些業(yè)務又需要得到快速執(zhí)行，如用戶的開停機等重要業(yè)務，如積壓時間過長，不僅會引起客戶投訴，還可能造成收入流失；

3、在多種不同類型的業(yè)務的情況下，沒有辦法采用統一的配置，使得處理業(yè)務的時間長以及效率低，造成一些業(yè)務處理不及時。

技術實現要素：

本發(fā)明所要解決的技術問題是:目前現有技術中業(yè)務繁忙的時候，不同的業(yè)務工單會造成混亂，處理不及時、錯誤率高、效率低。

為解決上述技術問題，本發(fā)明提供了一種業(yè)務工單的處理方法，該方法包括如下步驟：

s1，通過消息中間件接收報文，對報文進行解析，將解析后的報文放入接口表；

s2，掃描接口表中的數據，根據策略規(guī)則表的配置對數據進行業(yè)務邏輯處理，并根據邏輯處理的結果判斷是否需要發(fā)送策略控制指令；

s3，若需要發(fā)送策略控制指令，則對需要發(fā)送策略控制指令的業(yè)務工單進行參數補充和策略分解，并將補充參數后的業(yè)務工單放入策略指令接口表；若是不需要，則結束；

s4，掃描策略指令接口表中的數據，并將數據同步發(fā)送到網絡激活中心，所述網絡激活中心與策略與計費規(guī)則功能單元進行網元交互，并更新業(yè)務工單。

本發(fā)明的有益效果：本發(fā)明通過實現配置對數據進行業(yè)務邏輯處理，提高了業(yè)務工單的處理效率，同時實現了業(yè)務工單配置的靈活化，更好地適配各類業(yè)務需求，大大降低了錯誤率。

進一步地，所述報文包括簽約數據、訂購數據、超套餐降速數據中的至少一種數據。

進一步地，所述的s4中具體包括：

s41，通過策略中心掃描策略指令接口表中的數據，通過應用集成平臺將數據同步到網絡激活中心；

s42，網絡激活中心激活業(yè)務工單后，所述網絡激活中心通過soap協議適配器與策略與計費規(guī)則功能單元進行網元交互；

s43，網絡激活中心接收策略與計費規(guī)則功能單元的網元應答，并更新業(yè)務工單。

進一步地，所述策略控制指令包括：業(yè)務與事件的映射指令、事件與動作的映射指令、動作與策略的指令。

進一步地，所述事件與動作的映射指令具體為：一個事件對應多個動作，在事件與動作映射關系表中存儲兩者之間的映射關系，根據事件返回的參數，查找參數是否與關系表的存在對應映射關系，若是執(zhí)行該動作與策略的映射指令；否則，不執(zhí)行。

進一步地，一個動作對應多個策略，在動作與策略映射關系表中存儲兩者之間的映射關系，根據動作返回的參數，查找參數是否與關系表的存在對應映射關系，若是執(zhí)行該動作與策略的映射指令；否則，不執(zhí)行。

進一步地，所述步驟s1中具體為：把業(yè)務工單的報文中的字段解析出來，插入到對應的表字段，并以服務工單的形式存儲在接口表中。

本發(fā)明還涉及一種業(yè)務工單的處理系統，該系統包括：消息接收模塊、策略引擎模塊、策略業(yè)務補參和分解模塊、網絡激活模塊；所述的消息接收模塊，用于通過消息中間件接收業(yè)務工單的報文，對業(yè)務工單的報文進行解析，將解析后的業(yè)務工單的報文放入接口表；所述的策略引擎模塊，用于掃描接口表中的數據，根據策略規(guī)則表的配置對數據進行業(yè)務工單的邏輯處理，并根據邏輯處理的結果判斷是否需要發(fā)送策略控制指令；所述的策略業(yè)務補參和分解模塊，用于根據是否需要發(fā)送策略控制指令的判斷，對需要發(fā)送策略控制指令的業(yè)務工單進行參數補充，并將補充參數后的業(yè)務工單放入策略指令接口表，若是不需要，則結束；所述的網絡激活模塊，用于掃描策略指令接口表中的數據，并將數據同步發(fā)送到網絡激活中心，所述網絡激活中心與策略與計費規(guī)則功能單元進行網元交互，并更新業(yè)務工單。

本發(fā)明的有益效果：通過本發(fā)明的業(yè)務工單處理系統，實現了業(yè)務的高效率處理，通過實現配置數據存儲在內存提高效率，對業(yè)務工單實現配置化、靈活化，更好地適配各類業(yè)務需求。

進一步地，所述的網絡激活模塊包括：

網絡激活同步單元，用于策略中心掃描策略指令接口表中的數據，通過應用集成平臺將數據同步到網絡激活中心；

網絡激活交互單元，用于網絡激活中心激活業(yè)務工單后，通過soap協議適配器與策略與計費規(guī)則功能單元網元交互；

網絡激活更新單元，網絡激活中心接收策略與計費規(guī)則功能單元(pcrf)的網元應答，并更新業(yè)務工單。

進一步地，所述的消息接收模塊具體用于通過消息中間件接收業(yè)務工單的報文，把業(yè)務工單的報文的字段解析出來，插入到對應的表字段，并以服務工單的形式存儲在接口表中。

附圖說明

圖1為本發(fā)明一種業(yè)務工單的處理方法流程圖；

圖2為本發(fā)明一種業(yè)務工單的處理系統示意圖；

圖3為本發(fā)明實施例1業(yè)務工單的處理方法示意圖；

圖4為本發(fā)明實施例2業(yè)務工單的處理方法示意圖。

具體實施方式

以下結合附圖對本發(fā)明的原理和特征進行描述，所舉實例只用于解釋本發(fā)明，并非用于限定本發(fā)明的范圍。

如附圖1所示的，本發(fā)明提供了一種業(yè)務工單的處理方法，該方法包括如下步驟：

s1，通過消息中間件接收報文，對報文進行解析，將解析后的報文放入接口表；billing/crm是通過消息中間件發(fā)過來的簽約、訂購、超套餐降速等事件信息，在本發(fā)明中的報文根據不同的時間，報文內容不一樣，報文格式可以是xml、json、mml；比如超套餐降速的報文字段有：業(yè)務流水、手機號碼、操作時間、已使用流量、套餐總流量等；本發(fā)明中的解析操作是把報文的字段解析出來，把事件名稱、服務流水、入表時間、初始狀態(tài)、請求時間、手機號碼、參數串等插入到對應的表字段，以服務工單的形式存儲在表中；

s2，掃描接口表中的數據，根據策略規(guī)則表的配置對數據進行業(yè)務邏輯處理，判斷是否需要發(fā)送策略控制指令；本發(fā)明中掃描接口表中的數據目的是掃描deal_status為0的數據進行處理。本發(fā)明中的策略規(guī)則表是指業(yè)務工單是否為4g卡用戶、是否訂購了上網放心寶、是否有新的訂購產生，從而判斷是否執(zhí)行發(fā)送策略控制指令；例如，超套餐降速屬于本發(fā)明中的在策略規(guī)則表中的業(yè)務邏輯處理，其處理方法如下：第一步，先判斷解析后得到的業(yè)務工單的報文是否為白名單用戶，是執(zhí)行發(fā)送策略控制指令同時執(zhí)行第二步，否執(zhí)行結束；第二步，判斷業(yè)務工單是否為usim卡，是執(zhí)行發(fā)送策略控制指令同時執(zhí)行第三步，否執(zhí)行結束；第三步，判斷業(yè)務工單是否為4g終端，是發(fā)送策略控制指令同時執(zhí)行第四步，否執(zhí)行結束；第四步，接著判斷業(yè)務工單是否有新的訂購在降速收費產生，是執(zhí)行發(fā)送策略控制指令同時執(zhí)行第五步，否執(zhí)行結束；第五步，如果上述四個步驟全部符合條件，則執(zhí)行降速。

s3，若需要發(fā)送策略控制指令，則對需要發(fā)送策略控制指令的業(yè)務工單進行參數補充和策略分解，并將補充參數后的業(yè)務工單放入策略指令接口表；若是不需要，則結束；在本發(fā)明中由于發(fā)送策略與計費規(guī)則功能單元網元指令的一些參數，需要從用戶信息表中提取，所以在入策略指令接口表的前，先把需要的參數補充到業(yè)務串里面。比如：網元平臺指令里面有imsi參數，需要通過手機號碼找到對應的imsi值，補到業(yè)務參數串里面。

s4，掃描策略指令接口表中的數據，并將數據同步發(fā)送到網絡激活中心，與策略與計費規(guī)則功能單元進行網元交互，并更新業(yè)務工單。

實施例1，如圖3所示的，一種業(yè)務工單的處理方法，該方法包括如下按步驟：

步驟1，crm服務處理用戶業(yè)務訂購信息，生成訂購實例，并將訂購實例同步至計費系統(ocs)；

步驟2，計費分析訂購實例，判斷業(yè)務類型，標準資費，日租類，實用業(yè)務計費無需同步，除此之外的業(yè)務需要同步；

步驟3，計費系統通過消息中間件將計費信息同步到策略中心；

步驟4，策略中心接收計費的業(yè)務訂購信息，更新本地庫；

步驟5，策略中心將業(yè)務訂購產生的業(yè)務策略信息，生成策略業(yè)務工單，計入策略工單表；

步驟6，策略中心從策略業(yè)務工單表掃描數據，通過應用集成平臺同步至網絡激活；

步驟7，網絡激活做業(yè)務工單激活，通過soap協議適配器與策略與計費規(guī)則功能單元網元通訊；

步驟8，網絡激活接收策略與計費規(guī)則功能單元網元應答，并更新業(yè)務工單狀態(tài)。

實施例2，如圖4所示的，一種業(yè)務工單的處理方法，該方法包括如下按步驟：

步驟1，crm涉及用戶簽約變化的業(yè)務，如開戶，銷戶，換號，用戶降速標識等，在訂單竣工后，由訂單管理發(fā)起用戶簽約請求，通過消息中間件，發(fā)給策略中心；

步驟2，計費系統通過流量計費，對超套餐流量的用戶，需要同步用戶配額標識，同樣，也是通過消息中間件，發(fā)給策略中心；

步驟3，維系挽留系統產生用戶等級變更信息，通過應用集成平臺，同步至策略中心；

步驟4，策略中心收到用戶簽約同步信息后，進行本地庫處理。如本地庫操作失敗，則記錄失敗原因，流程結束。如本地庫操作成功，則進入步驟5；

步驟5，策略中心將用戶簽約信息生成業(yè)務工單，發(fā)給網絡激活；

步驟6，網絡激活接收業(yè)務工單后，進行數據拼裝，參數替換，發(fā)給策略與計費規(guī)則功能單元；

步驟7，策略與計費規(guī)則功能單元處理后，網元返回應答結果給網絡激活應答結果。

如圖2所示的，本發(fā)明還涉及一種業(yè)務工單的處理系統，該系統包括：消息接收模塊、策略引擎模塊、策略業(yè)務補參和分解模塊、網絡激活模塊；所述的消息接收模塊，用于通過消息中間件接收業(yè)務工單的報文，對業(yè)務工單的報文進行解析，將解析后的業(yè)務工單的報文放入接口表；所述的策略引擎模塊，用于掃描接口表中的數據，根據策略規(guī)則表的配置對數據進行業(yè)務工單的邏輯處理，并根據邏輯處理的結果判斷是否需要發(fā)送策略控制指令；所述的策略業(yè)務補參和分解模塊，用于根據是否需要發(fā)送策略控制指令的判斷，對需要發(fā)送策略控制指令的業(yè)務工單進行參數補充和策略分解，并將補充參數后的業(yè)務工單放入策略指令接口表，若是不需要，則結束；所述的網絡激活模塊，用于掃描策略指令接口表中的數據，并將數據同步發(fā)送到網絡激活中心，所述網絡激活中心與策略與計費規(guī)則功能單元進行網元交互，并更新業(yè)務工單。

中國移動根據3gpp在r7版定義網絡資源與計費策略控制架構，旨在通過業(yè)務流承載資源保障以及流計費策略，為用戶提供差異化服務。3gpp標準定義的pcc架構主要由策略與計費規(guī)則功能單元(pcrf)、pcef、af、spr等功能實體組成，可有效實現lte網絡數據業(yè)務差異化的管理和運營，并提供業(yè)務端到端的質量保證，是lte網絡中實現語音業(yè)務等實時業(yè)務的關鍵。

策略控制中心在boss側分析用戶行為，實現保障類流量的控制和營銷類推薦的功能。

pcrf

本發(fā)明上述采用的pcrf是業(yè)務數據流和ip承載資源的策略與計費控制策略決策點，它為pcef(策略與計費執(zhí)行功能單元)選擇及提供可用的策略和計費控制決策。在3gpprelease8中，當使用gxx接口時，pcrf維護gw(網關)控制會話及ip-can(ip連接訪問網絡)會話之間的關聯。pcrf也是bberf(承載綁定及事件報告功能)及pcef之間的信息交換點，它行使bberf及pcef之間的事件觸發(fā)器的轉發(fā)，事件觸發(fā)器不能在bberf及pcef之間直接傳輸。

在本說明書中，對上述術語的示意性表述不必須針對的是相同的實施例或示例。而且，描述的具體特征、結構、材料或者特點可以在任一個或多個實施例或示例中以合適的方式結合。此外，在不相互矛盾的情況下，本領域的技術人員可以將本說明書中描述的不同實施例或示例以及不同實施例或示例的特征進行結合和組合。

以上所述僅為本發(fā)明的較佳實施例，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內。