一種防止mbbms業務系統各網元信息不一致的方法及系統的製作方法
2023-08-02 20:13:46
專利名稱：一種防止mbbms業務系統各網元信息不一致的方法及系統的製作方法
技術領域：
本發明涉及廣播式手機電視技術領域，尤其涉及一種防止MBBMS業務系統各網元 信息不一致的方法及系統。
背景技術：
因為手機電視業務的飛速發展，MBBMS (Mobile Broadcast BusinessManagement System、廣播式手機電視業務管理系統)日漸成為移動的主推規範，其中涉及到了眾多的 網元，包括，手機電視業務管理系統(以下簡稱NAF)，廣播運營商支撐系統(以下描述中以 廣電BOSS為例)，通信運營商支撐系統(以下描述中以中移BOSS)，廣電CAS系統等，用戶 相關的開通、訂購、密鑰請求等操作流程需要依次通過這些網元才可完成最終的流程。
如圖1所示，一個標準的開通或者訂購操作由以下六個步驟組成
步驟101，終端發起業務請求； 用戶在終端界面上發起開通或者訂購的操作，消息通過w即網關發送到手機電視 業務管理系統NAF，由NAF進行受理操作。 步驟102， NAF根據所述業務請求向廣電BOSS發送確認消息； 確認消息由NAF向廣電BOSS發起，確認用戶是否符合開通或者訂購的條件，正常
的話流程繼續，確認消息本身不會產生資料庫的更改操作。 步驟103， NAF將廣電BOSS返回的確認消息同步給中移BOSS ; NAF通過BOSS接口機向中移BOSS請求用戶的開通或者訂購操作，中移BOSS實施
扣費等預操作之後，給BOSS接口機回確認消息，BOSS接口機給中移BOSS回正確響應，中移
BOSS進行事務的提交操作，接口機通知NAF進行下一步處理。 步驟104， NAF保存用戶信息； NAF在資料庫中保存用戶的本次操作信息。 步驟105， NAF將中移BOSS發送的確認信息同步至廣電BOSS ;NAF向廣電BOSS同步本次操作，使廣電BOSS更新用戶信息，廣電BOSS向CAS同
步，CAS更新用戶信息。 步驟106， NAF向終端返回處理狀態； NAF向終端返回的處理狀態是步驟103中中移BOSS的處理結果。
該方案存在以下不足若步驟104和步驟105中數據保存不成功，或用戶消息同步 不成功，則會導致廣電BOSS保存的狀態為不成功，中移BOSS保存的狀態為成功，從而使得 NAF，廣電BOSS, CAS和中移BOSS的用戶信息存在不一致。 上述情況則會導致用戶看到的響應是成功，但是卻無法正常看到訂購節目的問 題。
發明內容
本發明實施例提供一種防止MBBMS業務系統各網元信息不一致的方法及系統，用於克服現有技術中因為網元故障導致各網元數據保存不一致的問題。 —種防止MBBMS業務系統各網元信息不一致的方法，當用戶終端向手機電視業務管理系統發起操作請求時，包括 手機電視業務管理系統NAF將所述操作請求的相關數據作為臨時記錄插入預設的臨時表中，並在該條記錄中添加第一標記； NAF向通信運營商支撐系統和廣播運營商支撐系統同步計費信息，並在接收到成功響應後，更新自身資料庫將所述第一標記更新為標示通信運營商支撐系統處理成功的第二標記； 如果更新所述第一標記不成功，NAF刪除所述臨時記錄。
—種防止MBBMS業務系統各網元信息不一致的系統，包括 手機電視業務管理系統NAF，用於在接收終端發起的操作請求後，將所述操作請求
的相關數據作為臨時記錄插入預設的臨時表中，向通信運營商支撐系統和廣播運營商支撐
系統同步計費信息，並在接收到成功響應後，更新自身資料庫將所述臨時記錄中的第一標
記更新為標示通信運營商支撐系統處理成功的第二標記；如果更新所述第一標記不成功，
刪除所述臨時記錄，並向通信運營商支撐系統和所述終端返回錯誤響應； 廣播運營商支撐系統和通信運營商支撐系統，用於接收NAF發送來的確認請求，
並在驗證所述確認請求後返回成功響應。 應用本發明實施例提供的方法和系統利用已有網元系統的特點將消息同步時的每個處理狀態都進行記錄，如果出現異常則通知用戶終端和各網元，避免各網元的用戶數據出現不一致的現象。
圖1本發明實施例現有技術的流程圖； 圖2本發明實施例中廣電BOSS和中移BOSS都成功確認用戶請求的實現流程圖； 圖3本發明實施例中NAF本身用戶信息的保存失敗時的實現流程圖； 圖4本發明實施例中當廣電BOSS的處理失敗時的實現流程圖； 圖5本發明實施例中實際應用時的實現流程圖； 圖6本發明實施例所提供的系統的結構圖。
具體實施例方式
本發明實施例提供一種防止MBBMS業務系統各網元信息不一致的方法，下面結合附圖對本發明實施例的處理流程做進一步的說明 如圖2所示，本發明實施例中，當用戶進行開通、訂購、密鑰請求等操作流程時，本發明實施例中通信運營商支撐系統和廣播運營商支撐系統分別以廣電BOSS和中移BOSS為例進行說明，該實施例中廣電BOSS和中移BOSS都成功確認所述請求(即各網元均處理正常的流程)，則該的具體流程包括 步驟201，用戶通過手機終端發起開通或者訂購業務的操作時，終端通過w即網關
向NAF伺服器發起請求，NAF服務端對終端進行http digest 4步鑑權認證。 步驟202， NAF在臨時表中插入一條臨時記錄，並在該條記錄中添加第一標記(實現的方式可以是將該條記錄的標記位置為0)，該條記錄用於記錄所述請求的相關數據，該條記錄中包括所述請求的操作類型、流水號、時間戳等信息。 步驟203， NAF向廣電BOSS發起開通確認請求或訂購確認請求，等待廣電BOSS的響應。 步驟204， NAF接收廣電BOSS返回的響應消息，得到用戶可以開通或者訂購的結果； 步驟205，向中移BOSS發起請求，準備同步用戶的開通或者訂購狀態。 步驟206，中移BOSS返迴響應標識已收到請求正在做進一步處理，NAF繼續等待中
移BOSS的確認消息。 步驟207， NAF收到中移BOSS的確認消息，對消息進行解析處理，得到的返回碼為正常值。 步驟208， NAF將所述第一標記更新為標示移用戶支撐系統確認成功的第二標記(即將所述0更新為第二標記2)，標識當前的處理進度。 步驟209， NAF組http包向廣電BOSS發起同步請求，等待廣電BOSS的同步響應。
步驟210， NAF收到廣電BOSS的同步響應數據，分析處理結果為成功；
步驟211， NAF組包向中移BOSS返回確認消息的成功響應，中移BOSS收到成功的響應消息，實施用戶扣費操作，在操作完成後，向NAF返回成功響應。 步驟212，接收到中移B0SS返回的成功響應後，將臨時表記錄中的第二標記更新
為第三標記(即，將標記位2置為1表示最終狀態)，向輪詢線程模塊發送消息，輪詢線程檢
測臨時表中標記為1的記錄，進行實際的開通或訂購資料庫表更新操作。 步驟213，NAF將成功處理的結果反饋給終端，刪除會話信息表。 當網元處理失敗時，本發明方法的具體實現方法包括，網元處理失敗的情況在本
發明實施例中，主要是廣電BOSS的處理失敗和NAF本身用戶信息的保存失敗 如圖3所示，當NAF本身用戶信息的保存失敗時，本發明實施例的具體步驟包括 步驟301，用戶通過手機終端發起開通或者訂購操作之一，終端通過w即網關向
NAF伺服器發起請求，NAF服務端對終端進行http digest 4步鑑權認證。 若鑑權成功，流程繼續往下，若鑑權失敗，NAF返回給終端錯誤消息，此時整個流程
結束，不會產生問題。 步驟302， NAF在臨時表中插入一條臨時記錄，標識用戶的此次操作類型、流水號等信息，置該條記錄的標記為0，同時加上時間戳。 步驟303， NAF向廣電BOSS發起開通確認請求或訂購確認請求，等待廣電BOSS的響應。 步驟304，接收廣電B0SS的響應消息，得到用戶可以開通或者訂購的結果，若確認消息返回失敗，那麼NAF直接刪除該臨時表記錄，返回給終端錯誤響應，整個流程結束。
步驟305，若確認消息正常，NAF向中移BOSS發起請求，準備同步用戶的開通或者訂購狀態。 步驟306，中移BOSS返迴響應消息標識已收到請求正在做進一步處理，NAF繼續等待中移BOSS的確認消息，若NAF收到的中移BOSS消息超時或確認消息失敗，那麼NAF直接刪除臨時表中的記錄，返回給終端錯誤響應，整個流程結束，若中移BOSS的確認消息結果
6為成功，則轉入步驟307。 步驟307， NAF將插入臨時表中對應記錄的標記位更改為2，標識當前的處理進度，若更新所述標記位失敗，則NAF向中移BOSS返回確認消息的失敗響應，同時將對應的臨時表的記錄刪除，返回給終端錯誤響應，整個流程結束，各網元的記錄都未發生改變；
若是因為資料庫異常導致刪除也失敗，那麼輪詢線程會定時根據臨時表記錄中的時間戳刪除過期的數據。 如圖4所示，當廣電BOSS的處理失敗時，本發明實施例的具體步驟包括 步驟401，用戶通過手機終端發起開通或者訂購操作之一，終端通過w即網關向
NAF伺服器發起請求，NAF服務端對終端進行http digest 4步鑑權認證。 若鑑權成功，流程繼續往下，若鑑權失敗，NAF返回給終端錯誤消息，此時整個流程
結束，不會產生問題。 步驟402， NAF在臨時表中插入一條記錄，標識用戶的此次操作類型、流水號等信息，置該條記錄的標記為0，同時加上時間戳。 步驟403， NAF向廣電BOSS發起開通確認請求或訂購確認請求，等待廣電BOSS的響應。 步驟404， NAF收到廣電BOSS的響應消息，得到用戶可以開通或者訂購的結果，若確認消息返回失敗，那麼NAF直接刪除該臨時表記錄，返回給終端錯誤響應，整個流程結束。 步驟405，若確認消息正常，NAF向中移BOSS發起請求，準備同步用戶的開通或者訂購狀態。 步驟406，中移BOSS返迴響應消息標識已收到請求正在做進一步處理，NAF繼續等待中移BOSS的確認消息，若NAF收到的中移BOSS消息超時或確認消息失敗，那麼NAF直接刪除臨時表中的記錄，返回給終端錯誤響應，整個流程結束，若中移BOSS的確認消息結果為成功，則轉入步驟407。 步驟407，NAF將插入臨時表中對應記錄的標記位更改為2，標識當前的處理進度。
步驟408， NAF組http包向廣電BOSS發起同步請求，等待廣電BOSS的同步響應。
步驟409，若廣電的同步消息返回失敗的響應，那麼NAF將臨時表中對應記錄的標記修改為0，同時刪除該條記錄組包向中移BOSS返回確認消息的失敗響應，中移BOSS自己處理回滾流程，NAF向終端返回失敗響應，整個流程結束，各網元的用戶狀態未發生變化。
若是因為資料庫異常導致刪除也失敗，那麼輪詢線程會定時根據臨時表記錄中的時間戳刪除過期的數據。 步驟410，若廣電B0SS的同步響應消息為正常，那麼NAF將臨時表中對應的記錄的標記置為1，同時組包向中移BOSS返回確認消息的成功響應，中移BOSS實施扣費操作，NAF向輪詢線程發送消息，使本次用戶的請求更新到實際的資料庫中；若臨時表中對應記錄的標記置1失敗，NAF向輪詢模塊發送標記失敗的流水號信息，輪詢模塊將該數據寫入文件中去以做記錄，隨後輪詢模塊嘗試重新更新資料庫中的標記，直到成功為止；同時將該異常上報至告警板，及時通知操作人員檢查是否資料庫出現故障，若資料庫出現故障，那麼在資料庫恢復後輪詢模塊會根據文件中記錄的流水號繼續進行嘗試直到更新成功。
步驟411，若無其他異常，NAF向終端反饋處理結果；輪詢線程會定期檢查臨時表
7中的記錄，對於過期數據實施刪除操作。 在實際的應用環境中，在廣電BOSS、中移BOSS以及NAF出現問題時任一網元出現問題時，本發明實施例具體包括如圖5所示的處理步驟。 如圖6所示，本發明實施例還提供一種防止MBBMS業務系統各網元信息不一致的系統，包括手機電視業務管理系統(NAF)601、廣播運營商支撐系統602和通信運營商支撐系統603 : 手機電視業務管理系統(NAF)601，用於在接收終端發起的操作請求後，將所述操作請求的相關數據作為臨時記錄插入預設的臨時表中，向通信運營商支撐系統603和廣播運營商支撐系統602同步計費信息，並在接收到成功響應後，更新自身資料庫將所述臨時記錄中的第一標記更新為標示通信運營商支撐系統603處理成功的第二標記；如果更新所述第一標記不成功，刪除所述臨時記錄，並向通信運營商支撐系統603和所述終端返回錯誤響應； 廣播運營商支撐系統602，用於接收NAF發送來的確認請求，並在驗證所述確認請求後返回成功響應； 通信運營商支撐系統603，用於接收NAF發送來的確認請求，並在驗證所述確認請求後返回成功響應。 所述手機電視業務管理系統601還用於如果更新所述第二標記成功，則向所述廣播運營商支撐系統602發送同步請求，若接收到廣播運營商支撐系統602返回的失敗響應，則刪除所述臨時記錄，並向所述通信運營商支撐系統603和終端返回失敗響應。
進一步，所述手機電視業務管理系統601還用於向所述廣播運營商支撐系統602發送同步請求之後，若接收到廣播運營商支撐系統602返回的成功響應，則將所述第二標記更新為標示廣播運營商支撐系統602確認成功的第三標記，並向通信運營商支撐系統603返回確認消息的成功響應；向輪詢線程發送消息，將所述操作請求的相關數據更新到自身資料庫中。 採用儘可能少的回滾機制和利用已有網元系統的特點處理各網元消息同步時出現的異常，避免各網元的用戶數據出現不一致的現象，同時給予終端用戶比較直觀的提示，另外該方法對於MBBMS平臺的外部網元不需要修改，主要集中在NAF的處理流程上做改進。
應用本發明實施例提供的方法和系統可以應用儘可能少的回滾機制和利用已有網元系統的特點處理消息同步時出現的異常，避免各網元的用戶數據出現不一致的現象。同時給予終端用戶比較直觀的提示，另外該方法對於MBBMS平臺的外部網元不需要修改，主要集中在NAF的處理流程上做改進。 本發明所述的方法並不限於具體實施方式
中所述的實施例，本領域技術人員根據本發明的技術方案得出其它的實施方式，同樣屬於本發明的技術創新範圍。顯然，本領域的技術人員可以對本發明進行各種改動和變型而不脫離本發明的精神和範圍。這樣，倘若本發明的這些修改和變型屬於本發明權利要求及其等同技術的範圍之內，則本發明也意圖包含這些改動和變型在內。
權利要求
一種防止MBBMS業務系統各網元信息不一致的方法，當用戶終端向手機電視業務管理系統發起操作請求時，其特徵在於，包括手機電視業務管理系統NAF將所述操作請求的相關數據作為臨時記錄插入預設的臨時表中，並在該條記錄中添加第一標記；NAF向通信運營商支撐系統和廣播運營商支撐系統同步計費信息，並在接收到成功響應後，更新自身資料庫將所述第一標記更新為標示通信運營商支撐系統處理成功的第二標記；如果更新所述第一標記不成功，NAF刪除所述臨時記錄。
2. 如權利要求l所述的方法，其特徵在於，如果更新所述第一標記成功，NAF則向所述 廣播運營商支撐系統發送同步請求，若接收到廣播運營商支撐系統返回的失敗響應，則刪 除所述臨時記錄，並向所述通信運營商支撐系統和終端返回失敗響應。
3. 如權利要求2所述的方法，其特徵在於，所述向所述廣播運營商支撐系統發送同步 請求之後，若接收到廣播運營商支撐系統返回的成功響應，則將所述第二標記更新為標示 廣播運營商支撐系統確認成功的第三標記，並向通信運營商支撐系統返回確認消息的成功 響應；在更新所述第二標記成功之後，向輪詢線程發送消息，將所述操作請求的相關數據更 新到自身資料庫中。
4. 如權利要求3所述的方法，其特徵在於，若更新所述第二標記失敗，輪詢線程則將該 臨時記錄寫入臨時文件中，並上報告警板。
5. 如權利要求1所述的方法，其特徵在於，所述操作請求的相關數據包括操作類型、流 水號信息和時間戳中的一項或多項的組合。
6. 如權利要求5所述的方法，其特徵在於，若NAF刪除所述臨時記錄失敗，輪詢線程定 時根據臨時記錄中的時間戳刪除過期的記錄。
7. 如權利要求1 6任一權項所述的方法，其特徵在於，所述臨時表設置在所述NAF的資料庫中。
8. —種防止MBBMS業務系統各網元信息不一致的系統，其特徵在於，包括 手機電視業務管理系統NAF，用於在接收終端發起的操作請求後，將所述操作請求的相關數據作為臨時記錄插入預設的臨時表中，向通信運營商支撐系統和廣播運營商支撐系統 同步計費信息，並在接收到成功響應後，更新自身資料庫將所述臨時記錄中的第一標記更 新為標示通信運營商支撐系統處理成功的第二標記；如果更新所述第一標記不成功，刪除 所述臨時記錄，並向通信運營商支撐系統和所述終端返回錯誤響應；廣播運營商支撐系統和通信運營商支撐系統，用於接收NAF發送來的確認請求，並在 驗證所述確認請求後返回成功響應。
9. 如權利要求8所述的系統，其特徵在於，所述手機電視業務管理系統還用於如果更 新所述第一標記成功，則向所述廣播運營商支撐系統發送同步請求，若接收到廣播運營商 支撐系統返回的失敗響應，則刪除所述臨時記錄，並向所述通信運營商支撐系統和終端返 回失敗響應。
10. 如權利要求8所述的系統，其特徵在於，所述手機電視業務管理系統還用於向所述 廣播運營商支撐系統發送同步請求之後，若接收到廣播運營商支撐系統返回的成功響應，則將所述第二標記更新為標示廣播運營商支撐系統確認成功的第三標記，並向通信運營商 支撐系統返回確認消息的成功響應；向輪詢線程發送消息，將所述操作請求的相關數據更 新到自身資料庫中。
全文摘要
本發明公開了一種防止MBBMS業務系統各網元信息不一致的方法和系統，該方法包括當用戶終端向手機電視業務管理系統發起操作請求時，手機電視業務管理系統NAF將所述操作請求的相關數據作為臨時記錄插入預設的臨時表中，並在該條記錄中添加第一標記；NAF向通信運營商支撐系統和廣播運營商支撐系統同步計費信息，並在接收到成功響應後，更新自身資料庫將所述第一標記更新為標示通信運營商支撐系統處理成功的第二標記；如果更新所述第一標記不成功，NAF刪除所述臨時記錄。應用本發明實施例提供的方法和系統在異常的情況下維持了各網元的用戶信息的統一，防止由於各網元用戶信息不統一導致的計費誤差等問題。
文檔編號H04W4/24GK101730050SQ200910205589
公開日2010年6月9日 申請日期2009年10月30日 優先權日2009年10月30日
發明者蔣元春 申請人:中興通訊股份有限公司