CN112311838A - 业务异步交互方法及装置 - Google Patents

Abstract

本申请公开了业务异步交互方法及装置，第一服务器将业务处理请求包发送至第二服务器进行相应的处理。第一服务器不断查询第二服务器是否生成新的处理结果以实现异步获得已发送的业务处理请求包的处理结果，例如，中间处理结果，第一服务器获得这些异步获得的中间处理结果后，只更新业务的中间状态。在第一服务器异步获得第二服务器完全处理完成得到的最终处理结果后，才依据最终处理结果更新业务的最终状态，如业务处理成功或业务处理失败。利用该方法使第一服务器能够异步获取第二服务器的处理结果，即实现第一服务器异步多次与第二服务器之间进行交互。

Description

业务异步交互方法及装置

技术领域

本申请涉及业务处理技术领域，尤其涉及业务异步交互方法及装置。

背景技术

通常很多情况下都需要两个服务器之间进行交互，例如，服务器一向服务器二发送业务处理请求，服务器二接收到该业务处理请求后进行相应的处理，并向服务器二返回相应的处理结果。

传统的交互过程，发送请求的服务器只支持同步获取结果，所谓同步获取结果是指在一次接口调用时，需要对方及时进行相应的处理并返回相应的处理结果。而实际应用中，响应请求的服务器很可能无法实时处理请求并返回相应的处理结果，而是通过多步处理后才能返回最终的处理结果。但相关技术中发送请求的服务器无法与响应请求的服务器进行多次异步交互。

发明内容

有鉴于此，本申请提供了业务异步交互方法及装置，以解决发送请求的服务器无法与响应请求的服务器之间进行多次异步交互的技术问题。

为实现上述目的，一方面，本申请提供了一种业务异步交互方法，包括：

向目标服务器发送针对目标业务的业务处理请求包，所述业务处理请求包用于使所述目标服务器进行相应的业务处理；

获取所述目标服务器响应所述业务处理请求包所产生的中间处理结果；

依据所述中间处理结果更新所述目标业务的中间业务状态；

获取所述目标服务器响应所述业务处理请求包所产生的最终处理结果；

依据所述最终处理结果更新所述目标业务的最终业务状态。

在一种可能的实现方式中，所述业务处理请求包中包括至少两个具有相同业务属性的业务处理请求。

在一种可能的实现方式中，所述依据所述中间处理结果更新所述目标业务的中间业务状态，包括：

解析所述中间处理结果获得所述业务处理请求包对应的中间处理状态；

依据中间处理状态与中间业务状态之间的映射关系，将所述目标业务的状态更新为与解析得到的中间业务状态相对应的中间业务状态。

在一种可能的实现方式中，所述依据所述中间结果更新所述目标业务的中间业务状态，包括：

解析获得的第一中间处理结果，得到所述目标服务器对所述业务处理请求包进行格式校验的文件校验成功结果；

依据所述文件校验成功结果将所述目标业务的业务状态更新为文件已受理待处理；

解析获得的第一中间处理结果，得到所述目标服务器对所述业务处理请求包进行格式校验的文件校验失败结果；

依据所述文件校验失败结果将所述目标业务的业务状态更新为请求失败；

解析获得的第二中间处理结果，得到所述目标服务器对所述业务处理请求包内的业务处理请求进行校验的业务校验成功结果；

依据所述业务校验成功结果将所述目标业务的业务状态更新为业务已受理待回传处理结果；

解析获得的第二中间处理结果，得到所述目标服务器对所述业务处理请求包内的业务处理请求进行校验的业务校验失败结果；

依据所述业务校验失败结果将所述目标业务的业务状态更新为业务处理失败。

在一种可能的实现方式中，所述目标业务是付汇业务；

所述向目标服务器发送针对目标业务的业务处理请求包，包括：

检测到付汇请求包后，依据所述付汇请求包生成相应的付汇文件，所述付汇请求包内包括属性相同的至少两个付汇请求；

将所述付汇文件按照预设加密算法进行加密后得到加密后的付汇文件；

将加密后的付汇文件发送至目标服务器。

在一种可能的实现方式中，所述获取所述目标服务器响应所述业务处理请求包所产生的中间处理结果，包括：

解析所述付汇文件获得所述付汇文件对应的文件标识；

查询所述目标服务器中是否存在与所述文件标识相匹配的中间处理结果文件；

如果所述目标服务器中存在与所述文件标识相匹配的中间处理结果文件，则将与所述文件标识相匹配的中间处理结果文件拉取到本地。

在一种可能的实现方式中，所述依据所述中间处理结果更新所述目标业务的中间业务状态，包括：

解密拉取到本地的所述中间处理结果文件，得到解密后的中间处理结果文件；

解析解密后的中间处理结果文件得到所述付汇文件对应的中间处理状态；

