CN101953188B - 一种业务管理平台下处理多渠道请求订购的方法和装置 - Google Patents

Abstract

本发明公开了一种业务管理平台下处理多渠道请求订购的方法和装置，所述业务管理平台包括消息请求处理模块和数据库信息交互模块，其方法包括以下步骤：消息请求处理模块根据请求订购渠道提取请求信息，并组成统一的请求格式，向数据库信息交互模块请求保存或查询数据；以及数据库信息交互模块根据消息处理模块的请求，判断该请求的合理性，并向消息请求处理模块返回请求的结果。由于明确了消息请求处理模块和数据库信息交互模块在流程上的分工，保证了流程上的逻辑处理与数据处理过程相分离，从而简化了业务管理平台业务处理流程，缩短了处理时间，提高了处理效率，尤其是在请求的数据量较大时候，减少了出现业务管理平台系统处理上新瓶颈的可能。

Description

一种业务管理平台下处理多渠道请求订购的方法和装置

技术领域

本发明涉及移动通讯的数据服务流程领域，尤其涉及一种业务管理平台下处理多渠道请求订购方法和装置。

背景技术

目前，多渠道请求订购和查询订购关系即请求内容是业务管理平台系统中普遍需要处理的服务。当业务管理平台系统在接收到每个渠道的订购请求后，根据所请求内容和渠道，通常都要采用各自相对应的处理流程进行处理，甚至连请求渠道的数目变化时都要对业务处理流程进行很大改动。

而且，在对请求数据保存后进行处理的过程中，例如业务密钥下发控制、用户短信通知和业务数据同步等，此类跟请求渠道的相关操作处理有所不同；同时，由于对请求用户信息和业务信息的合格性还要作审查与判断，对业务逻辑和业务数据的同时兼顾处理，就很容易导致业务处理流程的过于复杂化，以及处理的时间长、效率低，特别是在请求的数据量较大时候，极易出现业务管理平台系统处理上的瓶颈。

因此，现有技术还有待于改善和发展。

发明内容

本发明要解决的问题是，提供一种业务管理平台下处理多渠道请求订购的方法和装置，以简化业务管理平台处理流程，缩短处理时间，提高处理效率，尤其是遇到请求的数据量较大时候，可减少出现业务管理平台系统处理上新的瓶颈。

本发明的技术方案如下：

一种业务管理平台下处理多渠道请求订购的方法，其中所述业务管理平台包括消息请求处理模块和数据库信息交互模块，所述的方法包括：

A、所述消息请求处理模块根据请求订购渠道提取请求信息，并组成统一的请求格式，向所述数据库信息交互模块请求保存或查询数据；以及

B、所述数据库信息交互模块根据所述消息请求处理模块的请求，判断所述请求的合理性，并向所述消息请求处理模块返回所述请求的结果。

所述的方法中，所述步骤A可包括：

A1、接收业务请求消息，提取有效的请求内容和请求渠道信息；

A2、根据具体业务的处理需要，对不同的请求渠道采用相应的处理流程；以及

A3、向所述数据库信息交互模块发送统一的数据处理请求，请求消息中包含有效的请求内容和渠道信息。

所述的方法中，所述步骤A1中的所述业务请求消息可来自于终端、门户或短信网关渠道。

所述的方法中，所述步骤A2中具体业务的处理需要可包括查询请求内容、拆分业务或与所述业务管理平台之间相互进行认证。

所述的方法中，所述步骤B可包括：

B1、所述数据库信息交互模块区分所述消息请求处理模块请求的类型；

B2、对于同一请求类型，统一判断请求的业务信息是否合理并在合理时调用结构化查询语言SQL语句请求数据库的响应；以及

B3、得到所述数据库的响应后，对所述消息请求处理模块返回数据处理结果，并在响应消息中携带原始请求的渠道。

所述的方法中，所述步骤B2还可包括：

B21、若请求的业务信息不合理，则直接返回失败的响应，并结束处理流程。

所述的方法中，所述步骤B之后还可包括：

C、所述消息请求处理模块根据返回的所述请求的结果中的渠道信息，调用相应的处理流程，判断业务的同步目的地并向原始请求方发送响应消息。

所述的方法，其中，所述步骤C可包括：

C1、所述消息请求处理模块解析接收到的所述数据库信息交互模块的响应消息；

