实现多业务系统间订购关系一致的方法及系统 【技术领域】
本发明涉及通讯技术领域，尤其涉及一种实现多业务系统间订购关系一致的方法及系统。
背景技术
目前，增值业务管理平台中的业务系统一般根据用户的具体需求维护一个订购关系，当用户订购或者退订某些业务时，会引起业务系统中订购关系的变化，相应地，业务系统会根据订购关系的变化对业务进行管理。例如广播式手机电视业务管理系统需要根据订购关系的变化，来判断频道、节目或者套餐是否订购，以及如何对业务进行计费等。
然而，增值业务管理平台基于订购关系实现业务管理的过程中，考虑到对订购关系的管理、业务使用以及用户计费等多个环节，有时会要求在不同的业务系统中分别保存订购关系。另外，在保存订购关系之前，有时还需要确认用户是否停机、欠费以及业务是否可用等多种状况，确认之后，可首先一个业务系统中保存订购关系，再向其他业务系统同步该订购关系，这种同步机制需要在多业务系统间进行很多次消息交互，导致处理过程时间长，效率低下；而繁杂的处理流程极易导致订购关系在各个业务系统间的不一致，从而引起用于订购成功却计费失败，计费后却不能使用等异常问题，影响了运营商的服务质量。
【发明内容】
本发明所要解决的技术问题是，提供一种实现多业务系统间订购关系一致的方法及系统，提高了业务处理效率、有效避免了多业务系统之间由于订购关系不一致而导致的异常状况。
本发明解决其技术问题所采用的技术方案是：提供了一种实现多业务系统间订购关系一致的方法，包括以下步骤：第一业务系统接收终端设备的订购请求消息，所述订购请求消息包含用于生成订购关系的参数；
第一业务系统向第二业务系统发送所述订购请求消息，并接收第二业务系统利用所述参数成功保存订购关系后返回的成功保存响应；
第一业务系统保存所述订购关系。
进一步地，还包括第一业务系统再向至少一个第三业务系统发送所述订购请求消息的步骤。
本发明所述的第一业务系统为订购受理系统，所述第二业务系统为管理授权系统，所述第三业务系统为鉴权计费系统。
第一业务系统接收终端设备的订购请求消息后，还包括对所述订购请求消息进行校验的步骤，如果校验成功，则向第二业务系统发送所述订购请求消息，否则，向所述终端设备返回订购失败响应。
第一业务系统向第二业务系统发送所述订购请求消息后，还包括以下步骤：第一业务系统接收第二业务系统失败保存订购关系后返回的失败保存响应，然后向所述终端设备返回订购失败响应。
第一业务系统再向第三业务系统发送所述订购请求消息后，还包括以下步骤：第一业务系统接收第三业务系统利用所述参数成功保存订购关系后返回的成功保存响应或者失败保存订购关系后返回的失败保存响应，并向所述终端设备返回相应的订购成功响应或订购失败响应。
另外，第一业务系统接收第三业务系统返回的失败保存响应后，还包括回退原订购关系，以及记录异常信息的步骤。
还包括核准步骤：即第一业务系统向第二业务系统发送订购关系核准请求消息，所述订购关系核准请求消息携带所述异常信息；
第一业务系统接收第二业务系统根据所述异常信息更新本地订购关系后返回的核准响应消息，所述核准响应消息携带第二业务系统对于所述订购关系的处理结果；
第一业务系统根据所述处理结果对所述异常信息进行相应地处理。
本发明还保护了一种实现多业务系统间订购关系一致的系统，包括终端设备、第一业务系统和第二业务系统，其中，第一业务系统包括订购请求接收模块、保存请求模块、保存响应模块；
其中，终端设备用于向所述订购请求模块发送订购请求消息，所述订购请求消息包含用于生成订购关系的参数；
订购请求模块用于接收所述订购请求消息；
保存请求模块用于向第二业务系统发送所述订购请求消息；
保存响应模块用于接收第二业务系统利用所述参数成功保存订购关系后返回的成功保存响应，并用于保存所述订购关系。
系统还包括至少一个第三业务系统；保存响应模块还用于在保存所述订购关系后，控制所述保存请求模块再向至少一个第三业务系统发送所述订购请求消息。
第一业务系统还包括校验模块和订购反馈模块；校验模块用于对所述订购请求消息进行校验，如果校验成功，则控制所述保存请求模块向第二业务系统发送所述订购请求消息，否则通知订购反馈模块；订购反馈模块用于根据所述校验模块的通知向所述终端设备返回订购失败响应。
第一业务系统还包括异常处理模块；所述保存响应模块还用于接收第三业务系统失败保存订购关系后返回的失败保存响应，并通知所述异常处理模块；异常处理模块用于根据所述失败保存响应回退原订购关系并记录异常信息。
进一步地，第一业务系统还包括订购关系核准模块；所述订购关系核准模块用于向第二业务系统发送订购关系核准请求消息，所述订购关系核准请求消息携带所述异常信息；还用于接收第二业务系统根据所述异常信息更新本地订购关系后返回的核准响应消息，所述核准响应消息携带第二业务系统对于所述订购关系的处理结果；还用于根据所述处理结果对所述异常信息进行相应地处理。
本发明还保护了一种实现多业务系统间订购关系一致的第一业务系统，包括订购请求接收模块、保存请求模块、保存响应模块；
订购请求模块用于接收终端设备的订购请求消息，所述订购请求消息包含用于生成订购关系的参数；
保存请求模块用于向第二业务系统发送所述订购请求消息；
保存响应模块用于接收第二业务系统利用所述参数成功保存订购关系后返回的成功保存响应，并用于保存所述订购关系。
本发明的有益效果是，能够简化增值业务管理平台中多业务系统间订购关系复杂繁琐的保存流程，保证多个业务系统间订购关系的完全一致，显著提高了处理效率，避免了多业务系统之间由于订购关系不一致而导致的异常状况。
通过校验机制和核准机制，本发明进一步对订购关系进行合法性校验，确保为用户提供准确、完善的增值服务。
【附图说明】
图1为本发明的实现多业务系统间订购关系一致的方法第一种具体实施方式流程图；
图2为本发明的实现多业务系统间订购关系一致的方法第二种具体实施方式流程图；
图3为本发明的第一业务系统进行订购关系核准的信息交互示意图；
图4为本发明的实现多业务系统间订购关系一致的系统框图。
【具体实施方式】
以下结合附图对本发明的具体实施方式进行详细说明。
如图1所示，本实施方式的实现多业务系统间订购关系一致的方法包括以下步骤：
步骤S100：增值业务管理平台中的第一业务系统接收终端设备(例如手机、笔记本电脑、掌上电脑、数码相框等)的订购请求消息，该订购请求消息包含用于生成订购关系的参数。该步骤中，为了提高业务处理的准确度，第一业务系统可首先对业务请求消息进行校验，例如校验其合法性，以及可否在本系统保存订购关系等。
订购关系一般包含了用户、业务(例如套餐编码、频道信息等)以及订购状态(例如订购渠道、是否续订、位置信息等)参数之间的对应关系，因此，订购关系的生成依赖于用户所提供的这些必要参数。
步骤S101：第一业务系统向第二业务系统发送订购请求消息。
步骤S102：第二业务系统利用以上参数确认并成功保存订购关系，并向第一业务系统返回成功保存响应，保证了订购关系在本系统与第一业务系统的一致性。
步骤S103：第一业务系统接收成功保存响应。
步骤S104：第一业务系统利用以上参数保存订购关系，接着第一业务系统还可向终端设备反馈成功订购响应供用户查看。
步骤S105：以上步骤实现了用户通过终端设备向增值业务管理平台订购业务时两个业务系统之间订购关系地一致性。进一步地，第一业务系统还可再向一个或者多个第三业务系统发送订购请求消息，例如可同时或者依次向这些第三业务系统发送订购请求消息，使整个增值业务管理平台中的多个业务系统都保持一致的订购关系。
本实施方式提供了增值业务管理平台中，多个业务系统间保持订购关系协同、一致的处理机制。对于不同的增值业务管理平台，业务系统的数量、功能以及运行模式并不相同，而本发明提供的技术方案可根据具体需要应用适用于多种增值业务管理平台。
例如针对广播式手机电视业务管理系统，第一业务系统可为订购受理系统，用于提供业务订购，查询订购、业务退订等服务；第二业务系统可为管理授权系统，用于对业务进行管理和授权，例如控制视频播放、管理频点信息、管理密钥信息等；第三业务系统为鉴权计费系统，用于对用户进行鉴权和计费等，另外，还可根据业务需要增设多个第三业务系统，本实施方式的方法也可扩展至这些增设的第三业务系统。
另外，在增值业务管理平台中，每个业务系统还可能进一步包括按照功能区分的子业务系统，例如鉴权计费系统中还可能包含鉴权子系统、计费子系统、查询子系统等，本实施方式的方法也可扩展至这些增设的子业务系统。例如鉴权子系统相当于本实施方式的第一业务系统、计费子系统当于本实施方式的第二业务系统、查询子系统当于本实施方式的第二业务系统等。
请参见图2，本实施方式提供了一种提高准确度的优选实施方式，在基本应用的基础上，还包含了对订购请求消息进行校验的步骤，并考虑了业务系统失败保存订购关系的状况。本实施方式包括以下步骤：
步骤S200：第一业务系统接收终端设备的订购请求消息。
步骤S201：第一业务系统对订购请求进行校验处理，即确认订购请求消息中包含的各种参数是否合法，和能否在本系统保存订购关系等，如果订购请求消息本身消息错误，或者增值业务管理平台无法提供用户要求的业务，则校验失败，否则通过校验。
步骤S202：判断是否通过校验，即是否可以在本地保存订购关系，是，则进入步骤S203，否则进入步骤212。
步骤S203：通过校验，则第一业务系统向第二业务系统发送订购请求消息，该步骤中，消息发送方式根据业务系统之间的接口类型而定。
步骤S204：第二业务系统接收订购请求消息后，根据所述的参数确认并保存订购关系，保证订购关系的一致性，如果系统内部还包含多个子业务系统或者处理单元，则利用以上参数在其中一一确认和保存订购关系，接着向第一业务系统反馈结果；根据不同的处理结果，可能返回成功保存响应或失败保存响应。第一业务系统接收第二业务系统的成功保存响应或失败保存响应。
步骤S205：判断是否成功保存响应，是，则进入步骤S206，否则进入步骤S212。
步骤S206：第一业务系统在本系统中保存订购关系。
步骤S207：第一业务系统再向一个第三业务系统发送订购请求消息。
步骤S208：与步骤S204类似，第三业务系统接收订购请求消息后，根据所述的参数确认并保存订购关系，接着向第一业务系统反馈结果。例如可先确认用户资费状况，再根据不同的处理结果，可能返回成功保存响应或失败保存响应。第一业务系统接收第三业务系统的成功保存响应或失败保存响应。
步骤S209：判断是否成功保存响应，是则进入步骤S210，否则进入步骤S212。
步骤S210：第一业务系统向终端设备返回订购成功响应，表明此次订购请求处理成功。
步骤S211：第一业务系统回退原订购关系，即将订购关系恢复至本次订购请求处理之前的状态，并记录异常信息；接着可返回步骤S207依次向下一个第三业务系统发送订购请求消息。
步骤S212：向终端设备返回订购失败响应。
步骤S213：结束流程。
进一步地，如图3所示，第二中实施方式还可进一步包括对订购关系进行核准的流程，即包括以下步骤：
步骤S300：第一业务系统向第二业务系统发送订购关系核准请求消息，其中携带记录的异常信息，本步骤中，可根据需要采用批量发送的形式，或者定时发送的机制，例如每隔一段固定的时间，第一业务系统向第二业务系统发送针对多个异常订购关系的订购关系核准请求消息供其核准。
步骤S301：第二业务系统接收核准请求消息后，利用异常信息校验更新本地订购关系，并向第一业务系统返回核准响应消息，其中携带第二业务系统对于各个订购关系的处理结果；第一业务系统收到核准响应消息后，根据处理结果对异常信息进行相应地处理，如果第二业务系统已经更新成功订购关系表明已经实现了订购关系的一致性，则删除异常信息，否则继续保留异常信息。
如图4所示，本发明的实现多业务系统间订购关系一致的系统包括终端设备10、第一业务系统20和第二业务系统30，还可进一步包括一个或多个第三业务系统40，例如第三业务系统1......第三业务系统n。
进一步地，第一业务系统20包括订购请求接收模块21、保存请求模块23和保存响应模块24等，为了进一步优化服务，还可增加校验机制、响应机制、核准机制等，即还可包含校验模块22、订购反馈模块25、异常处理模块26、订购关系核准模块27等。
其中，终端设备10用于向订购请求模块21发送订购请求消息，如前所述，该订购请求消息包含用于生成订购关系的参数。
订购请求模块21用于接收订购请求消息。
校验模块22用于对订购请求消息进行校验，例如确认订购请求消息中包含的各种参数是否合法，和能否在本系统保存订购关系等，如果校验成功，则控制保存请求模块23向第二业务系统30发送订购请求消息，否则通知订购反馈模块25。
保存请求模块23用于向第二业务系统30发送订购请求消息。
保存响应模块24用于接收第二业务系统30利用参数成功保存订购关系后返回的成功保存响应，接着在第一业务系统10中也保存订购关系。
如果存在第三业务系统40，保存响应模块24还用于在保存订购关系后，控制保存请求模块23再向至少一个第三业务系统40发送订购请求消息。
当第三业务系统40成功保存订购关系时，保存响应模块24接收到第三业务系统40返回的成功保存响应，并通知订购反馈模块25；当第三业务失败保存订购关系时，保存响应模块24接收到第三业务系统40返回的失败保存响应，并通知异常处理模块26。
订购反馈模块25用于在校验模块22校验失败时，根据校验模块22的通知向终端设备10返回订购失败响应供用户查看；当然，如果第一业务系统20成功保存订购关系，或者当保存响应模块24接收到至少一个第三业务系统10返回的成功保存响应或失败保存响应后，订购反馈模块25还可向终端设备10返回相应的订购成功响应或订购失败响应供用户查看。
异常处理模块26用于根据失败保存响应回退原订购关系，并记录异常信息。
订购关系核准模块27用于向第二业务系统30发送订购关系核准请求消息，该订购关系核准请求消息携带异常信息，可采用定时机制和批量处理机制；还用于接收第二业务系统30根据异常信息更新本地订购关系后返回的核准响应消息，该核准响应消息携带第二业务系统30对于订购关系的处理结果；还用于根据处理结果对异常信息进行相应地处理，例如删除异常信息或者保留异常信息。
本发明能够简化增值业务管理平台中订购关系复杂繁琐的保存流程，保证多个业务系统间订购关系的完全一致，显著提高了处理效率，从而为用户提供更加优质、完善的增值服务。
以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。