依据中间处理状态与中间业务状态之间的映射关系，将所述付汇请求包的业务状态更新为与解析得到的中间业务状态。

在一种可能的实现方式中，所述依据中间处理状态与中间业务状态之间的映射关系，将所述付汇请求包的业务状态更新为与解析得到的中间业务状态，包括：

若解析解密后的中间处理结果文件得到所述付汇文件对应的第一中间处理结果文件，所述第一中间处理结果文件表明所述目标服务器已受理所述付汇文件；

将所述付汇请求包的业务状态更新为付汇请求包已受理且付汇请求待回导；

若解析解密后的中间处理结果文件得到所述付汇文件对应的第二中间处理结果文件，所述第二中间处理结果文件表明所述目标服务器已处理所述付汇请求包中的付汇请求；

将所述付汇请求包的业务状态更新为付汇请求已处理。

另一方面，本申请还提供了一种业务异步交互装置，包括：

请求发送模块，用于向目标服务器发送针对目标业务的业务处理请求包，所述业务处理请求包用于使所述目标服务器进行相应的业务处理；

中间结果获取模块，用于获取所述目标服务器响应所述业务处理请求包所产生的中间处理结果；

中间状态更新模块，用于依据所述中间处理结果更新所述目标业务的中间业务状态；

最终结果获取模块，用于获取所述目标服务器响应所述业务处理请求包所产生的最终处理结果；

最终状态更新模块，用于依据所述最终处理结果更新所述目标业务的最终业务状态。

又一方面，本申请还提供一种服务器，包括：

处理器和存储器；

其中，所述处理器用于执行所述存储器中存储的程序；

所述存储器用于存储程序，所述程序至少用于：

向目标服务器发送针对目标业务的业务处理请求包，所述业务处理请求包用于使所述目标服务器进行相应的业务处理；

获取所述目标服务器响应所述业务处理请求包所产生的中间处理结果；

依据所述中间处理结果更新所述目标业务的中间业务状态；

获取所述目标服务器响应所述业务处理请求包所产生的最终处理结果；

依据所述最终处理结果更新所述目标业务的最终业务状态。

再一方面，本申请还提供了一种存储介质，包括：所述存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器加载并执行时，实现上述任意一种可能的实现方式提供的业务异步交互方法。

本申请提供的业务异步交互方法，第一服务器将业务处理请求包发送至第二服务器进行相应的处理。第一服务器不断查询第二服务器是否生成新的处理结果以实现异步获得已发送的业务处理请求包的处理结果，例如，中间处理结果，第一服务器获得这些异步获得的中间处理结果后，只更新业务的中间状态。在第一服务器异步获得第二服务器完全处理完成得到的最终处理结果后，才依据最终处理结果更新业务的最终状态，如业务处理成功或业务处理失败。利用该方法使第一服务器能够异步获取第二服务器的处理结果，即实现第一服务器异步多次与第二服务器之间进行交互。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1示出了本申请提供的一种业务异步交互系统的交互示意图；

图2示出了本申请提供的一种业务异步交互方法的交互示意图；

图3示出了本申请提供的另一种业务异步交互方法的交互示意图；

图4示出了本申请提供的一种付汇系统的结构示意图；

图5示出了本申请提供的付汇业务的异步交互方法的交互示意图；

图6示出了本申请提供的一种业务异步交互装置的结构示意图；

图7示出了本申请提供的一种服务器的结构示意图。

具体实施方式

背景技术中已叙及，相关技术中的需要进行交互的两个服务器中的一个服务器只支持同步获取结果，而另一服务器无法实时返回处理结果，导致两个服务器之间的交互失败。为了解决这种矛盾，本申请提供了业务处理方法，发送请求的服务器接收到对方返回的中间处理结果，并针对中间处理结果相应修改业务状态，直到接收到对方返回的最终处理结果，根据最终处理结果更新业务的最终状态，从而使发送请求的服务器实现异步结果获取，以适应对方的异步处理方式。

为了便于理解本申请的业务异步交互方法，下面对于本申请的业务异步交互系统进行介绍。

请参见图1，示出了本申请实施例提供的一种业务异步交互系统的结构示意图，如图1所示，该系统可以包括终端11、第一服务器12和第二服务器13，其中，终端11与第一服务器12之间通过网络实现通信连接，同理，第一服务器12与第二服务器13之间通过网络实现通信连接。

其中，终端11可以是手机、平板电脑等移动终端。终端11上可以安装实现业务异步交互方法的客户端，该客户端可以是安装在终端11上的应用程序或web客户端。用户可以在客户端上进行相应的操作，客户端依据用户的操作生成业务处理请求，并发送至第一服务器12。

第一服务器12将该业务处理请求发送至第二服务器13，并由第二服务器13响应该业务处理请求进行相应的业务处理。

