專利名稱：一種防止mbbms業(yè)務系統(tǒng)各網(wǎng)元信息不一致的方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及廣播式手機電視技術(shù)領(lǐng)域，尤其涉及一種防止MBBMS業(yè)務系統(tǒng)各網(wǎng)元 信息不一致的方法及系統(tǒng)。
背景技術(shù)：
因為手機電視業(yè)務的飛速發(fā)展，MBBMS (Mobile Broadcast BusinessManagement System、廣播式手機電視業(yè)務管理系統(tǒng))日漸成為移動的主推規(guī)范，其中涉及到了眾多的 網(wǎng)元，包括，手機電視業(yè)務管理系統(tǒng)(以下簡稱NAF)，廣播運營商支撐系統(tǒng)(以下描述中以 廣電BOSS為例)，通信運營商支撐系統(tǒng)(以下描述中以中移BOSS)，廣電CAS系統(tǒng)等，用戶 相關(guān)的開通、訂購、密鑰請求等操作流程需要依次通過這些網(wǎng)元才可完成最終的流程。
如圖1所示，一個標準的開通或者訂購操作由以下六個步驟組成
步驟101，終端發(fā)起業(yè)務請求； 用戶在終端界面上發(fā)起開通或者訂購的操作，消息通過w即網(wǎng)關(guān)發(fā)送到手機電視 業(yè)務管理系統(tǒng)NAF，由NAF進行受理操作。 步驟102， NAF根據(jù)所述業(yè)務請求向廣電BOSS發(fā)送確認消息； 確認消息由NAF向廣電BOSS發(fā)起，確認用戶是否符合開通或者訂購的條件，正常
的話流程繼續(xù)，確認消息本身不會產(chǎn)生數(shù)據(jù)庫的更改操作。 步驟103， NAF將廣電BOSS返回的確認消息同步給中移BOSS ; NAF通過BOSS接口機向中移BOSS請求用戶的開通或者訂購操作，中移BOSS實施
扣費等預操作之后，給BOSS接口機回確認消息，BOSS接口機給中移BOSS回正確響應，中移
BOSS進行事務的提交操作，接口機通知NAF進行下一步處理。 步驟104， NAF保存用戶信息； NAF在數(shù)據(jù)庫中保存用戶的本次操作信息。 步驟105， NAF將中移BOSS發(fā)送的確認信息同步至廣電BOSS ;NAF向廣電BOSS同步本次操作，使廣電BOSS更新用戶信息，廣電BOSS向CAS同
步，CAS更新用戶信息。 步驟106， NAF向終端返回處理狀態(tài)； NAF向終端返回的處理狀態(tài)是步驟103中中移BOSS的處理結(jié)果。
該方案存在以下不足若步驟104和步驟105中數(shù)據(jù)保存不成功，或用戶消息同步 不成功，則會導致廣電BOSS保存的狀態(tài)為不成功，中移BOSS保存的狀態(tài)為成功，從而使得 NAF，廣電BOSS, CAS和中移BOSS的用戶信息存在不一致。 上述情況則會導致用戶看到的響應是成功，但是卻無法正常看到訂購節(jié)目的問 題。

