CN101232540B

CN101232540B - 间消息交互方法及消息交互

Info

Publication number: CN101232540B
Application number: CN2008100061902A
Authority: CN
Inventors: 薛玉何
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2008-02-21
Filing date: 2008-02-21
Publication date: 2012-04-04
Anticipated expiration: 2028-02-21
Also published as: CN101232540A

Abstract

本发明提供一种***间消息交互方法，包括：步骤S102，对于第一***和第二***，接收到操作请求的一方作为发起方在预置的中间表中加入相应的记录；步骤S104，第一***和第二***中的另一方作为执行方扫描中间表，根据中间表中加入的记录进行相应的处理。此外，本发明还公开了一种消息交互***。通过使用本发明，能够容易地实现***之间的信息传递、信息更新、历史查询，并且具有良好的扩展性和兼容性。

Description

***间消息交互方法及消息交互***

技术领域

本发明涉及通讯领域，并且特别地，涉及一种***间消息交互方法以及消息交互***。

背景技术

智能网(IN)技术出现在上世纪90年代初，是一个能快速、方便、灵活、经济、有效的生成和实现各种新业务的网路体系，建有集中的业务控制点和数据库，具有集中的业务管理***和业务生成环境。

彩铃***音(Coloring Ring Back Tone，CRBT)是一种可以让手机用户自己定制手机彩铃的智能网增值业务。当手机用户申请了这项服务以后，主叫用户拨打该用户的手机时，听到的彩铃再也不是以前单调的“嘟...嘟...”声音，而有可能是一段音乐、问候语等一些人性化的回应声。这些个性化的彩铃是由被叫用户预先设定的，可以是***提供的铃音/音乐，也可以是被叫用户事先通过智能网***录制的语音文件，或被叫用户事先通过网络下载到智能网***的语音文件。

为了确保主叫听到彩铃，CRBT要求网络侧归属位置寄存器(简称HLR，用于对网络提供用户信息管理功能，包括号码、呼叫的路由、以及计费等相关的位置信息)等硬件要具有CRBT属性的设置，这样当用户A播打用户B的电话时，网络要能知道用户B是彩铃用户，然后网络会连接到CRBT来播放彩铃给A听。该CRBT属性一般由BOSS***维护。BOSS***可以实现彩铃用户的开户、销户等功能。

为了确保CRBT的正常使用，以及确定用户是否是CRBT用户，需要在CRBT***和网络侧同时进行维护。在CRBT***中登记用户是否为CRBT用户，然后就可以进行铃音下载及铃音设置，网络侧登记是否为CRBT用户，是便于网络接通彩铃业务播放铃音，网络侧由BOSS维护。由于CRBT和BOSS***都具有开户、销户的权力，为了确保二者数据的同步和一致性，二者必须有接口进行通信。对CRBT的操作一般包括开户、销户、激活、去激活等，这些操作必须同时修改BOSS和CRBT中保存的信息。例如，用户通过CRBT的WEB进行开户，那么CRBT需要开户，相应地BOSS***也需要开户，这时CRBT会通过接口通知BOSS***，反之亦然。

对于如何在BOSS***和CRBT间进行接口，目前存在多种方式，主要可以分为文件通知方式和实时通知方式。实时通知方式要求另外一方也必须同时立即处理发起方的请求，这对BOSS和CRBT的处理速度和性能要求比较高，并且一旦一方失败，由于重发机制复杂，因此将不易重新发出指令，并且操作日志的维护和查询也很复杂。

文件通知方式的处理过程如下，

定义文件接口的格式，其中需要定义的文件包括发出请求文件、请求应答文件(文件字段含义与中间表定义的一样)；

发起请求文件的格式可以为：

文件名：Request_YYYYMMDD_24HHMMSS.dat；

文件格式：ID|MSISDN|Action|Originator|Request_date；

请求应答文件的格式可以为：

文件名：Answer_YYYYMMDD_24HHMMSS.dat；

文件格式可以为：

以CRBT发起开户为例，在CRBT发起开户后，首先在CRBT***中为用户开户；