在一些应用场景下，第二服务器13需要对相应的业务进行至少两步处理后得到最终的业务处理结果。即第二服务器13无法及时得到响应所述业务请求的最终处理结果。为了适应此种应用场景下，第一服务器12能够针对第二服务器13返回的中间处理结果，进行相应的处理，即相应修改业务中间状态。当接收到第二服务器13返回的最终处理结果后才对应修改业务的最终状态。

下面将对第一服务器和第二服务器之间的交互过程进行详细介绍。

请参见图2，示出了本申请实施例提供的一种业务异步交互方法的交互示意图，如图2所示，该交互过程包括：

S110，终端生成业务处理请求并发送至第一服务器。

终端通过检测用户在客户端上的操作生成相应的业务处理请求，例如，客户端的显示界面上设置有不同的业务相关联的虚拟按键，用户可以操作虚拟按键进行相应的业务操作，客户端检测到用户对虚拟按键的操作生成相应的业务处理请求，并将该业务处理请求发送至第一服务器。

第一服务器是为终端提供业务处理服务的服务器，该第一服务器可以是独立的服务器，或者，也可以是多个分布式服务器构成的服务器集群。

业务处理请求用于请求第二服务器进行相应的业务处理。本文中的第二服务器即目标服务器。

S120，第一服务器接收终端发送的业务处理请求，生成业务处理请求包。

其中，该业务处理请求包中包括至少一个业务处理请求。

在一种应用场景下，第一服务器每接收到一个业务处理请求就生成一个业务处理请求包，即该业务处理请求包中包括一个业务处理请求。

在一种应用场景中，第一服务器接收到多个终端发送的多个业务处理请求，并根据业务属性，将业务属性相同的请求打包成一个包一起发送，即此种应用场景下一个业务处理请求包中包括多个业务处理请求。

S130，第一服务器将业务处理请求包发送至第二服务器。

第一服务器通过网络将生成的业务处理请求包发送至第二服务器进行处理。

S140，第二服务器响应该业务处理请求包生成中间处理结果。

在一种应用场景下，第二服务器可能会在很短时间段内接收到很多业务处理请求，因此，第二服务器不能实时响应该业务处理请求包。此种应用场景下，第二服务器通常分多步来处理业务，并向第一服务器返回中间处理结果。

例如，当接收到第一服务器发送的业务处理请求包后，初步检查后向第一服务器返回表示请求包已收到的中间处理结果；后续，第二服务器处理业务处理请求包中的请求后，还会向第一服务器返回表示业务已处理的中间处理结果。

S150，第一服务器从第二服务器中获取该业务处理请求包对应的中间处理结果，并依据该中间处理结果更新该业务处理请求包的中间业务状态。

第一服务器按照指定的时间间隔查询第二服务器中是否存在该业务处理请求包对应的中间处理结果，如果存在则将该中间处理结果拉取到本地，并解析该中间处理结果的内容。然后，再依据解析得到的中间结果的内容更新该业务处理请求包对应的中间业务状态。

其中，指定的时间间隔可以根据实际需求自行设定，本申请对此并不限定。

S160，第二服务器对业务处理请求包进行业务处理生成最终处理结果。

当第二服务器处理该业务处理请求包中的各个业务处理请求时，相应生成最终处理结果。

S170，第一服务器从第二服务器中获取该业务处理请求包对应的最终处理结果，并依据该最终处理结果更新该业务处理请求包对应的最终业务状态。

第一服务器查询第二服务器中是否存在该业务处理请求包对应的最终处理结果，如果存在则将该最终处理结果拉取到本地，并解析该最终处理结果的内容，最后，依据该最终处理结果的内容更新该业务处理请求包对应的最终业务状态。可选的，第一服务器将该业务处理请求包中各个业务处理请求的最终业务状态反馈给对应的终端。

本实施例提供的业务异步交互方法，第一服务器将业务处理请求包发送至第二服务器进行相应的处理。之后，第一服务器不断查询第二服务器生成新的处理结果以实现异步获得已发送业务处理请求包的处理结果。第一服务器获得这些异步返回的中间处理结果后，只更新业务的中间状态。在第一服务器异步获得第二服务器完全处理完成得到的最终处理结果后，才依据最终处理结果更新业务的最终状态，如业务处理成功或业务处理失败。利用该方法使第一服务器能够异步获取第二服务器的处理结果，即实现第一服务器异步多次与第二服务器之间进行交互。

请参见图3，示出了本申请提供的另一种业务异步交互方法的交互示意图。该方法以第二服务器分两次处理业务处理请求包为例进行说明。如图3所示，该方法可以包括如下步骤：

S210，终端生成业务处理请求并发送至第一服务器。

