专利名称：一种防止mbbms业务系统各网元信息不一致的方法及系统的利记博彩app
技术领域：
本发明涉及广播式手机电视技术领域，尤其涉及一种防止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日
发明者蒋元春 申请人:中兴通讯股份有限公司