C2、如果所述响应消息为成功的响应消息，则根据所述响应消息中的渠道信息进行数据保存后的处理；向原始请求方回复响应消息，其中所述处理包括判断业务的同步目的地；如果所述响应消息为失败的响应消息，则直接回复原请求方失败的响应消息；以及

C3、所述消息请求处理模块向原始请求方回复响应消息后，处理结束。

所述的方法中，可根据请求订购的原始渠道和/或请求订购业务的归属来判断所述业务的同步目的地。

一种业务管理平台下处理多渠道请求订购的装置，所述业务管理平台包括相互分离的消息请求处理模块和数据库信息交互模块，其中，

所述消息请求处理模块设置成根据请求订购渠道提取请求信息，并组成统一的请求格式，向所述数据库信息交互模块请求保存或查询数据；以及

所述数据库信息交互模块设置成根据所述消息请求处理模块的请求，判断所述请求的合理性，并向所述消息请求处理模块返回所述请求的结果。

所述的装置中，所述消息请求处理模块还可设置成根据所述数据库信息交互模块返回的所述请求的结果中的渠道信息，调用相应的处理流程，判断业务的同步目的地并向原始请求方发送响应消息。

所述的装置中，所述消息请求处理模块还可设置成根据请求订购的原始渠道和/或请求订购业务的归属来判断业务的同步目的地。

本发明所提供的一种业务管理平台下处理多渠道订购的方法和装置，由于明确了消息请求处理模块和数据库信息交互模块在流程上的分工，保证了流程上的逻辑处理与数据处理过程相分离，使得处理过程条理清晰，从而简化了业务管理平台业务处理流程，缩短了处理时间，提高了处理效率，尤其是在请求的数据量较大时候，减少了出现业务管理平台系统处理上新瓶颈的可能。

附图概述

图1是本发明业务处理流程示意图；

图2是本发明消息请求处理模块的处理流程示意图；

图3是本发明数据库信息交互模块的处理流程示意图；

图4为本发明消息处理数据响应流程示意图；以及

图5是本发明业务处理系统模块结构示意图。

本发明的较佳实施方式

以下结合所示附图，对本发明业务管理平台下处理多渠道请求订购方法和装置的具体实施方式加以详细说明。

本发明业务管理平台下处理多渠道请求订购的方法和装置，主要核心点在于，明确消息请求处理模块和数据库信息交互模块在流程上的分工，分离逻辑处理与数据处理过程，简化多渠道请求订购业务，至于多渠道请求订购以及业务管理平台等技术为现有技术所熟知，在此不再赘述。

本发明具体实施方式的业务管理平台下处理多渠道请求业务如移动终端、短信或门户等请求业务订购关系的方法，其业务管理平台系统主要包括两个模块：消息请求处理模块510和数据库信息交互模块520；如图5所示，其中，所述消息请求处理模块510用于处理来自移动终端、短信和门户等各种渠道的请求，根据请求订购渠道采取相应的处理流程以提取请求信息，并组成统一的请求格式，向数据库信息交互模块520请求保存或查询数据；而所述数据库信息交互模块520则用于根据消息请求处理模块510的请求，判断该请求的合理性，并向所述消息请求处理模块510返回请求的结果。

本发明是基于一种对请求的归并，以及将逻辑处理与数据处理相分离的思路，来处理从多渠道向业务管理平台系统发起的订购和查询请求。

本发明的业务处理流程如图1所示，其中具体实现步骤如下：

步骤S110、数据库信息交互模块判断请求的类型，并根据请求的类型对请求业务数据的合格性进行审查与判断，并向数据库查询或保存数据内容；

步骤S120、数据库信息交互模块对消息请求处理模块返回数据处理结果，其中响应消息中包含必要的请求结果和渠道信息；

步骤S130、消息请求处理模块根据返回数据处理结果中的渠道信息，调用相应的处理流程，向原始请求方发送响应消息；

需要说明的是，消息请求处理模块接收来自于终端、门户或短信网关等渠道的业务请求消息，提取用户信息、业务信息和请求渠道等有效信息，根据不同的请求渠道调用相应的处理流程，并向数据库信息交互模块发送数据请求，其中包含必要的请求内容和请求渠道信息。

而在接收处理多渠道订购请求的时候，把对请求的逻辑处理流程和数据处理流程分开，将复杂的业务处理流程划分为两个相对简单的处理流程；较好的是，当订购或查询渠道的数目发生变化时，也不用对数据库信息交互模块进行修改，仅增加或删除消息请求处理模块的处理流程；而只有当数据库的表结构发生变化时，才需要对数据库信息交互模块进行修改，进一步简化了业务处理流程。