S220，第一服务器接收客户端发送的业务处理请求，生成业务处理请求包。

S230，第一服务器将业务处理请求包发送至第二服务器。

其中，S210～S230的实施过程分别与S110～S130中对应步骤的实施过程相同，此处不再赘述。

S240，第二服务器对该业务处理请求包进行校验，并生成该业务处理请求包对应的第一中间处理结果。

第二服务器对该业务处理请求包的文件格式进行校验，若校验正确，则生成校验成功结果；若校验失败，则生成校验失败结果。此处的第一中间处理结果即校验结果。

S250，第一服务器获取该业务处理请求包对应的第一中间处理结果。

第一服务器可以按照指定的时间间隔查询第二服务器是否生成该业务处理请求包对应的第一中间处理结果，如果是，则从第二服务器中拉取该业务处理请求包对应的第一中间处理结果并存储到本地。

在一种可能的实现方式中，第一服务器获取该业务处理请求包对应的唯一标识，并查询第二服务器中是否包含该唯一标识对应的第一中间处理结果。

S260，第一服务器根据该第一中间处理结果更新该业务处理请求包的中间业务状态。

第一服务器解析该第一中间处理结果，若该第一中间处理结果表明第二服务器对业务处理请求包校验成功的文件校验成功结果，则将该业务处理请求包的状态更新为文件已受理待处理，表示第二服务器已接收到该业务处理请求包，但还没有处理该业务处理请求包。

若该第一中间处理结果表明第二服务器对业务处理请求包校验失败的文件校验失败结果，则将该业务处理请求包的状态更新为请求失败。该请求失败的状态表示第二服务器未接收到该业务处理请求包。

S270，第二服务器对该业务处理请求包中的各个业务处理请求进行校验，生成第二中间处理结果。

如果在S240中第二服务器对业务处理请求包校验成功，则将该业务处理请求包放入待处理业务队列中，按照队列中的待处理业务的顺序进行处理，当对该业务处理请求包进行处理时，会对该业务处理请求包中的每个业务处理请求中的信息进行进一步校验，如果校验成功则生成校验成功的第二中间处理结果；如果校验失败，则生成校验失败的第二中间处理结果。

S280，第一服务器获取该业务处理请求包对应的第二中间处理结果。

第一服务器获取该业务处理请求包对应的第二中间处理结果的过程与拉取第一中间处理结果的过程相同，此处不再赘述。

S290，第一服务器依据该第二中间处理结果更新该业务处理请求包的中间业务状态。

如果第二中间处理结果表明第二服务器对业务处理请求包中的各个业务处理请求校验成功的业务校验成功结果，则将该业务处理请求包的业务状态更新为业务已受理待回传处理结果，表示第二服务器已经开始处理该业务处理请求包中的业务，但未得到最终的业务处理结果。

如果包中的业务处理请求校验失败的业务校验失败结果，则将业务状态更新为业务处理失败。

S2100，第二服务器处理业务处理请求包中的各个业务处理请求，并生成最终处理结果。

如果第二服务器对业务处理请求包中的业务处理请求校验成功，进一步处理该业务处理请求，并根据处理结果生成最终处理结果。

S2110，第一服务器获取该业务处理请求包对应的最终处理结果，根据该最终处理结果更新该业务处理请求包的最终业务状态。

第一服务器从第二服务器中获取最终处理结果，并解析该最终处理结果，若该最终处理结果为处理成功，则将对应业务的业务状态更新为业务处理成功；若该最终处理结果为处理失败，则将对应业务的业务状态更新为业务处理失败。

下面将详细介绍将该业务异步交互方法应用到付汇这一应用场景中的具体技术方案。在详细介绍付汇场景的具体技术方案之前，先介绍付汇场景下的专业术语。

付汇:一般是指进口企业在发生进口业务时,需要从其外汇账户上支付货款到境外的过程。

换汇平台：通常能够向用户提供用一种币种兑换另一种币种的功能，包括购汇、付汇等。

账务系统：换汇服务器的内部系统，主要是针对财务使用，包括购汇包、付汇包的审核、发起资金调拨请求、拒绝审核等功能。

付汇批处理：每天定时触发银行接口，进行回导付汇结果的功能，包括付汇打包、付汇包发往银行、付汇包回导账务、付汇包回导到核心四个功能，与账务系统紧密结合，在账务系统上可以看到各种明细的状态变化。

如图4所示，示出了本申请实施例提供的付汇系统的结构示意图，该付汇系统包括终端21、换汇服务器22和银行服务器23。

其中，终端21与换汇服务器22之间通过网络实现通信连接，且换汇服务器22与银行服务器23之间通过网络实现通信连接。

换汇服务器22主要用于接收终端21发起的付汇请求，将该付汇请求中的支付币种换算成目标币种，然后，基于目标币种生成新的付汇请求并发送至银行服务器23。