發(fā)明內(nèi)容
本發(fā)明實施例提供一種防止MBBMS業(yè)務系統(tǒng)各網(wǎng)元信息不一致的方法及系統(tǒng)，用于克服現(xiàn)有技術(shù)中因為網(wǎng)元故障導致各網(wǎng)元數(shù)據(jù)保存不一致的問題。 —種防止MBBMS業(yè)務系統(tǒng)各網(wǎng)元信息不一致的方法，當用戶終端向手機電視業(yè)務管理系統(tǒng)發(fā)起操作請求時，包括 手機電視業(yè)務管理系統(tǒng)NAF將所述操作請求的相關(guān)數(shù)據(jù)作為臨時記錄插入預設(shè)的臨時表中，并在該條記錄中添加第一標記； NAF向通信運營商支撐系統(tǒng)和廣播運營商支撐系統(tǒng)同步計費信息，并在接收到成功響應后，更新自身數(shù)據(jù)庫將所述第一標記更新為標示通信運營商支撐系統(tǒng)處理成功的第二標記； 如果更新所述第一標記不成功，NAF刪除所述臨時記錄。
—種防止MBBMS業(yè)務系統(tǒng)各網(wǎng)元信息不一致的系統(tǒng)，包括 手機電視業(yè)務管理系統(tǒng)NAF，用于在接收終端發(fā)起的操作請求后，將所述操作請求
的相關(guān)數(shù)據(jù)作為臨時記錄插入預設(shè)的臨時表中，向通信運營商支撐系統(tǒng)和廣播運營商支撐
系統(tǒng)同步計費信息，并在接收到成功響應后，更新自身數(shù)據(jù)庫將所述臨時記錄中的第一標
記更新為標示通信運營商支撐系統(tǒng)處理成功的第二標記；如果更新所述第一標記不成功，
刪除所述臨時記錄，并向通信運營商支撐系統(tǒng)和所述終端返回錯誤響應； 廣播運營商支撐系統(tǒng)和通信運營商支撐系統(tǒng)，用于接收NAF發(fā)送來的確認請求，
并在驗證所述確認請求后返回成功響應。 應用本發(fā)明實施例提供的方法和系統(tǒng)利用已有網(wǎng)元系統(tǒng)的特點將消息同步時的每個處理狀態(tài)都進行記錄，如果出現(xiàn)異常則通知用戶終端和各網(wǎng)元，避免各網(wǎng)元的用戶數(shù)據(jù)出現(xiàn)不一致的現(xiàn)象。


