一种报文处理方法与装置与流程

本申请涉及计算机技术领域，尤其涉及一种报文处理方法与装置。

背景技术：

目前，网络数据传输已广泛采用异步传输(asynchronoustransmission)的方式。

由于采用异步传输的方式，发送方向接收方发送完数据后，不必等到接收方接收到数据，便可继续传输其他数据，因此在实际应用中，采用异步传输可能会出现报文乱序。例如，当服务器采用异步传输的方式向业务系统发送业务报文时，服务器响应于用户的需求，向业务系统发送业务报文，在该业务报文还未到达业务系统时，用户如果紧接着申请对所述业务报文对应的业务进行变更(如申请撤销业务等)，服务器会向业务系统发送用于请求业务系统变更业务的业务变更报文。在网络抖动等因素的影响下，业务变更报文有可能先于业务报文达到业务系统，或者与业务报文同时达到业务系统，从而出现报文乱序。

报文乱序会影响业务系统对报文的处理。具体而言，报文乱序会造成业务系统无法按照正常的处理程序来处理业务，从而导致业务系统一直处于处理某个业务的状态或者最终导致业务处理失败。因此，目前亟需一种用于解决业务系统报文乱序问题的方法。

技术实现要素：

本申请实施例提供一种报文处理方法，用以解决现有技术中业务系统受到报文乱序的影响而无法正常处理业务的问题。

本申请实施例还提供一种基于网商银行的报文处理方法，用以解决现有技 术中业务系统受到报文乱序的影响而无法正常处理业务的问题。

本申请实施例提供一种报文处理装置，用以解决现有技术中业务系统受到报文乱序的影响而无法正常处理业务的问题。

本申请实施例还提供一种基于网商银行的报文处理装置，用以解决现有技术中业务系统受到报文乱序的影响而无法正常处理业务的问题。

本申请实施例采用下述技术方案：

一种报文处理方法，包括：

接收业务变更报文；

判断业务系统是否已接收到业务变更报文对应的业务报文；

判断结果为是时，向业务系统发送所述业务变更报文；

判断结果为否时，执行上述判断业务系统是否已接收到业务变更报文对应的业务报文的步骤。

一种基于网商银行的报文处理方法，包括：

金融网络系统接收网银中心发送的撤销通用处理确认报文；

金融网络系统判断业务系统是否接收到撤销通用处理确认报文对应的借贷记业务报文；

判断结果为是时，向业务系统发送所述撤销通用处理确认报文；

判断结果为否时，执行上述判断业务系统是否已接收到撤销通用处理确认报文对应的借贷记业务报文的步骤；

其中，所述撤销通用处理确认报文，是用于撤销借贷记业务的报文。

一种报文处理装置，包括：

接收模块，用于接收业务变更报文；

第一业务判断模块，用于判断业务系统是否已接收到业务变更报文对应的业务报文；判断结果为是时，触发发送模块；判断结果为否时，触发第一业务判断模块；

发送模块，用于向业务系统发送所述业务变更报文。

一种基于网商银行的报文处理装置，包括：

金融网络接收模块，用于接收网银中心发送的撤销通用处理确认报文；

第一金融网络业务判断模块，用于判断业务系统是否已接收到撤销通用处理确认报文对应的业务报文；判断结果为是时，触发发送模块；判断结果为否时，触发第一金融网络业务判断模块；

金融网络发送模块，用于向业务系统发送所述撤销通用处理确认报文；

其中，所述撤销通用处理确认报文，是用于撤销借贷记业务的报文。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

采用本申请提供的方法，由于是在业务系统接收到业务变更报文对应的业务报文后，才向业务系统发送业务变更报文，从而可以保证业务报文和业务变更报文在到达业务系统时不会出现乱序的情况，这样，业务系统便不会受到报文乱序的影响，可以正常处理业务。

附图说明

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

图1为本申请实施例提供的一种报文处理方法的具体流程示意图；

图2a为本申请实施例提供的一种涉及借贷记业务报文的报文处理方法具体流程示意图；

图2b为本申请实施例提供的一种网商银行处理业务报文的具体流程示意图；

图2c为本申请实施例提供的一种涉及借贷记业务报文和撤销通用处理确认报文的报文处理方法的具体流程示意图；

图3为本申请实施例提供的一种报文处理装置的具体结构示意图；

图4为本申请实施例提供的一种基于网商银行的报文处理装置的具体结构 示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下结合附图，详细说明本申请各实施例提供的技术方案。

实施例1

为了解决现有技术中的业务系统受到报文乱序的影响而无法正常处理业务的问题，本申请实施例1提供一种报文处理方法，该方法的具体流程示意图如图1所示，包括下述步骤：

步骤11，接收业务变更报文。

为了理解业务变更报文的概念，以下对本申请实施例中涉及到的一些名词进行解释说明：

报文，网络中交换与传输的数据单元，即数据块。按照预定的传输协议对数据进行封装，可以得到报文。

业务，是指需要处理的事务，该事务比如可以是转账、计费或扣款等等。一般地，可以通过设备执行业务处理流程，来完成业务。其中，业务处理流程，包含至少一个业务处理步骤。若通过执行某业务处理流程，可以完成某业务，则可以将该业务处理流程称为该业务对应的业务处理流程。

业务报文，包括用于触发设备执行业务处理流程的报文，以及参与业务处理流程的设备在业务处理流程中交互的报文。若某业务报文是用于触发设备执行某业务处理流程的报文，或者，该业务报文是参与业务处理流程的设备在该 业务处理流程中交互的报文，则可以将该业务称为该业务报文对应的业务，并且，将该业务处理流程称为该业务报文对应的业务处理流程。