CRBT产生文件Request_YYYYMMDD_24HHMMSS.dat并FTP到BOSS指定的目录；

ID|MSISDN|Action|Originator|Request_date

11|9988672|SUB|CRBT|20070101

BOSS定时(如每5分钟)从指定目录扫描文件，如有文件则立即进行处理，修改HLR的CRBT相关属性信息；

不论修改成功或者失败，BOSS都会返回应答文件，如下：Answer_YYYYMMDD_24HHMMSS.dat。

如果修改成功，则文件的内容可以为：

11|9988672|SUB|CRBT|YES||20070101

如果修改失败，则文件的内容可以为：

11|9988672|SUB|CRBT|NO|XXX|20070101

上述文件接口方式能够实现CRBT与BOSS之间的接口，并且对***的性能要求不高，不会增加***的额外成本。然而，这种方式存在以下问题：

(1)文件处理复杂，例如，难以处理同一秒到达的多个请求；

(2)接口记录查询难，例如，如果需要查询总共发出了多少个开户命令及每次命令执行结果如何，就必须打开所有请求文件，并且要找到对应的应答文件，此外，如果一旦在该过程中出现偏差，就无法准确定位原因；

(3)可扩展性差，如果想增加一些用户信息，例如，用户是预付费还是后付费，那么就需要增加一些一个字段，这样两边软件都需要改动，并且难以追查历史文件。

然而，目前尚未提出能够解决在BOSS***和CRBT间实现接口的过程中存在的实现复杂、不易追查等问题的技术方案。

发明内容

考虑到上述问题而做出本发明，为此，本发明的主要目的在于提供一种***间消息交互方法和消息交互***，以解决相关技术中处理复杂度高、不易追查、扩展性差的问题。

根据本发明的实施例，提供了一种***间消息交互方法。

该方法包括：步骤S102，对于第一***和第二***，其中接收到操作请求的一方作为发起方在预置的中间表中加入相应的记录，其中，记录包括操作类型标识、发起方标识、发起方处理状态标识、以及执行方处理状态标识、操作对象标识；步骤S104，第一***和第二***中的另一方作为执行方扫描中间表，根据中间表中加入的记录进行相应的处理，并将处理的结果加入中间表以供发起方；其中，在步骤S102中，发起方可将发起方标识设置为其本身的标识，将发起方处理状态标识设置为已经处理，以及将执行方处理状态标识设置为未经处理；在步骤S104中，执行方定时扫描中间表，在通过扫描获知发起方标识为发起方的标识以及执行方处理状态标识设置为未经处理的情况下，根据操作对象标识进行处理，并根据处理结果将执行方处理状态标识设置为已经处理或发生错误。

并且，该方法可进一步包括：预先配置与多种操作类型分别对应的操作类型标识，发起方根据操作请求所请求的操作在记录中设置相应的操作类型标识。

之后，中间表包括错误码标识，在处理出现错误的情况下，执行方在错误码标识中写入错误原因。

此外，中间表进一步包括请求标识、发起方对中间表的更新时间、执行方对中间表的更新时间、操作请求的发起日期，其中，发起的每次操作分别对应于一个请求标识。

除此之外，上述多种操作包括开启账户、撤消账户、激活业务、去激业务。

另外，上述第一***为彩铃***，上述第二***为综合运营支撑***；或

上述第一***为综合运营支撑***，上述第二***为彩铃***。

而在步骤S102之前，还可以进一步包括：由第一***或第二***建立中间表，并定期备份中间表、以及清除中间表的历史记录。

根据本发明的另一实施例，提供了一种消息交互***。

该***包括：第一***；第二***；中间表，作为第一***和第二***间的接口；其中，对于第一***和第二***，接收到操作请求的一方作为发起方在中间表中加入相应的记录，其中，记录包括操作类型标识、发起方标识、发起方处理状态标识、以及执行方处理状态标识、操作对象标识；发起方可将发起方标识设置为其本身的标识，将发起方处理状态标识设置为已经处理，以及将执行方处理状态标识设置为未经处理；第一***和第二***中的另一方作为执行方扫描中间表，根据中间表中加入的记录进行相应的处理，其中，执行方定时扫描中间表，在通过扫描获知发起方标识为发起方的标识以及执行方处理状态标识设置为未经处理的情况下，根据操作对象标识进行处理，并根据处理结果将执行方处理状态标识设置为已经处理或发生错误。

