CN102055606B - 一种业务支撑系统中的业务处理方法、系统及设备 - Google Patents

Abstract

本发明公开了一种业务支撑系统中的业务处理方法、系统及设备，主要内容包括：业务支撑系统向业务服务器发送业务请求后，在等待业务服务器返回响应消息的过程中执行所述业务请求对应的业务，返回成功响应消息时，业务支撑系统继续执行所述业务直至业务完成，因此，本发明实施例的方案对业务支撑系统和业务服务器的性能没有特别高的要求，并且还提高了业务执行的效率；在返回失败响应消息时，业务支撑系统停止执行所述业务，因此，确保了业务支撑系统和业务服务器之间业务数据的一致性，保证业务执行的准确性。

Description

一种业务支撑系统中的业务处理方法、系统及设备

技术领域

本发明涉及通信领域，尤其涉及一种业务支撑系统中的业务处理方法、系统及设备。

背景技术

业务支撑系统中的业务需要通过业务支撑系统与业务服务器之间的交互完成，目前，业务支撑系统和业务服务器之间有两种报文交互方式，以业务支撑系统作为业务发起方为例，这两种报文交互方式分别为同步方式和异步方式。

同步方式是指：业务支撑系统向业务服务器发送业务请求的报文后，在等待业务服务器返回响应消息后，根据返回的响应消息进行相应的处理。

异步方式是指：业务支撑系统向业务服务器发送业务请求的报文后，不需要业务服务器返回响应消息，而直接执行后续的业务。

在同步方式下，对业务支撑系统中的网元和业务服务器的性能要求很高，实施难度大，如果业务支撑系统的业务量巨大，很难保证用户请求业务的处理效率，且等待业务服务器返回响应消息的过程中很容易出现大量的等待延迟。在异步方式下，由于不需要等待业务服务器返回响应消息，相对于同步方式而言能够提高业务的处理效率，但是，由于业务支撑系统和业务服务器之间没有数据同步，因此，业务支撑系统和业务服务器之间容易出现业务数据不一致的问题，对于业务服务器无法正确响应业务支撑系统发送的业务请求的情况下，无法进行回退处理，降低了业务请求感受。

综上所述，在现有的业务支撑系统中的业务处理过程中，同步方式的实施难度大、等待业务服务器返回响应消息造成业务处理效率低的问题；异步方式会导致业务支撑系统和业务服务器之间出现业务数据不一致，无法保证业务执行的准确性的问题。

发明内容

本发明实施例提供一种业务支撑系统中的业务处理方法、系统及设备，解决业务支撑系统的业务处理效率低、无法保证业务执行的准确性的问题。

一种业务支撑系统中的业务处理方法，所述方法包括以下步骤：

业务支撑系统向业务服务器发送业务请求后，执行下述业务处理操作：

业务支撑系统执行所述业务请求对应的业务；

在所述业务执行完成之前，业务支撑系统接收所述业务服务器针对所述业务请求返回的响应消息；

在所述响应消息为成功响应消息时，业务支撑系统继续执行所述业务直至业务完成，在所述响应消息为失败响应消息时，业务支撑系统停止执行所述业务。

一种业务处理系统，所述系统包括业务支撑系统中的支撑服务器和业务服务器，其中：

所述支撑服务器，用于向业务服务器发送业务请求后，执行下述业务处理操作：

支撑服务器执行所述业务请求对应的业务，并在所述业务执行完成之前，接收所述业务服务器针对所述业务请求返回的响应消息，在所述响应消息为成功响应消息时，继续执行所述业务直至业务完成，在所述响应消息为失败响应消息时，停止执行所述业务；

所述业务服务器，用于在接收到所述业务请求后，向所述支撑服务器返回响应消息。

一种支撑服务器，应用于业务支撑系统中，所述支撑服务器包括：

请求发送模块，用于发送业务请求；

响应消息接收模块，用于接收针对所述业务请求的响应消息；

请求执行模块，用于在接收到所述响应消息之前，执行所述业务请求对应的业务；

控制模块，用于在所述响应消息为成功响应消息时，指示所述请求执行模块继续执行所述业务直至业务完成，在所述响应消息为失败响应消息时，指示所述请求执行模块停止执行所述业务。

本发明实施例结合现有的业务支撑系统和业务服务器之间的同步交互方式和异步交互方式，业务支撑系统向业务服务器发送业务请求后，在等待业务服务器返回响应消息的过程中执行所述业务请求对应的业务，返回成功响应消息时，业务支撑系统继续执行所述业务直至业务完成，因此，本发明实施例的方案对业务支撑系统和业务服务器的性能没有特别高的要求，并且还提高了业务执行的效率；在返回失败响应消息时，业务支撑系统停止执行所述业务，因此，确保了业务支撑系统和业务服务器之间业务数据的一致性，保证业务执行的准确性。