首先，说明本发明的消息请求处理模块处理流程，如图2所示，在实施过程中主要包括以下步骤：

步骤S210、消息请求处理模块接收到终端、门户或短信网关的业务请求消息；

步骤S220、提取有效的请求内容和请求渠道信息；

步骤S230、根据具体业务的处理需要，将不同的请求渠道采用或调用相应不同的处理流程；

例如，在手机电视业务中，如果是来自终端的请求，终端和平台之间要进行digest等相互认证的过程；

又如，如果是来自短信的请求，要先进行查询请求短信内容对应的业务；

再如，如果终端或门户的请求中包含对多个业务的订购，则拆分成多个单业务的请求。

步骤S240、将请求内容与渠道信息拼装成公共的请求结构，向数据库信息交互模块发送统一的数据处理请求，请求消息中包含有效的请求内容和渠道信息。

其次，再说明本发明的数据库信息交互模块处理流程，如图3所示，在实施过程中主要包括以下步骤：

步骤S310、数据库信息交互模块接收到消息请求处理模块的请求后，区分请求的类型；

例如，在手机电视业务中，需要检查请求的用户状态、业务状态和用户对此次请求业务的订购关系状态都是否正常。

步骤S320、判断请求的业务名称如订购、查询或其他等必要信息是否合理，审核请求数据是否合理；

步骤S330、如果是合理的请求，则根据请求类型和内容组成SQL语句，选择合适的SQL语句请求数据库的响应或操作，进入步骤S350；

步骤S340、如果是不合理的请求，则直接返回失败的响应消息，并处理结束；

步骤S350、等待数据库返回结果；得到数据库的返回后，对消息请求处理模块返回数据处理结果，并在响应消息中携带原始请求的渠道，处理结束。

最后，再说明一下本发明的消息处理数据响应的流程，如图4所示，其中具体实现步骤如下：

步骤S410、消息请求处理模块解析接收到的数据库信息交互模块的响应消息；

步骤S420、判断请求结果，如果为成功的响应消息，则进入步骤S430，如果为失败的响应消息，则进入步骤S440；

步骤S430、根据响应消息中的原始请求渠道信息，进行数据保存后的处理流程，包括判断该业务的同步目的地等；

步骤S440、直接回复请求方失败的响应消息给原始请求端；

步骤S450、向原始请求方回复响应消息后，处理结束。

例如，在手机电视业务中，如果原始请求渠道为终端方式，则需要立即下发业务密钥；如果原始请求为非终端方式，则不需要立即向用户发送业务密钥。

与此同时，还需要根据请求订购的原始渠道以及其业务的归属来判断该业务的同步目的地。

综上，在接收处理多渠道订购请求的情况下，把来自多渠道的订购请求统一看作为一种公共消息的处理，同时，把对请求的逻辑处理流程和数据处理流程区分开；这样，当订购或查询的渠道发生变化时，不用对数据库信息交互模块进行修改，只增加或删除消息请求处理模块的处理流程；而只有当数据库表结构发生变化时，才需要对数据库信息交互模块进行修改，缩短了处理时间，提高了处理效率。

以上具体实施方式中业务管理平台下处理多渠道请求订购的方法根据实际应用还可以采用现有各种可能的方案，为本领域技术人员所熟知，在此也不再赘述。

本发明所提供的一种业务管理平台下处理多渠道订购的方法，由于明确了消息请求处理模块和数据库信息交互模块在流程上的分工，保证了流程上的逻辑处理与数据处理过程相分离，使得处理过程条理清晰，从而简化了业务管理平台业务处理流程，缩短了处理时间，提高了处理效率，尤其是在请求的数据量较大时候，减少了出现业务管理平台系统处理上新瓶颈的可能。

应当理解的是，对本领域普通技术人员来说，可以根据上述方案的说明加以改进或变换，例如变换提取有效的请求内容和请求渠道信息的主体等，而所有这些改进和变换都本应属于本发明所附权利要求的保护范围。

工业实用性