业务变更报文，是指用于对业务报文所对应的业务进行更改或者撤销等操作的报文。本申请实施例中，若某业务变更报文，是为了更改(或者撤销等)某业务报文对应的业务发出的，则可以称该业务变更报文对应于该业务报文。

步骤12，判断业务系统是否已接收到业务变更报文对应的业务报文。

判断结果为是时，执行步骤13，判断结果为否时，执行步骤14。

本申请实施例中，可以根据判断业务系统针对所述业务报文对应的业务处理流程的处理状态，来确定业务系统是否已接收到业务变更报文对应的业务报文。

其中，上述业务系统针对所述业务报文对应的业务处理流程的处理状态包括下述三种处理状态：

1、业务系统已接收到所述业务报文但未开始执行所述业务报文对应的业务处理流程；

2、业务系统已经开始执行所述业务报文对应的业务处理流程但未处理完毕；

3、业务系统已经执行完毕所述业务报文对应的业务处理流程。

若判断出业务系统针对所述业务报文对应的业务处理流程的处理状态是上述三种处理状态中的任意一种，那么便可判定业务系统已接收到业务变更报文对应的业务报文。

那么，若要判断业务系统针对所述业务报文对应的业务处理流程的处理状态是否是业务系统已接收到所述业务报文但未开始执行所述业务报文对应的业务处理流程，可采用下述两种方法进行判断：

方法1，判断是否已接收到业务系统发出的业务报文接收通知且业务系统是否产生业务流水记录，若已接收到业务系统发出的业务报文接收通知且业务系统未产生业务流水记录，则判定业务系统针对所述业务报文对应的业务处理 流程的处理状态是业务系统已接收到所述业务报文但未开始执行所述业务报文对应的业务处理流程。

其中，所述业务报文接收通知，用于表示业务系统已经接收到业务报文。

所述业务流水记录，是用于表示业务系统执行业务报文对应的业务处理流程的过程的记录。一般业务系统会将该业务流水记录会存储在业务系统的数据库中。

其中，接收到业务系统发出的业务报文接收通知后，会将上述业务报文接收通知存储在本申请实施例的执行主体的数据库(下文称本地数据库)中。一般可以通过在本地数据库中查找上述业务报文接收通知，来判断是否已接收到业务系统发出的业务报文接收通知。若在上述本地数据库中查找到上述业务报文接收通知，则判定已接收到上述业务报文通知，若在上述本地数据库中查找不到上述业务报文接收通知，则判定未接收到上述业务报文通知。

另外，判断业务系统是否产生业务流水记录，可以由第三方系统或应用，在业务系统的数据库中查找上述业务流水记录来判断，若在业务系统的数据库中查找到上述业务流水记录，则可以判断出业务系统已产生业务流水记录，若在业务系统的数据库中查找不到上述业务流水记录，则可以判定业务系统未产生业务流水记录。上述第三方系统或应用可将上述判断结果发送给本申请实施例的执行主体，那么本申请实施例的执行主体则可判断业务系统是否产生业务流水记录。

方法2，判断业务系统是否已发出业务报文接收通知且业务系统是否产生业务流水记录，若业务系统已发出业务报文接收通知且业务系统未产生业务流水记录，则判定业务系统针对所述业务报文对应的业务处理流程的处理状态是业务系统已接收到所述业务报文但未开始执行所述业务报文对应的业务处理流程。

其中，业务系统发出业务报文接收通知后，业务系统会将发出业务报文接收通知这一事件，记录在业务系统的数据库中。记录该事件的文件名为“第一 事件记录”。第一事件记录包括业务系统发出业务报文接收通知的时间，以及发出的业务报文接收通知对应的业务报文的标识等信息。判断业务系统是否已发出业务报文接收通知的方法与方法1中判断业务系统是否产生业务流水记录的方法相似，此处不再进行赘述。

若要判断业务系统针对所述业务报文对应的业务处理流程的处理状态是否是业务系统已经开始执行所述业务报文的业务处理流程但未执行完毕，可采用下述两种方法进行判断：

方法3，判断业务系统是否产生业务流水记录且是否已接收到业务系统发出的业务报文回执，若业务系统产生业务流水记录且未接收到业务系统发出的业务报文回执，则判定业务系统针对所述业务报文对应的业务处理流程的处理状态是业务系统已经开始执行所述业务报文的业务处理流程但未执行完毕。

其中，所述业务报文回执，用于表示业务系统已执行完毕所述业务处理流程。接收到上述业务报文回执后，会将上述业务报文回执存储在本申请实施例的执行主体的数据库(下文称本地数据库)中。一般可以通过在本地数据库中查找上述业务报文回执的方式，来判断是否已接收到业务系统发出的业务报文回执。若在上述本地数据库中查找到上述业务报文回执，则判定已接收到上述业务报文回执，若在上述本地数据库中查找不到上述业务报文接收通知，则判定未接收到上述业务报文回执。

方法4，判断业务系统是否产生业务流水记录且业务系统是否已发出业务报文回执，若业务系统产生业务流水记录且业务系统未发出业务报文回执，则判定业务系统针对所述业务报文对应的业务处理流程的处理状态是业务系统已经开始执行所述业务报文的业务处理流程但未执行完毕。

其中，业务系统在发出业务报文回执后，业务系统会将发出业务报文回执这一事件，记录在业务系统的数据库中。记录该事件的文件名为“第二事件记录”。第二事件记录包括业务系统发出业务报文回执的时间，以及发出的业务报文回执对应的业务报文的标识等信息。判断业务系统是否已发出业务报文回 执的方法，与方法1中判断业务系统是否已发出业务报文接收通知的方法类似，此处不再进行赘述。