其中，第一***为彩铃***，第二***为综合运营支撑***；或第一***为综合运营支撑***，第二***为彩铃***。

通过本发明的上述技术方案，能够容易地实现***之间的信息传递、信息更新、历史查询，并且具有良好的扩展性和兼容性。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明方法实施例的***间消息交互方法的流程图；

图2是根据本发明方法实施例的***间消息交互方法中所使用的中间表在***中的位置的示意图；以及

图3是根据本发明***实施例的消息交互***的框图。

具体实施方式

下面参考附图，详细说明本发明的具体实施方式。

方法实施例

在本实施例中，提供了一种***间消息交互方法，以解决CRBT与BOSS***接口困难的问题，

如图1所示，根据本发明实施例的***间消息交互方法包括：步骤Sl02，对于第一***(可以是CRBT)和第二***(可以是BOSS)，其中接收到操作请求的一方作为发起方在预置的中间表(也可称为数据库中间表，是第一***与第二***间的接口)中加入相应的记录；步骤S104，第一***和第二***中的另一方作为执行方扫描中间表，根据中间表中加入的记录进行相应的处理。优选地，之后还可将处理的结果加入中间表以供发起方。

其中，如表l所示，被加入到中间表中的上述记录可以包括操作类型标识(Action)、发起方标识(Originator)、以及操作对象标识(MSISDN)，而表1中的CRBT_flag和BOSS_flag为发起方处理状态标识和执行方处理状态标识。如果CRBT为发起方，则CRBT将CRBT_flag设置为已经处理，并将BOSS_flag设置为未经处理，反之亦然。

并且，该方法可进一步包括：预先配置与多种操作类型分别对应的操作类型标识，例如，SUB对应于开户，UN对应于消户。A 对应于激活，B对应于去激活，发起方根据操作请求所请求的操作在记录中设置相应的操作类型标识。

在步骤S102中，发起方可将发起方标识设置为其本身的标识，将发起方处理状态标识设置为已经处理，以及将执行方处理状态标识设置为未经处理。

此时，执行方定时扫描中间表，在通过扫描获知发起方标识为发起方的标识、以及执行方处理状态标识设置为未经处理的情况下，根据操作对象标识进行处理，并根据处理结果将执行方处理状态标识设置为已经处理或发生错误。

并且，如表1所示，中间表可以包括错误码标识(Error_code)，在处理出现错误的情况下，执行方在错误码标识中写入错误原因。

此外，中间表可进一步包括请求标识(ID)、发起方对中间表的更新时间(CRBT_data)、执行方对中间表的更新时间(BOSS_data)、以及操作请求的发起日期(Request_date)，其中，发起的每次操作分别对应于一个请求标识。

上述第一***为综合运营支撑***，上述第二***为彩铃***。

并且，两个***均可以作为发起方。

在实际应用当中，中间表在接口中的位置如图2的图示。CRBT可以通过WEB、短消息SMS、IVR语音管理流程进行CRBT的各种操作，任何操作都会作为一条表记录***中间表，BOSS***定时读取中间表获得这些待处理的记录进行相应的操作，并进行BOSS***的数据更新；同样，BOSS也可以进行CRBT的各种操作，并通过中间表通知CRBT进行数据更新。

中间表的基本表结构如下表所示，与数据库类型(例如，Oracle、Sybase等)无关。该表可以建立在CRBT的数据库，或者BOSS指定的数据库，建立该表的一方要定期备份并删除该表的历史记录，使其保持具有良好的性能。

表1

字段	类型	描述
			ID	Number(38)	请求ID，是记录的唯一标识，用于识别、修改该条记录数据时参考引用，是一个唯一的数字
MSISDN	Varchar2(10)	***作对象的号码，例如，13212345678
			Action	Varchar2(3)	要执行的操作，取值如下： SUB：开户 UN：销户 A：激活CRBT业务 S：去激活CRBT业务