圖1本發(fā)明實施例現(xiàn)有技術(shù)的流程圖； 圖2本發(fā)明實施例中廣電BOSS和中移BOSS都成功確認用戶請求的實現(xiàn)流程圖； 圖3本發(fā)明實施例中NAF本身用戶信息的保存失敗時的實現(xiàn)流程圖； 圖4本發(fā)明實施例中當廣電BOSS的處理失敗時的實現(xiàn)流程圖； 圖5本發(fā)明實施例中實際應用時的實現(xiàn)流程圖； 圖6本發(fā)明實施例所提供的系統(tǒng)的結(jié)構(gòu)圖。
具體實施例方式
本發(fā)明實施例提供一種防止MBBMS業(yè)務系統(tǒng)各網(wǎng)元信息不一致的方法，下面結(jié)合附圖對本發(fā)明實施例的處理流程做進一步的說明 如圖2所示，本發(fā)明實施例中，當用戶進行開通、訂購、密鑰請求等操作流程時，本發(fā)明實施例中通信運營商支撐系統(tǒng)和廣播運營商支撐系統(tǒng)分別以廣電BOSS和中移BOSS為例進行說明，該實施例中廣電BOSS和中移BOSS都成功確認所述請求(即各網(wǎng)元均處理正常的流程)，則該的具體流程包括 步驟201，用戶通過手機終端發(fā)起開通或者訂購業(yè)務的操作時，終端通過w即網(wǎng)關(guān)
向NAF服務器發(fā)起請求，NAF服務端對終端進行http digest 4步鑒權(quán)認證。 步驟202， NAF在臨時表中插入一條臨時記錄，并在該條記錄中添加第一標記(實現(xiàn)的方式可以是將該條記錄的標記位置為0)，該條記錄用于記錄所述請求的相關(guān)數(shù)據(jù)，該條記錄中包括所述請求的操作類型、流水號、時間戳等信息。 步驟203， NAF向廣電BOSS發(fā)起開通確認請求或訂購確認請求，等待廣電BOSS的響應。 步驟204， NAF接收廣電BOSS返回的響應消息，得到用戶可以開通或者訂購的結(jié)果； 步驟205，向中移BOSS發(fā)起請求，準備同步用戶的開通或者訂購狀態(tài)。 步驟206，中移BOSS返回響應標識已收到請求正在做進一步處理，NAF繼續(xù)等待中
移BOSS的確認消息。 步驟207， NAF收到中移BOSS的確認消息，對消息進行解析處理，得到的返回碼為正常值。 步驟208， NAF將所述第一標記更新為標示移用戶支撐系統(tǒng)確認成功的第二標記(即將所述0更新為第二標記2)，標識當前的處理進度。 步驟209， NAF組http包向廣電BOSS發(fā)起同步請求，等待廣電BOSS的同步響應。
步驟210， NAF收到廣電BOSS的同步響應數(shù)據(jù)，分析處理結(jié)果為成功；
步驟211， NAF組包向中移BOSS返回確認消息的成功響應，中移BOSS收到成功的響應消息，實施用戶扣費操作，在操作完成后，向NAF返回成功響應。 步驟212，接收到中移B0SS返回的成功響應后，將臨時表記錄中的第二標記更新
為第三標記(即，將標記位2置為1表示最終狀態(tài))，向輪詢線程模塊發(fā)送消息，輪詢線程檢
測臨時表中標記為1的記錄，進行實際的開通或訂購數(shù)據(jù)庫表更新操作。 步驟213，NAF將成功處理的結(jié)果反饋給終端，刪除會話信息表。 當網(wǎng)元處理失敗時，本發(fā)明方法的具體實現(xiàn)方法包括，網(wǎng)元處理失敗的情況在本
發(fā)明實施例中，主要是廣電BOSS的處理失敗和NAF本身用戶信息的保存失敗 如圖3所示，當NAF本身用戶信息的保存失敗時，本發(fā)明實施例的具體步驟包括 步驟301，用戶通過手機終端發(fā)起開通或者訂購操作之一，終端通過w即網(wǎng)關(guān)向
NAF服務器發(fā)起請求，NAF服務端對終端進行http digest 4步鑒權(quán)認證。 若鑒權(quán)成功，流程繼續(xù)往下，若鑒權(quán)失敗，NAF返回給終端錯誤消息，此時整個流程
結(jié)束，不會產(chǎn)生問題。 步驟302， NAF在臨時表中插入一條臨時記錄，標識用戶的此次操作類型、流水號等信息，置該條記錄的標記為0，同時加上時間戳。 步驟303， NAF向廣電BOSS發(fā)起開通確認請求或訂購確認請求，等待廣電BOSS的響應。 步驟304，接收廣電B0SS的響應消息，得到用戶可以開通或者訂購的結(jié)果，若確認消息返回失敗，那么NAF直接刪除該臨時表記錄，返回給終端錯誤響應，整個流程結(jié)束。
步驟305，若確認消息正常，NAF向中移BOSS發(fā)起請求，準備同步用戶的開通或者訂購狀態(tài)。 步驟306，中移BOSS返回響應消息標識已收到請求正在做進一步處理，NAF繼續(xù)等待中移BOSS的確認消息，若NAF收到的中移BOSS消息超時或確認消息失敗，那么NAF直接刪除臨時表中的記錄，返回給終端錯誤響應，整個流程結(jié)束，若中移BOSS的確認消息結(jié)果
6為成功，則轉(zhuǎn)入步驟307。 步驟307， NAF將插入臨時表中對應記錄的標記位更改為2，標識當前的處理進度，若更新所述標記位失敗，則NAF向中移BOSS返回確認消息的失敗響應，同時將對應的臨時表的記錄刪除，返回給終端錯誤響應，整個流程結(jié)束，各網(wǎng)元的記錄都未發(fā)生改變；
若是因為數(shù)據(jù)庫異常導致刪除也失敗，那么輪詢線程會定時根據(jù)臨時表記錄中的時間戳刪除過期的數(shù)據(jù)。 如圖4所示，當廣電BOSS的處理失敗時，本發(fā)明實施例的具體步驟包括 步驟401，用戶通過手機終端發(fā)起開通或者訂購操作之一，終端通過w即網(wǎng)關(guān)向
NAF服務器發(fā)起請求，NAF服務端對終端進行http digest 4步鑒權(quán)認證。 若鑒權(quán)成功，流程繼續(xù)往下，若鑒權(quán)失敗，NAF返回給終端錯誤消息，此時整個流程
結(jié)束，不會產(chǎn)生問題。 步驟402， NAF在臨時表中插入一條記錄，標識用戶的此次操作類型、流水號等信息，置該條記錄的標記為0，同時加上時間戳。 步驟403， NAF向廣電BOSS發(fā)起開通確認請求或訂購確認請求，等待廣電BOSS的響應。 步驟404， NAF收到廣電BOSS的響應消息，得到用戶可以開通或者訂購的結(jié)果，若確認消息返回失敗，那么NAF直接刪除該臨時表記錄，返回給終端錯誤響應，整個流程結(jié)束。 步驟405，若確認消息正常，NAF向中移BOSS發(fā)起請求，準備同步用戶的開通或者訂購狀態(tài)。 步驟406，中移BOSS返回響應消息標識已收到請求正在做進一步處理，NAF繼續(xù)等待中移BOSS的確認消息，若NAF收到的中移BOSS消息超時或確認消息失敗，那么NAF直接刪除臨時表中的記錄，返回給終端錯誤響應，整個流程結(jié)束，若中移BOSS的確認消息結(jié)果為成功，則轉(zhuǎn)入步驟407。 步驟407，NAF將插入臨時表中對應記錄的標記位更改為2，標識當前的處理進度。
步驟408， NAF組http包向廣電BOSS發(fā)起同步請求，等待廣電BOSS的同步響應。
步驟409，若廣電的同步消息返回失敗的響應，那么NAF將臨時表中對應記錄的標記修改為0，同時刪除該條記錄組包向中移BOSS返回確認消息的失敗響應，中移BOSS自己處理回滾流程，NAF向終端返回失敗響應，整個流程結(jié)束，各網(wǎng)元的用戶狀態(tài)未發(fā)生變化。
若是因為數(shù)據(jù)庫異常導致刪除也失敗，那么輪詢線程會定時根據(jù)臨時表記錄中的時間戳刪除過期的數(shù)據(jù)。 步驟410，若廣電B0SS的同步響應消息為正常，那么NAF將臨時表中對應的記錄的標記置為1，同時組包向中移BOSS返回確認消息的成功響應，中移BOSS實施扣費操作，NAF向輪詢線程發(fā)送消息，使本次用戶的請求更新到實際的數(shù)據(jù)庫中；若臨時表中對應記錄的標記置1失敗，NAF向輪詢模塊發(fā)送標記失敗的流水號信息，輪詢模塊將該數(shù)據(jù)寫入文件中去以做記錄，隨后輪詢模塊嘗試重新更新數(shù)據(jù)庫中的標記，直到成功為止；同時將該異常上報至告警板，及時通知操作人員檢查是否數(shù)據(jù)庫出現(xiàn)故障，若數(shù)據(jù)庫出現(xiàn)故障，那么在數(shù)據(jù)庫恢復后輪詢模塊會根據(jù)文件中記錄的流水號繼續(xù)進行嘗試直到更新成功。
步驟411，若無其他異常，NAF向終端反饋處理結(jié)果；輪詢線程會定期檢查臨時表
7中的記錄，對于過期數(shù)據(jù)實施刪除操作。 在實際的應用環(huán)境中，在廣電BOSS、中移BOSS以及NAF出現(xiàn)問題時任一網(wǎng)元出現(xiàn)問題時，本發(fā)明實施例具體包括如圖5所示的處理步驟。 如圖6所示，本發(fā)明實施例還提供一種防止MBBMS業(yè)務系統(tǒng)各網(wǎng)元信息不一致的系統(tǒng)，包括手機電視業(yè)務管理系統(tǒng)(NAF)601、廣播運營商支撐系統(tǒng)602和通信運營商支撐系統(tǒng)603 : 手機電視業(yè)務管理系統(tǒng)(NAF)601，用于在接收終端發(fā)起的操作請求后，將所述操作請求的相關(guān)數(shù)據(jù)作為臨時記錄插入預設(shè)的臨時表中，向通信運營商支撐系統(tǒng)603和廣播運營商支撐系統(tǒng)602同步計費信息，并在接收到成功響應后，更新自身數(shù)據(jù)庫將所述臨時記錄中的第一標記更新為標示通信運營商支撐系統(tǒng)603處理成功的第二標記；如果更新所述第一標記不成功，刪除所述臨時記錄，并向通信運營商支撐系統(tǒng)603和所述終端返回錯誤響應； 廣播運營商支撐系統(tǒng)602，用于接收NAF發(fā)送來的確認請求，并在驗證所述確認請求后返回成功響應； 通信運營商支撐系統(tǒng)603，用于接收NAF發(fā)送來的確認請求，并在驗證所述確認請求后返回成功響應。 所述手機電視業(yè)務管理系統(tǒng)601還用于如果更新所述第二標記成功，則向所述廣播運營商支撐系統(tǒng)602發(fā)送同步請求，若接收到廣播運營商支撐系統(tǒng)602返回的失敗響應，則刪除所述臨時記錄，并向所述通信運營商支撐系統(tǒng)603和終端返回失敗響應。
進一步，所述手機電視業(yè)務管理系統(tǒng)601還用于向所述廣播運營商支撐系統(tǒng)602發(fā)送同步請求之后，若接收到廣播運營商支撐系統(tǒng)602返回的成功響應，則將所述第二標記更新為標示廣播運營商支撐系統(tǒng)602確認成功的第三標記，并向通信運營商支撐系統(tǒng)603返回確認消息的成功響應；向輪詢線程發(fā)送消息，將所述操作請求的相關(guān)數(shù)據(jù)更新到自身數(shù)據(jù)庫中。 采用盡可能少的回滾機制和利用已有網(wǎng)元系統(tǒng)的特點處理各網(wǎng)元消息同步時出現(xiàn)的異常，避免各網(wǎng)元的用戶數(shù)據(jù)出現(xiàn)不一致的現(xiàn)象，同時給予終端用戶比較直觀的提示，另外該方法對于MBBMS平臺的外部網(wǎng)元不需要修改，主要集中在NAF的處理流程上做改進。
應用本發(fā)明實施例提供的方法和系統(tǒng)可以應用盡可能少的回滾機制和利用已有網(wǎng)元系統(tǒng)的特點處理消息同步時出現(xiàn)的異常，避免各網(wǎng)元的用戶數(shù)據(jù)出現(xiàn)不一致的現(xiàn)象。同時給予終端用戶比較直觀的提示，另外該方法對于MBBMS平臺的外部網(wǎng)元不需要修改，主要集中在NAF的處理流程上做改進。 本發(fā)明所述的方法并不限于具體實施方式
中所述的實施例，本領(lǐng)域技術(shù)人員根據(jù)本發(fā)明的技術(shù)方案得出其它的實施方式，同樣屬于本發(fā)明的技術(shù)創(chuàng)新范圍。顯然，本領(lǐng)域的技術(shù)人員可以對本發(fā)明進行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權(quán)利要求及其等同技術(shù)的范圍之內(nèi)，則本發(fā)明也意圖包含這些改動和變型在內(nèi)。
權(quán)利要求
一種防止MBBMS業(yè)務系統(tǒng)各網(wǎng)元信息不一致的方法，當用戶終端向手機電視業(yè)務管理系統(tǒng)發(fā)起操作請求時，其特征在于，包括手機電視業(yè)務管理系統(tǒng)NAF將所述操作請求的相關(guān)數(shù)據(jù)作為臨時記錄插入預設(shè)的臨時表中，并在該條記錄中添加第一標記；NAF向通信運營商支撐系統(tǒng)和廣播運營商支撐系統(tǒng)同步計費信息，并在接收到成功響應后，更新自身數(shù)據(jù)庫將所述第一標記更新為標示通信運營商支撐系統(tǒng)處理成功的第二標記；如果更新所述第一標記不成功，NAF刪除所述臨時記錄。
2. 如權(quán)利要求l所述的方法，其特征在于，如果更新所述第一標記成功，NAF則向所述 廣播運營商支撐系統(tǒng)發(fā)送同步請求，若接收到廣播運營商支撐系統(tǒng)返回的失敗響應，則刪 除所述臨時記錄，并向所述通信運營商支撐系統(tǒng)和終端返回失敗響應。
3. 如權(quán)利要求2所述的方法，其特征在于，所述向所述廣播運營商支撐系統(tǒng)發(fā)送同步 請求之后，若接收到廣播運營商支撐系統(tǒng)返回的成功響應，則將所述第二標記更新為標示 廣播運營商支撐系統(tǒng)確認成功的第三標記，并向通信運營商支撐系統(tǒng)返回確認消息的成功 響應；在更新所述第二標記成功之后，向輪詢線程發(fā)送消息，將所述操作請求的相關(guān)數(shù)據(jù)更 新到自身數(shù)據(jù)庫中。
4. 如權(quán)利要求3所述的方法，其特征在于，若更新所述第二標記失敗，輪詢線程則將該 臨時記錄寫入臨時文件中，并上報告警板。
5. 如權(quán)利要求1所述的方法，其特征在于，所述操作請求的相關(guān)數(shù)據(jù)包括操作類型、流 水號信息和時間戳中的一項或多項的組合。
6. 如權(quán)利要求5所述的方法，其特征在于，若NAF刪除所述臨時記錄失敗，輪詢線程定 時根據(jù)臨時記錄中的時間戳刪除過期的記錄。
7. 如權(quán)利要求1 6任一權(quán)項所述的方法，其特征在于，所述臨時表設(shè)置在所述NAF的數(shù)據(jù)庫中。
8. —種防止MBBMS業(yè)務系統(tǒng)各網(wǎng)元信息不一致的系統(tǒng)，其特征在于，包括 手機電視業(yè)務管理系統(tǒng)NAF，用于在接收終端發(fā)起的操作請求后，將所述操作請求的相關(guān)數(shù)據(jù)作為臨時記錄插入預設(shè)的臨時表中，向通信運營商支撐系統(tǒng)和廣播運營商支撐系統(tǒng) 同步計費信息，并在接收到成功響應后，更新自身數(shù)據(jù)庫將所述臨時記錄中的第一標記更 新為標示通信運營商支撐系統(tǒng)處理成功的第二標記；如果更新所述第一標記不成功，刪除 所述臨時記錄，并向通信運營商支撐系統(tǒng)和所述終端返回錯誤響應；廣播運營商支撐系統(tǒng)和通信運營商支撐系統(tǒng)，用于接收NAF發(fā)送來的確認請求，并在 驗證所述確認請求后返回成功響應。
9. 如權(quán)利要求8所述的系統(tǒng)，其特征在于，所述手機電視業(yè)務管理系統(tǒng)還用于如果更 新所述第一標記成功，則向所述廣播運營商支撐系統(tǒng)發(fā)送同步請求，若接收到廣播運營商 支撐系統(tǒng)返回的失敗響應，則刪除所述臨時記錄，并向所述通信運營商支撐系統(tǒng)和終端返 回失敗響應。
10. 如權(quán)利要求8所述的系統(tǒng)，其特征在于，所述手機電視業(yè)務管理系統(tǒng)還用于向所述 廣播運營商支撐系統(tǒng)發(fā)送同步請求之后，若接收到廣播運營商支撐系統(tǒng)返回的成功響應，則將所述第二標記更新為標示廣播運營商支撐系統(tǒng)確認成功的第三標記，并向通信運營商 支撐系統(tǒng)返回確認消息的成功響應；向輪詢線程發(fā)送消息，將所述操作請求的相關(guān)數(shù)據(jù)更 新到自身數(shù)據(jù)庫中。
全文摘要
本發(fā)明公開了一種防止MBBMS業(yè)務系統(tǒng)各網(wǎng)元信息不一致的方法和系統(tǒng)，該方法包括當用戶終端向手機電視業(yè)務管理系統(tǒng)發(fā)起操作請求時，手機電視業(yè)務管理系統(tǒng)NAF將所述操作請求的相關(guān)數(shù)據(jù)作為臨時記錄插入預設(shè)的臨時表中，并在該條記錄中添加第一標記；NAF向通信運營商支撐系統(tǒng)和廣播運營商支撐系統(tǒng)同步計費信息，并在接收到成功響應后，更新自身數(shù)據(jù)庫將所述第一標記更新為標示通信運營商支撐系統(tǒng)處理成功的第二標記；如果更新所述第一標記不成功，NAF刪除所述臨時記錄。應用本發(fā)明實施例提供的方法和系統(tǒng)在異常的情況下維持了各網(wǎng)元的用戶信息的統(tǒng)一，防止由于各網(wǎng)元用戶信息不統(tǒng)一導致的計費誤差等問題。
文檔編號H04W4/24GK101730050SQ200910205589
公開日2010年6月9日 申請日期2009年10月30日 優(yōu)先權(quán)日2009年10月30日
發(fā)明者蔣元春 申請人:中興通訊股份有限公司