若要判断业务系统针对所述业务报文对应的业务处理流程的处理状态是否是业务系统已经执行完毕所述业务报文对应的业务处理流程时，可采用下述两种方法进行判断：

方法5，判断是否接收到业务报文回执，若接收到业务报文回执，则判定业务系统针对所述业务报文对应的业务处理流程的处理状态是业务系统已经执行完毕所述业务处理流程。

方法6，判断业务系统是否已经发出业务报文回执，若业务系统已发出所述回执，则判定业务系统针对所述业务报文对应的业务处理流程的处理状态是业务系统已经执行完毕所述业务处理流程。

需要说明的是，以步骤12的执行主体为服务器为例，在实际应用中，可能会出现服务器虽然接收到待转发给业务系统的业务变更报文，但却没有接收到该业务变更报文对应的业务报文的情况。在这样的情况下，由于业务系统肯定没有接收到服务器转发的业务报文，进而也就不可能执行完毕该业务报文对应的业务处理流程，因此服务器在向业务系统发送该业务变更报文前，若直接执行步骤12所述的该判断，其实是耗费了不必要的处理资源。为避免该问题，本申请实施例中，可以先判断服务器是否已接收到业务变更报文对应的业务报文；若服务器已接收到所述业务报文，则判断业务系统是否已接收到业务变更报文对应的业务报文，若服务器未接收到所述业务报文，则不判断业务系统是否已接收到业务变更报文对应的业务报文。这样做，可以使得在判断出服务器未接收到所述业务报文后，不判断业务系统是否已接收到业务变更报文对应的业务报文，不进行无意义操作，以免资源的无谓浪费。

步骤13，向业务系统发送所述业务变更报文。

步骤14，判断针对同一业务报文执行步骤12的次数是否达到预设次数阈值。

若判断结果为是，则执行步骤15；若判断结果为否，则继续执行步骤12。

那么下面对如何判断针对同一业务报文执行步骤12的次数是否达到预设次数阈值，进行介绍：

在实际应用中，在每次执行完毕步骤12后，将执行步骤12的事件信息记录保存在本地数据库中。通过在本地数据库中查找上述事件信息记录，便可确定出针对同一业务报文执行步骤12的次数，进而判断出针对同一业务报文执行步骤12的次数是否达到预设次数阈值。

其中，上述事件信息记录，包括执行步骤12的时间，执行步骤12的次数以及步骤12针对的业务报文的标识等信息。

步骤15，拒绝向业务系统发送所述业务变更报文。

其中，拒绝向业务系统发送所述业务变更报文的实现方式可以包括：将业务变更报文一直保持为中间状态，比如可以通过将业务变更报文中包含的、用以表示报文状态的标识设置为to_process，达到将该业务变更报文保持为中间状态的目的。其中，该中间状态，表明该业务变更报文暂时不能发送给业务系统，从而根据该状态，步骤15的执行主体不会发送该业务变更报文给业务系统。

采用本申请实施例1提供的方法，由于是在业务系统接收到业务变更报文对应的业务报文后，才向业务系统发送业务变更报文，从而可以保证业务报文和业务变更报文在到达业务系统时不会出现乱序的情况，这样，业务系统便不会受到报文乱序的影响，可以正常处理业务。

实施例2

本申请实施例2提供一种涉及借贷记业务报文和撤销通用处理确认报文的报文处理方法，用以具体说明本申请实施例1提供的方法在实际中的应用流程。

本申请实施例2涉及到的一些系统主要包括：网商银行、金融网络系统、业务系统、网银中心。以下先对该些系统进行简单介绍。

1、网商银行

网商银行是中国第一家将核心系统架构在金融云上的银行。基于金融云计算平台研发的银行核心系统，让网商银行拥有处理高并发金融交易、海量大数据和弹性扩容的能力，利用互联网和大数据的优势，给更多小微企业提供金融服务。

2、金融网络系统

金融网络系统是指网商银行负责报文的交换、适配，连接网商业务系统与中国人民银行大小额、网银中心等各个渠道的系统集合。按系统职能不同，可以将金融网络系统包含的子系统分为9个，这9个子系统相互配合并又各司其职。下文将重点介绍9个子系统中的金融交换系统和一致性恢复系统，由于9个子系统中的其他子系统与本申请实施例的关联性较小，因此本说明书中不再做介绍。

其中，上述中国人民银行大小额，又叫做大小额支付系统，指大额支付系统和小额支付系统。其中前者指中国人民银行现代化支付系统的接入系统，是以电子方式实时全额处理跨行及跨区支付业务的应用系统，大额支付系统指令逐笔实时发送，全额清算资金；后者是中国人民银行现代化支付系统的重要组成部分，主要处理跨行同城、异城纸质凭证截留的借记支付业务以及金额在规定起点以下的小额贷记支付业务(目前人行暂定为5万元〈含〉限额以下)，实现不同地区、不同银行营业网点的资源共享。

下面对金融交换系统和一致性恢复系统进行简单介绍：

金融交换系统，主要负责金融网络系统与业务系统进行报文对接、修改报文状态以及执行业务变更报文对应的变更业务的变更操作等。

一致性恢复系统，主要负责提供指定规则配置，采集业务报文，并根据策略发起原业务的查询和重发等功能，并支持查询与重发的次数控制。

3、业务系统

业务系统，是指网商银行中的用于与金融网络系统进行报文对接以及对报文所对应的业务进行处理的系统。

其中，金融网络系统与业务系统同属于网商银行。

4、网银中心