本发明所提供的一种业务管理平台下处理多渠道订购的方法和装置，由于明确了消息请求处理模块和数据库信息交互模块在流程上的分工，保证了流程上的逻辑处理与数据处理过程相分离，使得处理过程条理清晰，从而简化了业务管理平台业务处理流程，缩短了处理时间，提高了处理效率，尤其是在请求的数据量较大时候，减少了出现业务管理平台系统处理上新瓶颈的可能。

Claims (10)

1.一种业务管理平台下处理多渠道请求订购的方法，其中所述业务管理平台包括消息请求处理模块和数据库信息交互模块，在接收处理多渠道订购请求的时候，把对请求的逻辑处理流程和数据处理流程分开；所述方法包括：

A、所述消息请求处理模块根据请求订购渠道提取请求信息，并组成统一的请求格式，向所述数据库信息交互模块请求保存或查询数据，具体包括：

A1、消息请求处理模块接收到终端、门户或短信网关的业务请求消息，提取有效的请求内容和请求渠道信息；

A2、根据具体业务的处理需要，对不同的请求渠道采用或调用相应不同的处理流程；

A3、将请求内容与渠道信息拼装成公共的请求结构，向所述数据库信息交互模块发送统一的数据处理请求，请求消息中包含有效的请求内容和渠道信息；

B、所述数据库信息交互模块根据所述消息请求处理模块的请求，判断所述请求的合理性，并向所述消息请求处理模块返回请求的结果。

2.根据权利要求1所述的方法，其中所述步骤A2中所述具体业务的处理需要包括查询请求内容、拆分业务或与所述业务管理平台之间相互进行认证。

3.根据权利要求1所述的方法，其中所述步骤B包括：

B1、所述数据库信息交互模块区分所述消息请求处理模块请求的类型；

B2、对于同一请求类型，统一判断请求的业务信息是否合理并在合理时调用结构化查询语言SQL语句请求数据库的响应；以及

B3、得到所述数据库的响应后，对所述消息请求处理模块返回数据处理结果，并在响应消息中携带原始请求的渠道。

4.根据权利要求3所述的方法，其中所述步骤B2还包括：

B21、若请求的业务信息不合理，则直接返回失败的响应，并结束处理流程。

5.根据权利要求1所述的方法，其中所述步骤B之后还包括：

C、所述消息请求处理模块根据返回的所述请求的结果中的渠道信息，调用相应的处理流程，判断业务的同步目的地并向原始请求方发送响应消息。

6.根据权利要求5所述的方法，其中所述步骤C包括：

C1、所述消息请求处理模块解析接收到的所述数据库信息交互模块的响应消息；

C2、如果所述响应消息为成功的响应消息，则根据所述响应消息中的渠道信息进行数据保存后的处理，向原始请求方回复响应消息，其中所述处理包括判断业务的同步目的地；如果所述响应消息为失败的响应消息，则直接回复原请求方失败的响应消息；以及

C3、所述消息请求处理模块向原始请求方回复响应消息后，处理结束。

7.根据权利要求6所述的方法，其中根据请求订购的原始渠道和/或请求订购业务的归属来判断业务的同步目的地。

8.一种处理多渠道请求订购的业务管理平台，所述业务管理平台包括相互分离的消息请求处理模块和数据库信息交互模块，在接收处理多渠道订购请求的时候，把对请求的逻辑处理流程和数据处理流程分开；其中

所述消息请求处理模块设置成根据请求订购渠道提取请求信息，并组成统一的请求格式，向所述数据库信息交互模块请求保存或查询数据，具体包括：

（1）消息请求处理模块接收到终端、门户或短信网关的业务请求消息，提取有效的请求内容和请求渠道信息；

（2）根据具体业务的处理需要，对不同的请求渠道采用或调用相应不同的处理流程；

（3）将请求内容与渠道信息拼装成公共的请求结构，向所述数据库信息交互模块发送统一的数据处理请求，请求消息中包含有效的请求内容和渠道信息；

所述数据库信息交互模块设置成根据所述消息请求处理模块的请求，判断所述请求的合理性，并向所述消息请求处理模块返回所述请求的结果。

9.根据权利要求8所述的业务管理平台，其中所述消息请求处理模块还设置成根据所述数据库信息交互模块返回的所述请求的结果中的渠道信息，调用相应的处理流程，判断业务的同步目的地并向原始请求方发送响应消息。

10.根据权利要求9所述的业务管理平台，其中所述消息请求处理模块还设置成根据请求订购的原始渠道和/或请求订购业务的归属来判断业务的同步目的地。

Images