银行服务器23用于处理该付汇请求完成付汇操作。

下面将结合图5对换汇服务器与银行服务器之间的交互过程进行详细介绍。

如图5所示，基于付汇场景的业务异步交互方法包括以下步骤：

S310，终端生成付汇请求并发送至换汇服务器。

S320，换汇服务器接收终端发送的付汇请求并将业务属性相同的至少两个付汇请求打包成一个付汇包。

付汇包：把付汇业务属性相同的请求打包到一起生成一个付汇包，例如，付汇业务属性相同可以包括银行渠道相同、付汇类型相同、币种相同、汇率相同。

每一个付汇包有至少一笔付汇明细，包括银行名称、收款人、代理收款行、汇率、金额等字段；一个付汇包也有可能有多笔明细。

在一种应用场景下，换汇服务器只接收到一个终端发送的付汇请求，此时可以将这一个付汇请求打包成一个付汇包。

在另一种应用场景下，换汇服务器接收到多个终端发送的付汇请求，此种情况下，可以将付汇业务属性相同的付汇请求打包成一个付汇包。

生成的付汇包需要经过换汇服务器中的账务系统进行审核，审核通过后存储至数据库中，以便下一步发送至银行服务器。其中，账务系统主要用于审核付汇包中的基本信息是否准确。

S330，依据所述付汇包生成付汇文件。

由于银行服务器只能接收符合其格式标准的文件，所以需要将付汇包生成符合银行要求的格式标准的文件，即付汇文件。

换汇服务器检测到数据库中存在付汇包，且该付汇包的审核状态是审核通过。继续检测付汇包中是否有对应的付汇明细，如果有付汇明细则依据付汇明细生成相应的付汇文件。

S340，换汇服务器将付汇文件发送至银行服务器。

在一种应用场景下，为了提高传输的安全性，换汇服务器和银行服务器之间传输的文件都需要加密。即，换汇服务器生成付汇文件并对其进行加密后发送至银行服务器。

S350，银行服务器校验接收到的付汇文件的文件格式是否正确，并生成文件校验结果文件。

本实施例中，以银行服务器对付汇文件进行2次中间处理为例进行说明，两次中间处理分别是对付汇文件的文件格式进行校验，以及，对付汇文件中的付汇明细的校验。

在其它实施例中，银行服务器可能需要对付汇业务进行3次及以上次的中间处理才能进行最终的业务处理。

如果银行服务器对付汇文件的文件格式校验成功，则生成表示文件校验成功的文件校验结果文件，并将该付汇文件放入待处理的付汇队列中。

如果银行服务器对付汇文件的文件格式校验失败，则生成表示文件校验失败的文件校验文件。

在一种应用场景下，银行服务器可以包括文件服务器和结果服务器，银行服务器对付汇文件处理时生成的中间处理结果都存储到文件服务器中，生成的最终处理结果存储到结果服务器中。此种情况下，银行服务器生成的文件校验成功文件或文件校验失败文件进行加密后存储至文件服务器中。

在其他应用场景下，中间处理结果和最终处理结构也可以都存储到银行服务器中。

S360，换汇服务器从银行服务器中拉取该付汇文件对应的文件校验结果文件，并存储到换汇服务器本地。

换汇服务器按照指定时间间隔查询文件服务器中是否存在与该付汇文件相匹配的中间处理结果文件，如果存在，则下载至换汇服务器本地进行存储。

S370，换汇服务器解析获得的文件校验结果文件，如果解析结果表示文件校验成功，则执行S390；如果解析结果表示文件校验失败，则执行S3140。

换汇服务器先解密从银行服务器中下载的文件校验结果文件，然后解析解密后的文件校验结果文件得到相应的文件校验结果。

S380，银行服务器对付汇文件中的付汇明细进行校验，并生成明细校验结果文件。

银行服务器对付汇文件的文件格式校验成功后，则将该付汇文件放入待处理付汇队列中，然后，按照队列中待处理的付汇文件的入队列顺序，处理付汇文件。

在一种可能的实现方式中，银行服务器对付汇文件中的付汇明细中的一些基础信息进行校验，例如，校验swiftcode是否合法、节点之间的关联关系是否正确，例如，当ServiceCode为NURG时，表明银行需要走FPS清算网络，此种情况下需要在cdtrFinancialId中使用memberId替代SwiftCode。

其中，Swiftcode是银行代码，拥有这些代码的银行都是SWIFT的成员，每个银行都有唯一的Swiftcode，通常在银行之间办理转汇时使用Swiftcode。

环球银行金融电信协会(Society for Worldwide Interbank FinancialTelecommunication，SWIFT)。