网银中心，又叫做超级网银，是中国人民银行网银互联跨行支付清算系统，主要处理跨行同城、异地协议借记支付业务以及金额在规定起点以下的小额贷记支付业务，支付指令单笔实时发送，净额清算资金(与小额支付系统共用净借记限额)。其处理的主要业务类型包括网银贷记业务、网银借记业务、第三方贷记业务、账户跨行查询业务、授权支付协议签约解约管理业务、账户查询协议签约解约管理业务等。

在介绍本申请实施例2提供一种涉及借贷记业务报文和撤销通用处理确认报文的报文处理方法之前，首先对涉及借贷记业务报文的报文处理方法进行介绍。

通过先对涉及借贷记业务报文的报文处理方法进行介绍，再介绍涉及借贷记业务报文和撤销通用处理确认报文的报文处理方法，以使大家在清晰了解网商银行、金融网络系统、业务系统和网银中心处理借贷记报文的具体处理流程的基础上，更容易理解涉及借贷记业务报文和撤销通用处理确认报文的报文处理方法。

具体地，涉及借贷记业务报文的报文处理方法的具体流程示意图如图2a所示，包括下述步骤：

步骤21，对手行向网银中心发送业务报文。

其中，对手行包括除网商银行之外的任何一家或几家银行。

业务报文可以包括贷记业务报文或借记业务报文。

其中，贷记业务是指由客户通过付款行发起，通过网银跨行清算系统向收款方主动汇款的业务。贷记业务主要应用于网银转账汇兑和网银缴费等，客户可以通过网银跨行清算系统发起转账汇款业务，也可以通过网银跨行清算系统 完成有关费用的主动汇划缴纳。

借记业务是指由客户通过收款行发起的，通过网银跨行清算系统向付款方主动收款的业务。

下文以业务报文为借记业务报文为例，对如图2a所示的其他步骤进行说明。

步骤22，网银中心将接收到的业务报文(借记业务报文)发送给网商银行。

步骤23，网商银行发送借记业务报文回执给网银中心。

针对步骤23而言，具体地，网商银行在接收到借记业务报文后，网商银行(具体是网商银行包含的业务系统)会执行借记业务报文对应的借记业务处理流程，该流程执行完毕后，业务系统会发送借记业务报文回执给网商银行包含的金融网络系统，进而由金融网络系统将借记业务报文回执发送给网银中心，从而完成步骤23。

这里所说的借记业务报文回执，用于表示网商银行已执行完毕所述借记业务处理流程。其中，业务系统执行所述借记业务处理流程后得到的处理结果为下述两种结果之一：

同意执行对手行发起的借记业务；

拒绝执行对手行发起的借记业务。

由于处理结果由以上两种，因此，本申请实施例中所述的借记业务报文回执，可用于表示网商银行同意执行对手行发起的借记业务或拒绝执行对手行发起的借记业务。

步骤24，网银中心接收到网商银行发送的借记业务报文回执后，若该借记业务报文回执是用于表示网商银行同意执行对手行发起的借记业务，那么网银中心会进行轧差处理，轧差处理完毕后，执行步骤25和步骤26；若网银中心接收到的借记业务报文回执是用于表示网商银行拒绝执行对手行发起的借记业务，那么网银中心不会进行轧差处理，即借记业务失败，进而执行步骤25和步骤26。

所述轧差，是指网银中心将网商银行在中国人民银行头寸中的与借记业务所对应的相同金额的资金划给对手行。其中，所述头寸是指网商银行在中国人民银行所开账户中的资金。

步骤25，网银中心向网商银行发送借记业务处理完毕通知。

其中，所述借记业务处理完毕通知，具体是指轧差成功通知或业务失败通知。

若网银中心执行步骤24，进行了轧差处理，则会发送轧差成功通知给网商银行；若借记业务失败，则会发送业务失败通知给网商银行。

步骤26，网银中心向对手行发送借记业务处理完毕通知。

网银中心在执行完步骤24后，进行了轧差处理，则会发送轧差成功通知给对手行；若借记业务失败，则会发送业务失败通知给对手行。

需要说明的是，本申请实施例2并不对上述方法的步骤25和步骤26的执行先后顺序进行限制。比如，步骤25可以与步骤26同步执行，或者，步骤25可以在步骤26后执行。

以下进一步对上述步骤23中，网商银行处理借记业务报文的具体流程进行介绍。具体的，该流程包含如图2b中的步骤32～步骤36。为了清楚地展现该流程与图2a中相关步骤的关联，图2b中除包含该流程外，还包含与前文所述的步骤22、步骤24和步骤25一一对应的步骤31、步骤37和步骤38。

以下对图2b包括的各步骤进行详细介绍：

步骤31，网银中心将接收到的业务报文(借记业务报文)发送给网商银行。

需要说明的是，金融网络系统与业务系统是同属于网商银行的系统。步骤31相当于上述步骤22，网银中心将接收到的业务报文(借记业务报文)发送给网商银行，会首先发送给网商银行包含的金融网络系统。

步骤32，金融网络系统将借记业务报文发送给业务系统。

为便于后续对借记业务报文进行查询，金融网络系统在接收到借记业务报文后，可以将借记业务报文存储在本地数据库中。

步骤33，业务系统发送借记业务报文接收通知给金融网络系统。

业务系统接收到金融网络系统发送的借记业务报文后，为便于后续对借记业务报文进行查询，业务系统在接收到借记业务报文后，可以将借记业务报文存储在本地数据库中。

另外，业务系统会将借记业务报文接收通知发送给金融网络系统。该借记业务报文接收通知用于告知金融网络系统，已经接收到借记业务报文。

在执行完步骤33后，执行步骤34。

步骤34，业务系统执行借记业务报文对应的第一阶段借记业务处理流程，并在该流程执行完毕后，执行步骤35。