附图说明

图1为本发明实施例一中针对业务支撑系统的业务处理方法示意图；

图2为本发明实施例二中针对业务支撑系统的业务处理方法示意图；

图3为本发明实施例三中业务处理系统结构示意图；

图4为本发明实施例四中支撑服务器结构示意图。

具体实施方式

为了实现本发明目的，本发明实施例在异步方式的基础上增加了同步方式下的响应消息反馈机制，由于业务支撑系统最终完成业务的执行需要利用反馈的响应消息，因此，保证了业务执行的准确性；并且，由于在等待响应消息的反馈过程中，业务支撑系统继续执行所述业务请求对应的业务，因此，提高了业务执行的效率。

下面结合说明书附图对本发明实施例进行详细描述。

实施例一：

如图1所示，为本发明实施例一中针对业务支撑系统的业务处理方法示意图，所述方法包括以下步骤：

步骤101：业务支撑系统向业务服务器发送业务请求后，执行所述业务请求对应的业务。

在本实施例中，业务支撑系统中存储了多个用户账户，针对某一用户的需求，利用该用户存储在业务支撑系统中的用户账户发送业务请求。

在本步骤中，业务支撑系统仍采用异步方式，在业务请求的报文向业务服务器发送后，业务支撑系统将生成的工单置为“成功”，不需要等待业务服务器返回的响应消息就正常执行所述业务请求对应的业务。

步骤102：在所述业务执行完成之前，业务支撑系统接收所述业务服务器针对所述业务请求返回的响应消息。

在本步骤中，业务支撑系统在业务最终执行完成之前接收业务服务器返回的响应消息。如果业务支撑系统在即将完成业务时还未收到业务服务器返回的响应消息，则业务支撑系统在执行业务的最后一步之前停止，直至接收到业务服务器返回的响应消息。

步骤103：业务支撑系统确定接收到的响应消息的类型，如果是成功响应消息，则执行步骤104；如果是失败响应消息，则执行步骤105。

步骤104：业务支撑系统继续执行所述业务直至业务完成。

业务支撑系统实时采集业务服务器返回的响应消息，对于返回的成功响应消息不进行处理，直接存入数据库中待查。

在本步骤的方案中，业务支撑系统在等待业务服务器返回的响应消息的同时还在执行对应的业务，因此，当收到成功响应消息后，业务支撑系统只需要继续执行业务的剩余步骤，与现有的同步方式相比，对业务支撑系统和业务服务器的性能没有特别高的要求，并且还提高了业务执行的效率。

步骤105：业务支撑系统停止执行所述业务。

在本步骤的方案中，业务支撑系统收到失败响应消息时停止业务的执行，与现有的异步方式相比，确保了业务支撑系统和业务服务器之间业务数据的一致性，保证业务执行的准确性。

通过上述步骤101~步骤104的方案，使业务支撑系统的业务处理的准确性得以提高，并且还提高了业务执行的效率，实现了本发明目的。

实施例二：

本发明实施例二是实施例一的基础上，对于业务服务器返回失败响应消息的情况下，业务支撑系统可以进入重发流程，也可以进入非重发流程，下面分别对这两种流程进行说明。

如图2所示，为本发明实施例二的方法示意图，包括以下步骤：

步骤201~步骤205与实施例一中步骤101~步骤105相同。

步骤206：在业务支撑系统停止执行所述业务之后，还根据失败响应消息中携带失败类型信息，确定是否需要向所述业务服务器重新发送所述业务请求；若是，则执行步骤207；否则，执行步骤210。

重新发送业务请求的方式与正常发送业务请求的方式相同。

在本实施例中，只有在失败响应消息中携带特定的失败类型信息时才需要进行业务请求的重发，如：失败响应消息中携带与传输网络状态、传输网元性能相关的失败类型信息时需要进行重发，包括业务响应超时失败类型信息或主键冲突失败类型信息等。

对于一些失败类型信息，如：失败响应消息中携带与业务请求对应的用户账户相关的失败类型信息时不需要进行重发，包括用户账户已注销失败类型信息或用户账户未激活失败类型信息。因为即使重新发送也不能在业务服务器进行正确处理，因此，业务支撑系统继续执行所述业务直至业务完成，并将业务执行完成后生成的数据同步至所述业务服务器，使业务支撑系统和业务服务器针对同一用户账户的数据保持一致。具体的同步过程可以在业务支撑系统完成业务后立即执行，也可以定时进行同步（如每日进行一次针对多个业务请求的数据同步）。

步骤207：业务支撑系统判断所述业务请求的重发次数是否大于设定次数；若是，则执行步骤208；否则，执行步骤209。