Originator	Varchar2(10)	发起方 BOSS＝BOSS发起 CRBT＝彩铃中心发起
			Request_date	Date	发起方***日期
CRBT_flag	Varchar2(1)	彩铃中心处理状态： N＝尚未处理 Y：-处理完毕 E：-处理中发生错误
			BOSS_flag	Varchar2(1)	BOSS处理状态： N＝尚未处理 Y：-处理完毕 E：-处理中发生错误
Error_code	Varchar2(10)	错误码标识，根据需要定义，例如， 101—用户不存在。
			CRBT_date	Datetime	彩铃中心更新时间
BOSS_date	Datetime	BOSS更新时间

一方(发起方)处理后，***一条记录到中间表，另外一方(执行方)扫描中间表，以找到需要处理的记录，在修改***后向该中间表回写成功或失败信息。发起方可以扫描中间表获得对方处理结果。也就是说，两方的***均能够读/写该中间表。

例如，要为号码为13212345678的手机开通彩铃业务CRBT，就***一条开户记录，可以是：ID＝123456，MSISDN＝13212345678，Action＝SUB...)。

下面结合具体实例对本发明的方法作进一步的详细说明。

实例1：CRBT开户

CRBT发起开户后，在CRBT***中为用户开户；

CRBT***中间表记录：Action＝‘SUB’，CRBT_flag＝‘Y’，BOSS_flag＝‘N’，Originator＝‘CRBT’；

BOSS定时(例如，每5分钟)扫描中间表，处理BOSS_flag＝‘N’，Originator＝‘CRBT’部分，发现该记录后，修改HLR的CRBT相关属性信息；

修改成功则修改中间表BOSS_flag＝‘Y’；修改失败则修改BOSS_flag＝‘E’，Error_code＝‘XXX’。

实例2：BOSS开户

BOSS发起开户，BOSS修改HLR的CRBT相关属性信息；

BOSS***中间表记录：Action＝‘SUB’，CRBT_flag＝‘N’，BOSS_flag＝‘Y’，Originator＝‘BOSS’；

CRBT定时(如每5分钟)扫描中间表，处理CRBT-flag＝‘N’，Originator＝‘BOSS’部分，发现该记录后，在CRBT***中为用户开户；

开户成功则修改中间表CRBT_flag＝‘Y’；失败则修改CRBT_flag＝‘E’，Errot_code＝‘XXX’。

对于CRBT销户的情况，流程同上面的开户流程类似，需要将Action标识修改为“UN”。

实例3：激活CRBT

CRBT发起激活，在CRBT***中修改该用户的CRBT属性以激活该用户使用CRBT；

CRBT***中间表记录：Action＝‘A’，CRBT_flag＝‘Y’，BOSS_flag＝‘N’，Originator＝‘CRBT’；

BOSS定时(如每5分钟)扫描中间表，处理BOSS_flag＝‘N’，Originator＝‘CRBT’部分，发现该记录后，修改HLR的CRBT相关属性信息，激活该用户的CRBT；

实例4：BOSS激活

BOSS发起激活，BOSS修改HLR的CRBT相关属性信息，激活该用户的CRBT；

BOSS***中间表记录：Action＝‘A’，CRBT_flag＝‘N’，BOSS_flag＝‘Y’，Originator＝‘BOSS’；

CRBT定时(如每5分钟)扫描中间表，处理CRBT_flag＝‘N’，Originator＝‘BOSS’部分，发现该记录后，在CRBT***中修改该用户的CRBT属性以激活该用户使用CRBT；

开户成功则修改中间表CRBT_flag＝‘Y’；失败则修改CRBT_flag＝‘E’，Error_code＝‘XXX’。

去激活流程同上面的激活流程一样，需要将Action修改为“S”。

上述流程描述了本发明可以执行的部分处理，本领域技术人员应当理解，在实际实施时可以根据需要对表的字段数量和字段的值进行扩充以支持更多流程和更多操作。

***实施例

在本实施例中，提供了一种消息交互***。