业务系统执行借记业务报文对应的借记业务处理流程包括第一阶段借记业务处理流程和第二阶段借记业务处理流程。

这里说的借记业务报文对应的第一阶段借记业务处理流程相当于上述步骤23中的借记业务报文对应的借记业务处理流程。另外，这里说的借记业务报文对应的第一阶段借记业务处理流程相当于申请实施例1中的业务报文对应的业务处理流程。

业务系统在发送借记业务报文接收通知给金融网络系统后，开始执行对借记业务报文对应的第一阶段借记业务处理流程。

需要说明的是，业务系统执行借记业务报文对应的第一阶段借记业务处理流程后，可能会得到两种处理结果。

一种结果为业务系统同意执行对手行发起的借记业务。

比如，假设该借记业务报文对应的借记金额为10万元人民币，若客户账的账户中的金额不小于借记金额，那么业务系统会从客户账中划走金额为10万元人民币的资金，并将该资金划入到内部户中。因此，客户账的账目金额会减少10万元人民币，内部户的账目金额会增加10万元人民币。此时，业务系统完成对借记业务报文的第一阶段业务处理流程。

另一种结果为拒绝执行对手行发起的借记业务。

比如，有时客户账的账户中的金额会小于借记金额，那么业务系统尝试从客户账中拿走金额为10万元人民币的资金，并将该资金划入到内部户中。但是由于客户账的账目中的金额不足，因此业务系统无法从客户账中划走金额为10万元人民币的资金，划入到内部户中。此时，业务系统完成对借记业务报文的第一阶段业务处理流程。

以下对前文提及的一些名词进行说明：

客户账是客户在网商银行开设的结算账户；内部户是网商银行内部虚拟的账户，是客户账与资金往来户的资金过渡账户，用于业务系统在执行业务报文对应的业务处理流程时，作为资金的过渡账户，在业务系统不执行业务报文对应的业务处理流程时，内部户的账户中没有资金；资金往来户是网商银行的内部账户，是网商银行与客户之间资金往来的账户，资金往来户中的账目金额代表网商银行特定业务的账目金额，除此之外，资金往来户还会记录自身与客户账之间的账目往来。

步骤35，业务系统发送借记业务报文回执给金融网络系统。

步骤36，金融网络系统发送借记业务报文回执给网银中心。

步骤37，网银中心接收到金融网络系统发送的借记业务报文回执后，若该借记业务报文回执是用于表示网商银行同意执行对手行发起的借记业务，那么网银中心会进行轧差处理，轧差处理完毕后，执行步骤38；若网银中心接收到的借记业务报文回执是用于表示网商银行拒绝执行对手行发起的借记业务，那么网银中心不会进行轧差处理，即借记业务失败，进而执行步骤38。

步骤38，网银中心发送借记业务处理完毕通知给金融网络系统。

步骤39，金融网络系统将借记业务处理完毕通知发送给业务系统。

需要说明的是，当执行完步骤34后，业务系统会一直处于借记业务处理状态中，会一直等待借记业务处理完毕通知。若等待时间未超过预设等待时间阈值便接收到通过执行步骤39发送的借记业务处理完毕通知，则可以执行步骤310。若等待时间超过预设等待时间阈值仍未接收到借记业务处理完毕通知， 则业务系统会直接将借记业务置失败，即不再等待借记业务处理完毕通知到来，不再一直处于借记业务处理状态中，结束借记业务报文对应的借记业务处理流程。

这种情况下，若业务系统中的客户账、内部户和资金往来户之间已经产生资金转移，则可以通过人工介入的方式解决已经产生的资金转移。

步骤310，业务系统执行借记业务报文对应的第二阶段借记业务处理流程。

所述业务处理完毕通知包括轧差成功通知或业务失败通知。

业务系统接收到轧差成功通知或业务失败通知时，执行第二阶段业务处理流程的具体操作方式不同。

当业务系统接收到轧差成功通知时：

业务系统会将内部户中的10万元人民币的资金划入到资金往来户中，此时，业务系统完成对借记业务报文的第二阶段业务处理流程。

当业务系统接收到业务失败通知时：

业务系统不会进行其他操作，此时，业务系统完成对借记业务报文的第二阶段业务处理流程。通过上文介绍的只涉及借贷记业务报文的报文处理方法，可以清晰了解网商银行、金融网络系统、业务系统和网银中心处理借贷记业务报文的具体流程。

在这个基础上，我们再进一步介绍本申请实施例2提供的该涉及借贷记业务报文和撤销通用处理确认报文的报文处理方法。

其中，所述撤销通用处理确认报文，是用于撤销借贷记业务的报文。

那么，以撤销通用处理确认报文为撤销通用处理确认报文a为例，涉及借贷记业务报文和撤销通用处理确认报文的报文处理方法的具体实现流程如图2c所示，包括下述步骤：

步骤401，对手行发送借贷记业务报文给网银中心，以使得网银中心将该借记业务报文发送给金融网络系统。

为便于描述业务系统执行借贷记报文对应的借贷记业务处理流程，下文继 续沿用上述步骤21中的列举的借记业务报文为例进行说明。

步骤402，对手行发送撤销通用处理确认报文给网银中心，以使得网银中心将该撤销通用处理确认报文发送给金融网络系统。

对手行在发出借记业务报文后，针对该借记业务发起撤销，并将对应于借记业务报文的该撤销通用处理确认报文a发送给网银中心。

一般情况下，金融网络系统应先接收到借记业务报文，再接收到撤销通用处理确认报文a。

但是，由于本申请实施例，在进行报文传输时，采用异步传输方式，在网络发生抖动的情况下，可能会导致金融网络系统接收借记业务报文和撤销通用处理确认报文a时，产生乱序情况。