S390，换汇服务器从银行服务器中拉取明细校验结果文件，并解析该明细校验结果文件得到明细校验结果。如果明细校验成功，则执行S3100；如果明细校验失败，则执行S3140。

S3100，换汇服务器将付汇文件的状态更新为付汇明细受理待回传付汇结果。

换汇服务器从银行服务器中拉取到该付汇文件对应的明细校验结果为明细校验成功结果时，将该付汇文件的状态更新为付汇明细受理待回传付汇结果，该状态表明银行服务器已经受理该付汇明细，即已受理具体的付汇请求，但还未得到付汇结果。

S3110，银行服务器对明细校验成功的付汇明细执行付汇操作，并生成最终处理结果。

S3120，换汇服务器从银行服务器中拉取该付汇文件的最终处理结果，并解析该最终处理结果。

换汇服务器从银行服务器中下载付汇文件的最终处理结果并存储到本地，然后，对最终处理结果进行解密，并对解密后的最终处理结果进行解析。

S3130，换汇服务器依据解析得到的最终处理结果更新该付汇文件的最终业务状态。

换汇服务器依据解析得到的最终付汇明细对应的最终状态更新付汇文件内各付汇明细的最终状态。

S3140，换汇服务器将付汇文件的最终业务状态更新为付汇失败。

如果换汇服务器获得的第一中间处理结果是文件校验失败，表明付汇文件的文件格式不正确，银行服务器未受理付汇文件，此时，将付汇文件的最终业务状态更新为付汇失败。

如果换汇服务器获得的明细校验失败的处理结果，表明银行服务器未受理付汇明细，则将该付汇文件的最终业务状态更新为付汇失败。

另一方面，本申请还提供了业务异步交互装置实施例，请参见图6，示出了本申请提供的一种业务异步交互装置的结构示意图，该装置应用于发送业务处理请求的服务器中，本文中为了区分发送业务处理请求的服务器和响应业务处理请求的服务器，将发送业务处理请求的服务器称为第一服务器，将响应业务处理请求的服务器称为第二服务器。

如图6所示，该装置可以包括：请求发送模块110、中间结果获取模块120、中间状态更新模块130、最终结果获取模块140和最终状态更新模块150。

请求发送模块110，用于向第二服务器发送针对目标业务的业务处理请求包。

其中，该业务处理请求包用于使第二服务器处理相应的业务。

在一种应用场景下，该业务处理请求包中包括至少两个具有相同业务属性的业务处理请求。例如，多个终端向发送服务器发送了多个业务处理请求，此种情况下，第一服务器可以将业务属性相同的业务处理请求打包成一个业务处理请求包。

在其它应用场景下，该业务处理请求包中包括一个业务处理请求。

中间结果获取模块120，用于获取第二服务器响应该业务处理请求包所产生的中间处理结果。

在第一服务器将业务处理请求包发送至第二服务器之后，第一服务器中的中间结果获取模块120会按照指定的时间间隔查询第二服务器是否生成新的处理结果。

中间状态更新模块130，用于依据中间处理结果更新所述目标业务的中间业务状态。

在中间结果获取模块120从第二服务器中获得中间处理结果后，依据该中间处理结果更新该业务的中间业务状态。

其中，中间状态更新模块130具体用于：解析所述中间处理结果获得业务处理请求包对应的中间处理状态；依据中间处理状态与中间业务状态之间的映射关系，将目标业务的状态更新为与解析得到的中间业务状态相对应的中间业务状态。

在一种可能的实现方式中，第一服务器从第二服务器中获取两个中间处理结果，分别是第一中间处理结果和第二中间处理结果；此种情况下，该中间状态更新模块130具体用于：

解析获得的第一中间处理结果，得到目标服务器对所述业务处理请求包进行格式校验的文件校验成功结果；

依据文件校验成功结果将目标业务的业务状态更新为文件已受理待处理；

解析获得的第一中间处理结果，得到目标服务器对所述业务处理请求包进行格式校验的文件校验失败结果；

依据所述文件校验失败结果将所述目标业务的业务状态更新为请求失败；

解析获得的第二中间处理结果，得到目标服务器对所述业务处理请求包内的业务处理请求进行校验的业务校验成功结果；

依据业务校验成功结果将目标业务的业务状态更新为业务已受理待回传处理结果；

解析获得的第二中间处理结果，得到目标服务器对所述业务处理请求包内的业务处理请求进行校验的业务校验失败结果；

依据业务校验失败结果将目标业务的业务状态更新为业务处理失败。

最终结果获取模块140，用于获取第二服务器响应业务处理请求包所产生的最终处理结果。

从第二服务器中获取最终处理结果的过程与获取中间处理结果的过程相同，此处不再赘述。

最终状态更新模块150，用于依据最终处理结果更新目标业务的最终业务状态。