步骤208：业务支撑系统不向所述业务服务器重新发送所述业务请求，并将业务支撑系统中存储的所述业务请求对应的用户账户的数据回滚至第一次向业务服务器发送所述业务请求时的数据，结束业务处理流程。

为了避免出现过多的失败工单，需要对重发的次数进行限制，在重发次数大于设定次数时，对业务支撑系统中存储的用户账户的数据进行回滚，保证业务支撑系统和业务服务器存储数据的一致性。

生成的失败工单可以共管理员查询，以便于进行业务解释。

步骤209：业务支撑系统向所述业务服务器重新发送所述业务请求，并更新所述业务请求的重发次数，然后跳转至步骤201，重新执行步骤201~步骤205。

在本步骤中，跳转至步骤210后，业务支撑系统可以从初始开始重新执行业务请求对应的业务，也可以在上一次执行所述业务请求对应业务的基础上，继续执行该业务。

步骤210：业务支撑系统继续执行所述业务直至业务完成，并将业务执行完成后生成的数据同步至所述业务服务器，此时结束业务处理流程。

实施例三：

本发明实施例三提供一种业务处理系统，如图3所示，所述系统包括业务支撑系统中的支撑服务器11和业务服务器12，其中：所述支撑服务器11用于向业务服务器12发送业务请求后，执行下述业务处理操作：支撑服务器11执行所述业务请求对应的业务，并在所述业务执行完成之前，接收所述业务服务器12针对所述业务请求返回的响应消息，在所述响应消息为成功响应消息时，继续执行所述业务直至业务完成，在所述响应消息为失败响应消息时，停止执行所述业务；所述业务服务器12用于在接收到所述业务请求后，向所述支撑服务器返回响应消息。

进一步地，所述支撑服务器11还用于根据失败响应消息中携带失败类型信息，确定是否需要向所述业务服务器12重新发送所述业务请求，若是，则向所述业务服务器12重新发送所述业务请求；否则，继续执行所述业务直至业务完成，并将业务执行完成后生成的数据同步至所述业务服务器12。

所述支撑服务器11还用于判断重发次数是否大于设定次数，若是，则不向所述业务服务器12重新发送所述业务请求，并将自身存储的所述业务请求对应的用户账户的数据回滚至第一次向业务服务器12发送所述业务请求时的数据；否则，向所述业务服务器12重新发送所述业务请求。

实施例四：

本发明实施例四还提供一种应用于业务支撑系统中的支撑服务器，如图4所示，所述支撑服务器包括请求发送模块21、请求执行模块22、响应消息接收模块23和控制模块24，其中：请求发送模块21用于发送业务请求；请求执行模块22用于在接收到所述响应消息之前，执行所述业务请求对应的业务；响应消息接收模块23用于接收针对所述业务请求的响应消息；控制模块24用于在所述响应消息为成功响应消息时，指示所述请求执行模块继续执行所述业务直至业务完成，在所述响应消息为失败响应消息时，指示所述请求执行模块停止执行所述业务。

进一步地，所述控制模块24还用于指示所述请求执行模块22停止执行所述业务后，根据失败响应消息中携带失败类型信息，确定是否需要重新发送所述业务请求，若是，则指示请求发送模块21重新发送所述业务请求；否则，指示所述请求执行模块22继续执行所述业务直至业务完成，并由支撑服务器中的同步模块25将业务执行完成后生成的数据同步至业务服务器。

所述支撑服务器还包括数据存储模块26，用于存储用户账户的数据；控制模块24还用于判断所述业务请求的重发次数是否大于设定次数，若是，则不再重新发送所述业务请求，并将数据存储模块26存储的所述业务请求对应的用户账户的数据回滚至第一次发送所述业务请求时的数据；否则，指示请求发送模块21重新发送所述业务请求。

本发明各实施例涉及的业务支撑系统可以是BOSS系统，针对请求的业务不同，涉及的业务服务器也可以不同，例如，如果请求的业务是飞信业务，则所述业务服务器可以是飞信业务服务器。

通过本发明实施例提供的方法、系统及设备，在保持业务请求的异步方式下，保证业务执行的高效性，同时结合同步方式，根据业务服务器返回的响应消息执行业务，保证了业务支撑系统和业务服务器中数据的一致性，提高了业务执行的准确性；并且，新增的业务请求重发可以提高业务请求的成功率。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (13)

1.一种业务支撑系统中的业务处理方法，其特征在于，所述方法包括以下步骤：

业务支撑系统向业务服务器发送业务请求后，执行下述业务处理操作：

业务支撑系统执行所述业务请求对应的业务；

在所述业务执行完成之前，业务支撑系统接收所述业务服务器针对所述业务请求返回的响应消息；