如图3所示，根据本实施例的消息交互***包括：第一***302；第二***304；中间表306，作为第一***302和第二***304间的接口；其中，对于第一***302和第二***304，其中接收到操作请求的一方作为发起方在预置的中间表306中加入相应的记录；第一***302和第二***304中的另一方作为执行方扫描中间表，根据中间表306中加入的记录进行相应的处理。

其中，第一***为彩铃***，第二***为综合运营支撑***；或者第一***为综合运营支撑***，第二***为彩铃***。

综上所述，借助于本发明的技术方案，能够容易地实现***之间的信息传递、信息更新、历史查询，并且具有良好的扩展性和兼容性。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种***间消息交互方法，用于第一***和第二***间的消息交互，其特征在于，包括：

步骤S102，对于所述第一***和所述第二***，接收到操作请求的一方作为发起方在预置的中间表中加入相应的记录，其中，所述记录包括操作类型标识、发起方标识、发起方处理状态标识、以及执行方处理状态标识、操作对象标识；

步骤S104，所述第一***和所述第二***中的另一方作为执行方扫描所述中间表，根据所述中间表中加入的所述记录进行相应的处理；

其中，在所述步骤S102中，所述发起方将所述发起方标识设置为其本身的标识，将所述发起方处理状态标识设置为已经处理，以及将所述执行方处理状态标识设置为未经处理；在所述步骤S104中，所述执行方定时扫描所述中间表，在通过扫描获知所述发起方标识为所述发起方的标识以及所述执行方处理状态标识设置为未经处理的情况下，根据所述操作对象标识进行处理，并根据处理结果将所述执行方处理状态标识设置为已经处理或发生错误。

2.根据权利要求1所述的***间消息交互方法，其特征在于，进一步包括：

预先配置与多种操作类型分别对应的操作类型标识，所述发起方根据所述操作请求所请求的操作在所述记录中设置相应的操作类型标识。

3.根据权利要求1所述的***间消息交互方法，其特征在于，所述中间表包括错误码标识，在处理出现错误的情况下，所述执行方在所述错误码标识中写入错误原因。

4.根据权利要求3所述的***间消息交互方法，其特征在于，所述中间表进一步包括请求标识、所述发起方对所述中间表的更新时间、所述执行方对所述中间表的更新时间、所述操作请求的发起日期，其中，发起的每次操作分别对应于一个请求标识。

5.根据权利要求2所述的***间消息交互方法，其特征在于，所述多种操作包括开启账户、撤消账户、激活业务、去激业务。

6.根据权利要求1至4中任一项所述的***间消息交互方法，其特征在于，

所述第一***为彩铃***，所述第二***为综合运营支撑***；或

所述第一***为综合运营支撑***，所述第二***为彩铃***。

7.根据权利要求1至4中任一项所述的***间消息交互方法，其特征在于，在所述步骤S102之前，进一步包括：

由所述第一***或所述第二***建立所述中间表，并定期备份所述中间表、以及清除所述中间表的历史记录。

8.一种消息交互***，其特征在于，包括：

第一***；

第二***；

中间表，作为所述第一***和所述第二***之间的接口；

其中，对于所述第一***和所述第二***，接收到操作请求的一方作为发起方在所述中间表中加入相应的记录，其中，所述记录包括操作类型标识、发起方标识、发起方处理状态标识、以及执行方处理状态标识、操作对象标识；所述发起方将所述发起方标识设置为其本身的标识，将所述发起方处理状态标识设置为已经处理，以及将所述执行方处理状态标识设置为未经处理；

所述第一***和所述第二***中的另一方作为执行方扫描所述中间表，根据所述中间表中加入的所述记录进行相应的处理，其中，所述执行方定时扫描所述中间表，在通过扫描获知所述发起方标识为所述发起方的标识以及所述执行方处理状态标识设置为未经处理的情况下，根据所述操作对象标识进行处理，并根据处理结果将所述执行方处理状态标识设置为已经处理或发生错误。

9.根据权利要求8所述的消息交互***，其特征在于，

所述第一***为彩铃***，所述第二***为综合运营支撑***；或

所述第一***为综合运营支撑***，所述第二***为彩铃***。