依据从第二服务器中获得的该目标业务的最终处理结果更新该目标业务的最终业务状态，例如，处理成功或处理失败。

在一种应用场景中，目标业务是付汇业务，即需要从外汇账户支付到境外。此种应用场景下，各个模块的具体功能如下：

请求发送模块110具体用于：检测到付汇请求包后，依据所述付汇请求包生成相应的付汇文件，所述付汇请求包内包括属性相同的至少两个付汇请求；将所述付汇文件按照预设加密算法进行加密后得到加密后的付汇文件；将加密后的付汇文件发送至目标服务器。

中间结果获取模块120具体用于：解析付汇文件获得付汇文件对应的文件标识；查询目标服务器中是否存在与文件标识相匹配的中间处理结果文件；如果目标服务器中存在与文件标识相匹配的中间处理结果文件，则将与文件标识相匹配的中间处理结果文件拉取到本地。

中间状态更新模块130具体用于：解密拉取到本地的中间处理结果文件，得到解密后的中间处理结果文件；解析解密后的中间处理结果文件得到付汇文件对应的中间处理状态；依据中间处理状态与中间业务状态之间的映射关系，将付汇请求包的业务状态更新为与解析得到的中间业务状态。

在一种可能的实现方式中，中间状态更新模块130用于依据中间处理状态与中间业务状态之间的映射关系，将所述付汇请求包的业务状态更新为与解析得到的中间业务状态时具体用于：

若解析解密后的中间处理结果文件得到所述付汇文件对应的第一中间处理结果文件，则将付汇请求包的业务状态更新为付汇请求包已受理且付汇请求待回导；该第一中间处理结果文件表明目标服务器已受理付汇文件；

若解析解密后的中间处理结果文件得到付汇文件对应的第二中间处理结果文件，则将所述付汇请求包的业务状态更新为付汇请求已处理。该第二中间处理结果文件表明所述目标服务器已处理所述付汇请求包中的付汇请求。

最终结果获取模块140具体用于，从银行服务器中获取与该付汇文件相对应的最终处理结果。

最终状态更新模块150，用于依据从银行服务器中获得的最终处理结果更新该付汇文件的最终业务状态。

另一方面，本申请还提供了一种服务器，如参见图7，其示出了本申请的服务器的一种组成结构示意图，本实施例的服务器以包括：处理器201和存储器202。

可选的，该服务器还可以包括通信接口203、输入单元204和显示器205和通信总线206。

处理器201、存储器202、通信接口203、输入单元204、显示器205、均通过通信总线206完成相互间的通信。

在本申请实施例中，该处理器201，可以为中央处理器(Central ProcessingUnit，CPU)，特定应用集成电路，数字信号处理器、现成可编程门阵列或者其他可编程逻辑器件等。

该处理器可以调用存储器202中存储的程序。具体的，处理器可以执行以下消息发送方法的实施例中应用服务器侧所执行的操作。

存储器202中用于存放一个或者一个以上程序，程序可以包括程序代码，所述程序代码包括计算机操作指令，在本申请实施例中，该存储器中至少存储有用于实现以下功能的程序：

向目标服务器发送针对目标业务的业务处理请求包，所述业务处理请求包用于使目标服务器进行相应的业务处理；

获取目标服务器响应业务处理请求包所产生的中间处理结果；

依据中间处理结果更新目标业务的中间业务状态；

获取目标服务器响应业务处理请求包所产生的最终处理结果；

依据最终处理结果更新目标业务的最终业务状态。

在一种可能的实现方式中，该存储器202可包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、以及至少一个功能(比如图像播放功能等)所需的应用程序等；存储数据区可存储根据计算机的使用过程中所创建的数据，比如，用户数据及图像数据等等。

此外，存储器202可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件或其他易失性固态存储器件。

该通信接口203可以为通信模块的接口，如GSM模块的接口。

本申请还可以包括显示器204和输入单元205等等。

当然，图7所示的服务器的结构并不构成对本申请实施例中服务器的限定，在实际应用中服务器可以包括比图7所示的更多或更少的部件，或者组合某些部件。

另一方面，本申请实施例还提供了一种存储介质，所述存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器加载并执行时，实现如上任意一个实施例中的业务异步交互方法。

需要说明的是，本说明书中的各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

以上仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种业务异步交互方法，其特征在于，包括：

向目标服务器发送针对目标业务的业务处理请求包，所述业务处理请求包用于使所述目标服务器进行相应的业务处理；

获取所述目标服务器响应所述业务处理请求包所产生的中间处理结果；

依据所述中间处理结果更新所述目标业务的中间业务状态；

获取所述目标服务器响应所述业务处理请求包所产生的最终处理结果；

依据所述最终处理结果更新所述目标业务的最终业务状态。