在所述响应消息为成功响应消息时，业务支撑系统继续执行所述业务直至业务完成，在所述响应消息为失败响应消息时，业务支撑系统停止执行所述业务。

2.如权利要求1所述的方法，其特征在于，所述失败响应消息中携带失败类型信息；

所述业务支撑系统停止执行所述业务之后，所述方法还包括：

所述业务支撑系统根据失败响应消息中携带失败类型信息，确定是否需要向所述业务服务器重新发送所述业务请求；

在需要重新发送所述业务请求时，业务支撑系统向所述业务服务器重新发送所述业务请求，并执行所述业务处理操作。

3.如权利要求2所述的方法，其特征在于，所述方法还包括：

在不需要重新发送所述业务请求时，业务支撑系统执行所述停止执行之后未执行的业务，直至业务完成，并将业务执行完成后生成的数据同步至所述业务服务器。

4.如权利要求2所述的方法，其特征在于，确定需要向所述业务服务器重新发送所述业务请求之后，并且向所述业务服务器重新发送所述业务请求之前，所述方法还包括：

业务支撑系统确定所述业务请求的重发次数不大于设定次数。

5.如权利要求4所述的方法，其特征在于，确定需要向所述业务服务器重新发送所述业务请求之后，所述方法还包括：

业务支撑系统确定所述业务请求的重发次数大于设定次数时，不向所述业务服务器重新发送所述业务请求，并将业务支撑系统中存储的所述业务请求对应的用户账户的数据回滚至第一次向业务服务器发送所述业务请求时的数据。

6.一种业务处理系统，其特征在于，所述系统包括业务支撑系统中的支撑服务器和业务服务器，其中：

所述支撑服务器，用于向业务服务器发送业务请求后，执行下述业务处理操作：

支撑服务器执行所述业务请求对应的业务，并在所述业务执行完成之前，接收所述业务服务器针对所述业务请求返回的响应消息，在所述响应消息为成功响应消息时，继续执行所述业务直至业务完成，在所述响应消息为失败响应消息时，停止执行所述业务；

所述业务服务器，用于在接收到所述业务请求后，向所述支撑服务器返回响应消息。

7.如权利要求6所述的业务处理系统，其特征在于，

所述支撑服务器，还用于根据失败响应消息中携带失败类型信息，确定是否需要向所述业务服务器重新发送所述业务请求，在需要重新发送所述业务请求时，向所述业务服务器重新发送所述业务请求，并执行所述业务处理操作。

8.如权利要求7所述的业务处理系统，其特征在于，

所述支撑服务器，还用于在不需要重新发送所述业务请求时，执行所述停止执行之后未执行的业务，直至业务完成，并将业务执行完成后生成的数据同步至所述业务服务器。

9.如权利要求8所述的业务处理系统，其特征在于，

所述支撑服务器，还用于判断所述业务请求的重发次数是否大于设定次数，若是，则不向所述业务服务器重新发送所述业务请求，并将自身存储的所述业务请求对应的用户账户的数据回滚至第一次向业务服务器发送所述业务请求时的数据；否则，向所述业务服务器重新发送所述业务请求。

10.一种支撑服务器，应用于业务支撑系统中，其特征在于，所述支撑服务器包括：

请求发送模块，用于发送业务请求；

响应消息接收模块，用于接收针对所述业务请求的响应消息；

请求执行模块，用于在接收到所述响应消息之前，执行所述业务请求对应的业务；

控制模块，用于在所述响应消息为成功响应消息时，指示所述请求执行模块继续执行所述业务直至业务完成，在所述响应消息为失败响应消息时，指示所述请求执行模块停止执行所述业务。

11.如权利要求10所述的支撑服务器，其特征在于，

所述控制模块，还用于指示所述请求执行模块停止执行所述业务后，根据失败响应消息中携带失败类型信息，确定是否需要重新发送所述业务请求，在需要重新发送所述业务请求时，指示请求发送模块重新发送所述业务请求，并触发所述请求执行模块和所述控制模块。

12.如权利要求11所述的支撑服务器，其特征在于，

所述控制模块，还用于在不需要重新发送所述业务请求时，指示所述请求执行模块执行所述停止执行之后未执行的业务，直至业务完成；

所述支撑服务器还包括：

同步模块，用于将业务执行完成后生成的数据同步至业务服务器。

13.如权利要求12所述的支撑服务器，其特征在于，所述支撑服务器还包括：

数据存储模块，用于存储用户账户的数据；

所述控制模块，还用于判断所述业务请求的重发次数是否大于设定次数，若是，则将存储的所述业务请求对应的用户账户的数据回滚至第一次发送所述业务请求时的数据；否则，指示请求发送模块重新发送所述业务请求。

Images