上述乱序情况包括但不限于下述其中一种：

同时接收到借贷记业务报文和撤销通用处理确认报文a；

先接收到撤销通用处理确认报文a后接收到借贷记业务报文；

只接收到撤销通用处理确认报文a，借贷记业务报文丢失。

由于针对不同的乱序情况，本申请实施例均会采用类似的方案来保证业务系统不会受到报文乱序的影响，因此，为便于描述，本申请实施例2以先接收到撤销通用处理确认报文a后接收到借贷记业务报文这一情况为例，对该方案进行说明。

步骤403，金融网络系统接收网银中心发送的撤销通用处理确认报文a。

为了便于后续查询撤销通用处理确认报文a，金融网络系统会将接收到的撤销通用处理确认报文a存储在本地数据库中。由于本申请实施例2中以先接收到撤销通用处理确认报文a后接收到借贷记业务报文这一情况为例，因此，在执行完步骤403后，执行步骤404。

步骤404，金融网络系统接收网银中心发送的借记业务报文。

该借记业务报文是步骤403中所述的撤销通用处理确认报文a对应的业务报文。

为了便于后续查询借记业务报文，金融网络可以将接收到的借记业务报文存储在本地数据库中。

步骤405，金融网络系统发送借记业务报文给业务系统。

针对先接收到撤销通用处理确认报文a后接收到借贷记业务报文这一乱序情况，可以事先对金融网络系统进行设定，使金融网络系统在执行步骤403和步骤404后，只发送借记业务报文给业务系统。

步骤406，金融网络系统包含的称为“金融交换系统”的子系统在向业务系统发送撤销通用处理确认报文a前，判断业务系统是否已接收到撤销通用处理确认报文a对应的借记业务报文；若判断结果为是，则执行步骤407；若判断结果为否，则执行步骤409。

步骤406的具体实现流程可参见申请实施例1中的步骤12。其中，步骤406中的撤销通用处理确认报文a相当于申请实施例1中的业务变更报文，步骤406中的借记业务报文相当于申请实施例1中的业务报文。

另外，根据本申请实施例2中的步骤34可知，借记业务报文对应的第一阶段借记业务处理流程相当于申请实施例1中的业务报文对应的业务处理流程。

那么，此处不再对如何判断业务系统是否已接收到撤销通用处理确认报文a对应的借记业务报文进行赘述。

步骤407，金融网络系统发送撤销通用处理确认报文a给业务系统。

执行完步骤407后，执行步骤408。

步骤408，业务系统执行撤销通用处理确认报文a对应的撤销流程。

当业务系统已接收到借记业务报文，但未开始执行所述借记业务报文对应的第一阶段借记业务处理流程，或业务系统已接收到借记业务报文并开始执行所述借记业务报文对应的第一阶段借记业务处理流程但未执行完毕时，业务系统的具体操作步骤如下：

业务系统收到金融网络系统发送的撤销通用处理确认报文a，会暂时忽略 撤销通用处理确认报文a，继续执行借记业务报文对应的第一阶段借记处理流程，直至执行完毕借记业务报文对应的第一阶段借记处理流程，业务系统再执行撤销通用处理确认报文a对应的撤销流程。

当业务系统已接收到借记业务报文并已经执行完毕所述借记业务报文对应的第一阶段借记业务处理流程时，业务系统的具体操作步骤如下：

业务系统收到金融网络系统发送的撤销通用处理确认报文a，会立即执行撤销通用处理确认报文a对应的撤销流程。

业务系统完成对借记业务报文的第一阶段业务处理流程后可能会得到两种结果：

结果一：

业务系统将客户账中金额为10万元人民币的资金划入内部户，同意执行对手行发起的借记业务。

结果二：

业务系统不将客户账中金额为10万元人民币的资金划入内部户，拒绝执行对手行发起的借记业务。

业务系统针对上述这两种结果，执行撤销通用处理确认报文a对应的撤销流程的具体操作实现方式不同。

那么，针对结果一，业务系统执行撤销通用处理确认报文a对应的撤销流程具体包括：通过将内部户中金额为10万元人民币的资金划入所述客户账中，从而完成撤销处理流程，也即完成对借记业务报文的第二阶段业务处理流程。

针对结果二，业务系统执行撤销通用处理确认报文a对应的撤销流程具体包括：不进行内部户与客户账之间的资金转移，从而完成撤销处理流程，也即完成对借记业务报文的第二阶段业务处理流程。

步骤409，一致性恢复系统采集中间状态的撤销通用处理确认报文。

一致性恢复系统采集中间状态的撤销通用处理确认报文撤销通用处理确认报文，是指一致性恢复系统通过查询金融网络系统的数据库中的各撤销通用 处理确认报文撤销通用处理确认报文的保存报文状态信息的关键信息段(后称第一关键信息段)，确定当前处于中间状态的撤销通用处理确认报文撤销通用处理确认报文。确定出的当前处于中间状态的撤销通用处理确认报文撤销通用处理确认报文，即为采集到的中间状态的撤销通用处理确认报文撤销通用处理确认报文。

具体而言，若查询到包含“to_process”这一报文状态信息的第一关键信息段，则可以确定该第一关键信息段所属的撤销通用处理确认报文撤销通用处理确认报文，是中间状态的撤销通用处理确认报文撤销通用处理确认报文。

本申请实施例中，一致性恢复系统可以采用周期性采集的方式，定期采集指定时间段内的中间状态的撤销通用处理确认报文撤销通用处理确认报文。比如，可以按每小时采集一次的方式，采集在当前采样周期到来前的一段时间内被保存至金融网络的数据库中的中间状态的撤销通用处理确认报文撤销通用处理确认报文。