2.根据权利要求1所述的方法，其特征在于，所述业务处理请求包中包括至少两个具有相同业务属性的业务处理请求。

3.根据权利要求1所述的方法，其特征在于，所述依据所述中间处理结果更新所述目标业务的中间业务状态，包括：

解析所述中间处理结果获得所述业务处理请求包对应的中间处理状态；

依据中间处理状态与中间业务状态之间的映射关系，将所述目标业务的状态更新为与解析得到的中间业务状态相对应的中间业务状态。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述依据所述中间结果更新所述目标业务的中间业务状态，包括：

解析获得的第一中间处理结果，得到所述目标服务器对所述业务处理请求包进行格式校验的文件校验成功结果；

依据所述文件校验成功结果将所述目标业务的业务状态更新为文件已受理待处理；

解析获得的第一中间处理结果，得到所述目标服务器对所述业务处理请求包进行格式校验的文件校验失败结果；

依据所述文件校验失败结果将所述目标业务的业务状态更新为请求失败；

解析获得的第二中间处理结果，得到所述目标服务器对所述业务处理请求包内的业务处理请求进行校验的业务校验成功结果；

依据所述业务校验成功结果将所述目标业务的业务状态更新为业务已受理待回传处理结果；

解析获得的第二中间处理结果，得到所述目标服务器对所述业务处理请求包内的业务处理请求进行校验的业务校验失败结果；

依据所述业务校验失败结果将所述目标业务的业务状态更新为业务处理失败。

5.根据权利要求1所述的方法，其特征在于，所述目标业务是付汇业务；

所述向目标服务器发送针对目标业务的业务处理请求包，包括：

检测到付汇请求包后，依据所述付汇请求包生成相应的付汇文件，所述付汇请求包内包括属性相同的至少两个付汇请求；

将所述付汇文件按照预设加密算法进行加密后得到加密后的付汇文件；

将加密后的付汇文件发送至目标服务器。

6.根据权利要求5所述的方法，其特征在于，所述获取所述目标服务器响应所述业务处理请求包所产生的中间处理结果，包括：

解析所述付汇文件获得所述付汇文件对应的文件标识；

查询所述目标服务器中是否存在与所述文件标识相匹配的中间处理结果文件；

如果所述目标服务器中存在与所述文件标识相匹配的中间处理结果文件，则将与所述文件标识相匹配的中间处理结果文件拉取到本地。

7.根据权利要求6所述的方法，其特征在于，所述依据所述中间处理结果更新所述目标业务的中间业务状态，包括：

解密拉取到本地的所述中间处理结果文件，得到解密后的中间处理结果文件；

解析解密后的中间处理结果文件得到所述付汇文件对应的中间处理状态；

依据中间处理状态与中间业务状态之间的映射关系，将所述付汇请求包的业务状态更新为与解析得到的中间业务状态。

8.根据权利要求7所述的方法，其特征在于，所述依据中间处理状态与中间业务状态之间的映射关系，将所述付汇请求包的业务状态更新为与解析得到的中间业务状态，包括：

若解析解密后的中间处理结果文件得到所述付汇文件对应的第一中间处理结果文件，所述第一中间处理结果文件表明所述目标服务器已受理所述付汇文件；

将所述付汇请求包的业务状态更新为付汇请求包已受理且付汇请求待回导；

若解析解密后的中间处理结果文件得到所述付汇文件对应的第二中间处理结果文件，所述第二中间处理结果文件表明所述目标服务器已处理所述付汇请求包中的付汇请求；

将所述付汇请求包的业务状态更新为付汇请求已处理。

9.一种业务异步交互装置，其特征在于，包括：

请求发送模块，用于向目标服务器发送针对目标业务的业务处理请求包，所述业务处理请求包用于使所述目标服务器进行相应的业务处理；

中间结果获取模块，用于获取所述目标服务器响应所述业务处理请求包所产生的中间处理结果；

中间状态更新模块，用于依据所述中间处理结果更新所述目标业务的中间业务状态；

最终结果获取模块，用于获取所述目标服务器响应所述业务处理请求包所产生的最终处理结果；

最终状态更新模块，用于依据所述最终处理结果更新所述目标业务的最终业务状态。

10.一种服务器，其特征在于，包括：

处理器和存储器；

其中，所述处理器用于执行所述存储器中存储的程序；

所述存储器用于存储程序，所述程序至少用于：

向目标服务器发送针对目标业务的业务处理请求包，所述业务处理请求包用于使所述目标服务器进行相应的业务处理；

获取所述目标服务器响应所述业务处理请求包所产生的中间处理结果；

依据所述中间处理结果更新所述目标业务的中间业务状态；

获取所述目标服务器响应所述业务处理请求包所产生的最终处理结果；

依据所述最终处理结果更新所述目标业务的最终业务状态。

Images