需要说明的是，金融网络系统接收到撤销通用处理确认报文撤销通用处理确认报文时，撤销通用处理确认报文撤销通用处理确认报文状态是to_process。而后，金融网络系统会将撤销通用处理确认报文撤销通用处理确认报文保存到所述数据库中，并将撤销通用处理确认报文撤销通用处理确认报文的状态保持为to_process，以表明该撤销通用处理确认报文撤销通用处理确认报文等待被发送给业务系统。后续，当金融网络系统向业务系统发送撤销通用处理确认报文撤销通用处理确认报文时，会先将撤销通用处理确认报文撤销通用处理确认报文状态更改为processed，然后再进行发送。

基于金融网络系统对于撤销通用处理确认报文撤销通用处理确认报文状态的上述处理机制，一致性恢复系统通过采集中间状态的撤销通用处理确认报文撤销通用处理确认报文，可以确定当前还未发送给业务系统的撤销通用处理确认报文撤销通用处理确认报文。下文以采集到的该中间状态的撤销通用处理确认报文撤销通用处理确认报文为撤销通用处理确认报文撤销通用处理确认 报文a为例，进行介绍。

报文在传输过程中，会不断的封装成分组、包、帧来传输，其中封装的方式就是添加一些信息段。该信息段可以包括报文被传输的原地址、目的地址、达到原地址时间以及存储在数据库的时间等。报文每经过一次传输，便会添加一些信息段，导致报文包含的信息越来越多。由此可知，中间状态的撤销通用处理确认报文撤销通用处理确认报文经过多次传输后，包含的信息段会比较多。本申请实施例中，视实际需求，可以从已采集的中间状态的撤销通用处理确认报文撤销通用处理确认报文包含的信息段中，获取除报文状态信息外的其他信息。

比如，由于在一致性恢复系统采集到中间状态的撤销通用处理确认报文撤销通用处理确认报文a后，后续可能会将针对采集到的撤销通用处理确认报文撤销通用处理确认报文a的补偿通知发送给金融交换系统。该补偿通知中，一般会包括一致性恢复系统采集到的中间状态的撤销通用处理确认报文撤销通用处理确认报文a的标识，以使得金融交换系统获知当前是撤销通用处理确认报文撤销通用处理确认报文a处于中间状态。因此，一致性恢复系统可以获取撤销通用处理确认报文撤销通用处理确认报文a包含的某关键信息段(后称第二关键信息段)中的撤销通用处理确认报文撤销通用处理确认报文a的标识。

又比如，除了可以获取上述第一、第二关键信息段外，一致性恢复系统还可以获取用于保存报文类型标识(如撤销通用处理确认报文撤销通用处理确认报文a的类型标识为“x”)的字段，并携带在所述补偿通知中发送给金融交换系统，以便金融交换系统获知处于中间状态的报文的类型。

步骤410，一致性恢复系统判断针对撤销通用处理确认报文撤销通用处理确认报文a的补偿次数是否达到预设次数阈值；若判断结果为否，则执行步骤411；若判断结果为是，则执行步骤412；

针对撤销通用处理确认报文撤销通用处理确认报文a的补偿次数，是指一致性恢复系统重复向金融交换系统发送针对该撤销通用处理确认报文撤销通 用处理确认报文a生成的补偿通知的次数。其中，针对该撤销通用处理确认报文撤销通用处理确认报文a生成的补偿通知，用于告知金融交换系统，有中间状态的撤销通用处理确认报文a需要被处理。

步骤411，一致性恢复系统将针对采集到的中间状态的撤销通用处理确认报文a生成的补偿通知(该通知中会包含撤销通用处理确认报文a的标识)，发送给金融交换系统，以触发金融交换系统在向业务系统发送撤销通用处理确认报文a前，判断业务系统是否已接收到撤销通用处理确认报文a对应的借记业务报文；若判断结果为是，则执行步骤407；若判断结果为否，则执行步骤410。

其中，所述补偿通知，可以是一致性恢复系统生成的。

步骤412，金融网络系统拒绝发送撤销通用处理确认报文a给业务系统。

具体而言，金融网络系统将一直保持撤销通用处理确认报文a为中间状态。

步骤412执行完毕后，执行步骤413。

步骤413，业务系统置借记业务失败，从而结束借记业务报文对应的借记业务处理流程。

采用本申请实施例2提供的方法，由于是在业务系统接收到业务变更报文对应的业务报文后，才向业务系统发送业务变更报文，从而可以保证业务报文和业务变更报文在到达业务系统时不会出现乱序的情况，这样，业务系统便不会受到报文乱序的影响，可以正常处理业务。

实施例3

出于与实施例1相同的发明构思，本申请实施例3提供一种报文处理装置，该装置的具体结构示意图如图3所示，包括下述模块：

接收模块51，用于接收业务变更报文。

第一业务判断模块52，用于判断业务系统是否已接收到业务变更报文对应 的业务报文；判断结果为是时，触发发送模块；判断结果为否时，触发第一业务判断模块。

发送模块53，用于向业务系统发送所述业务变更报文。

在一种实施方式中，第一业务判断模块52，具体用于：

判断业务系统针对所述业务报文对应的业务处理流程的处理状态，以便根据所述处理状态确定业务系统是否已接收到业务变更报文对应的业务报文。

当所述处理状态为业务系统已接收到上述业务报文但未开始执行所述业务报文对应的业务处理流程时，所述第一业务判断模块52，具体用于：

判断是否已接收到业务系统发出的业务报文接收通知且业务系统是否产生业务流水记录，若已接收到业务系统发出的业务报文接收通知且业务系统未产生业务流水记录，则判定业务系统已接收到上述业务报文但未开始执行所述业务报文对应的业务处理流程，进而可以判定业务系统已接收到业务变更报文对应的业务报文；

或，判断业务系统是否已发出业务报文接收通知且业务系统是否产生业务流水记录，若业务系统已发出业务报文接收通知且业务系统未产生业务流水记录，则判定业务系统已接收到上述业务报文但未开始执行所述业务报文对应的业务处理流程，进而可以判定业务系统已接收到业务变更报文对应的业务报文；

或，当所述处理状态为业务系统已经开始执行所述业务报文的业务处理流程但未执行完毕时，所述第一业务判断模块52，具体用于：

判断业务系统是否产生业务流水记录且是否已接收到业务系统发出的业务报文回执，若业务系统产生业务流水记录且未接收到业务系统发出的业务报文回执，则判定业务系统已经开始执行所述业务报文的业务处理流程但未执行完毕，进而判定业务系统已接收到业务变更报文对应的业务报文；

或，判断业务系统是否产生业务流水记录且业务系统是否已发出业务报文回执，若业务系统产生业务流水记录且业务系统未发出业务报文回执，则判定 业务系统已经开始执行所述业务报文的业务处理流程但未执行完毕，进而判定业务系统已接收到业务变更报文对应的业务报文；

或，当所述处理状态为业务系统已经执行完毕所述业务报文对应的业务处理流程时，所述第一业务判断模块52，具体用于：

判断是否接收到业务报文回执，若接收到业务报文回执，则判定业务系统已经执行完毕所述业务处理流程，进而判定业务系统已接收到业务变更报文对应的业务报文；

或，判断业务系统是否已经发出业务报文回执，若业务系统已发出所述回执，则判定业务系统已经执行完毕所述业务处理流程，进而判定业务系统已接收到业务变更报文对应的业务报文；

其中，所述业务报文接收通知，用于表示业务系统已经接收到业务报文；

所述业务流水记录，用于表示业务系统执行业务报文对应的业务处理流程的过程的记录；

所述业务报文回执，用于表示业务系统已执行完毕所述业务处理流程。

在一种实施方式中，所述装置还包括：

第二业务判断模块，用于第一业务判断模块52判断业务系统是否已接收到业务变更报文对应的业务报文之前，判断是否已接收到业务变更报文对应的业务报文。

次数确定模块，用于确定第一业务判断模块52确定执行判断业务系统是否已接收到业务变更报文对应的业务报文的步骤的次数。

第三业务判断模块，用于判断所述次数确定模块55确定的次数是否达到预设次数阈值且第一业务判断模块52得到的最后一次的判断结果是否仍未否；如果是，不触发第一业务判断模块52和发送模块53。

采用本申请实施例3提供的方法，由于是在业务系统接收到业务变更报文对应的业务报文后，才向业务系统发送业务变更报文，从而可以保证业务报文和业务变更报文在到达业务系统时不会出现乱序的情况，这样，业务系统便不 会受到报文乱序的影响，可以正常处理业务。

实施例4

出于与实施例1相同的发明构思，本申请实施例4提供一种基于网商银行的报文处理装置，其特征在于，所述网商银行包括：业务系统以及连接网银中心与业务系统的金融网络系统，所述装置的具体结构示意图如图4所示，包括下述模块：

金融网络接收模块61，用于接收网银中心发送的撤销通用处理确认报文。

第一金融网络业务判断模块62，用于判断业务系统是否已接收到撤销通用处理确认报文对应的业务报文；判断结果为是时，触发金融网络发送模块；判断结果为否时，触发第一金融网络业务判断模块62。

金融网络发送模块63，用于向业务系统发送所述撤销通用处理确认报文。

其中，所述撤销通用处理确认报文，是用于撤销借贷记业务的报文。

另外，所述撤销通用处理确认报文，由不同于网商银行的其他银行发送给网银中心，再由网银中心发送给网商银行包含的金融网络系统，最终由网商银行包含的上述金融网络系统发送给网商银行包含的业务系统。

第一金融网络业务判断模块62，具体用于：

判断业务系统针对所述借贷记业务报文对应的借贷记业务处理流程的处理状态，以便根据所述处理状态确定业务系统是否已接收到撤销通用处理确认报文对应的借贷记业务报文。

在一种实施方式中，所述装置还可以包括：

第二金融网络业务判断模块，用于第一金融网络业务判断模块62判断业务系统是否已接收到撤销通用处理确认报文对应的借贷记业务报文之前，判断金融网络系统是否接收到撤销通用处理确认报文对应的借贷记业务报文；若金融网络系统接收到所述借贷记业务报文，则触发第一金融网络业务判断模块62；若金融网络系统未接收到所述借贷记业务报文，则不触发第一金融网络业 务判断模块62。

金融网络次数确认模块，用于确定第一金融网络业务判断模块62执行判断业务系统是否已接收到撤销通用处理确认报文对应的借贷记业务报文的步骤的次数；

第三金融网络业务判断模块，用于判断所述金融网络次数确定模块确定的次数是否达到预设次数阈值且第一金融网络业务判断模块62得到的最后一次的判断结果是否仍为否；如果是，不触发第一金融网络业务判断模块62和金融网络发送模块63。

采用本申请实施例4提供的方法，由于是在业务系统接收到业务变更报文对应的业务报文后，才向业务系统发送业务变更报文，从而可以保证业务报文和业务变更报文在到达业务系统时不会出现乱序的情况，这样，业务系统便不会受到报文乱序的影响，可以正常处理业务。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中 的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

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