一种业务处理方法及装置与流程

本发明属于金融领域的业务处理技术领域，尤其涉及一种业务处理方法及装置。

背景技术：

银行现金管理系统在接收到前端系统的业务处理请求，进行业务处理的过程中，通常会与包括银行核心系统、业务子系统、第三方系统等在内的多个外部系统(后端系统)进行交互，在跨系统调用时，如银行现金管理系统与上述各种外部系统进行交互时，对实时性有极高的要求，通常采用向被交互系统发起交易请求，实时等待对方系统的反馈结果，在交互完毕，得到最终的反馈结果并保存后，向前端系统返回一个类似于“您的请求已提交”的响应结果，后续，当有需要时，前端系统可通过查询方式来调出并查看银行现金管理系统对其请求进行处理后所得的处理结果。

具体地，在现金管理系统中，一个典型涉及与外部系统进行交互的交互时序图，请参考图1，现金管理系统接收到前端系统发起的业务处理请求后，进行本系统的业务逻辑处理(如状态修改，条件校验等)，在此基础上，向外部系统发起交易请求并等待反馈，收到外部系统的反馈后对反馈结果进行相应处理(如进行结果存储等)，若存在多个需调用的外部系统，则需顺序按照此方式依次进行处理。在最终的交互结束并对外部系统的反馈结果进行处理后，向前端系统进行响应，以通知前端系统其请求已提交。

此种处理方式下，现金管理系统对前端系统的响应速率，往往与前端系统所请求业务的业务量相关，一般来说，前端系统的响应等待时间与其业务量呈线性相关关系，请求的业务量越大，其响应时长越长，除此之外，响应速率还会受到跨系统调用时外部系统的响应速度、故障状态、通信状态等多种因素的限制，基于此，在以上诸多因素的影响下，前端系统的响应等待时间往往较长，而如何克服这一问题，则是本发明的主要目的所在。

技术实现要素：

有鉴于此，本发明的目的在于提供一种业务处理方法及装置，旨在解决现有技术存在的上述问题，降低前端系统的响应等待时长，提升前端请求的响应速率。

为此，本发明公开如下技术方案：

一种业务处理方法，包括：

获得前端系统的业务处理请求；所述业务处理请求包括：待处理业务对应的总任务的总任务标识，及总任务包含的各个子任务的子任务标识；

依据所述总任务标识及各个子任务标识，从预定数据库中确定出与所述业务处理请求相对应的业务数据；

对所述业务数据进行包含预定的业务逻辑处理的实时处理，得到业务逻辑处理结果；

向前端系统返回响应结果；

依据所述业务逻辑处理结果，确定各个子任务中需与后端的外部系统进行交互处理的各个目标子任务；

对于每个目标子任务，通过与后端的相应外部系统进行交互来获得所述每个目标子任务对应的任务结果信息并存储。

上述方法，优选的，所述对所述业务数据进行包含预定的业务逻辑处理的实时处理，包括：

对所述业务数据进行预定的业务逻辑处理，得到业务逻辑处理结果；

向预先创建的自动任务待执行列表中，为所述业务处理请求登记一条待执行的跨系统交互任务的任务记录，所述任务记录包括所述总任务标识。

上述方法，优选的，所述业务逻辑处理结果包括各个子任务的子任务信息表，各个子任务信息表存储在所述预定数据库中，其中，子任务信息表包括子任务标识、子任务所属总任务的总任务标识以及子任务的状态信息；则所述依据所述业务逻辑处理结果，确定需与后端的外部系统进行交互处理的各个目标子任务，包括：

从所述自动任务待执行列表中，读取所述业务处理请求所对应的任务记录中的总任务标识；

依据所述总任务标识从所述预定数据库中确定出各个子任务的子任务信息表；

基于各个子任务信息表中记录的各个子任务的状态信息，确定需与后端的外部系统进行交互处理的各个目标子任务。

上述方法，优选的，所述对于每个目标子任务，通过与后端的相应外部系统进行交互来获得所述每个目标子任务对应的任务结果信息，包括：

依据各个目标子任务的任务标识，从所述预定数据中查询所述各个目标子任务对应的各条业务数据；从各个目标子任务对应的各条业务数据中，抽取出与外部系统进行交互时所需的各个目标子任务的目标业务数据；并将每条目标业务数据按预设格式作为一条记录登记至预先创建的处理结果明细表中；

从所述处理结果明细表中，按顺序读取出当前待处理的目标子任务的目标业务数据，并对读取的所述目标业务进行请求封装处理，得到所述待处理目标子任务对应的交互处理请求；

将所述交互处理请求发送至相应的外部系统，并接收响应信息；

基于所述响应信息，确定响应是否正常；

如果正常，则将所述响应信息中包含的业务数据处理结果信息，添加至所述处理结果明细表中当前处理的目标子任务对应的当前记录中，并更新所述当前记录的状态为处理成功；如果响应异常，则依据预设的异常处理机制对响应异常的目标子任务进行相应的异常处理。

上述方法，优选的，所述依据预设的异常处理机制对响应异常的目标子任务进行相应的异常处理，包括：

确定异常响应所对应的异常类型；

如果异常类型为通信故障或外部系统故障且外部系统无响应，则在处理结果明细表中标记所述当前处理的目标子任务的当前记录状态为等待重发；并在各目标子任务所需的交互处理结束后，按设定的定时重发机制对处理结果明细表中标记有等待重发的各记录进行重发处理；

如果异常类型为外部系统故障且外部系统有响应，则在处理结果明细表中标记所述当前处理的目标子任务的记录状态为失败；

如果异常类型为业务数据导致的正常失败，则在处理结果明细表中标记所述当前处理的目标子任务的记录状态为拒绝。

上述方法，优选的，所述在各目标子任务所需的交互处理结束后，按设定的定时重发机制对处理结果明细表中标记有等待重发的各记录重发处理，包括：

扫描所述处理结果明细表中所有被标记为等待重发的记录；

针对每个被标记为等待重发的记录，将所述记录对应的交互处理请求重新发送至相应的外部系统进行处理；

对处理成功或失败的记录进行相应的处理结果标记，同时按异常类型对需等待重发的记录标记等待重发；

判断是否满足以下条件中任意一种：处理结果明细表中记录的请求重发次数达到设定的重发次数上限，或处理结果明细表中不存在等待重发的记录，如果不满足，则在经过预定的时间间隔后，对于处理结果明细表中剩余的等待重发的各条记录，采用循环方式重复执行以上各步骤，直至重发次数达到设定的重发次数上限，或重发次数未达上限但处理结果明细表中不存在等待重发的记录为止。

上述方法，优选的，还包括：

基于所述处理结果明细表中记录的记录状态，确定记录的交互处理过程是否成功；

针对处理结果明细表中交互未成功的记录，在所述预定数据库中对未成功的所述记录对应的业务数据进行回退处理。

一种业务处理装置，包括：

获取单元，用于获得前端系统的业务处理请求；所述业务处理请求包括：待处理业务对应的总任务的总任务标识，及总任务包含的各个子任务的子任务标识；

第一确定单元，用于依据所述总任务标识及各个子任务标识，从预定数据库中确定出与所述业务处理请求相对应的业务数据；

处理单元，用于对所述业务数据进行包含预定的业务逻辑处理的实时处理，得到业务逻辑处理结果；

响应单元，用于向前端系统返回响应结果；

第二确定单元，用于依据所述业务逻辑处理结果，确定各个子任务中需与后端的外部系统进行交互处理的各个目标子任务；

交互单元，用于针对每个目标子任务，通过与后端的相应外部系统进行交互来获得所述每个目标子任务对应的任务结果信息并存储。

上述装置，优选的，所述处理单元，进一步用于：

对所述业务数据进行预定的业务逻辑处理，得到业务逻辑处理结果；向预先创建的自动任务待执行列表中，为所述业务处理请求登记一条待执行的跨系统交互任务的任务记录，所述任务记录中包括所述总任务标识。

上述装置，优选的，所述业务逻辑处理结果包括各个子任务的子任务信息表，各个子任务信息表存储在所述预定数据库中，其中，子任务信息表包括子任务标识、子任务所属总任务的总任务标识以及子任务的状态信息；则所述第二确定单元，进一步用于：

从所述自动任务待执行列表中，读取所述业务处理请求所对应的任务记录中的总任务标识；依据所述总任务标识从所述预定数据库中确定出各个子任务的子任务信息表；基于各个子任务信息表中记录的各个子任务的状态信息，确定需与后端的外部系统进行交互处理的各个目标子任务。

上述装置，优选的，所述交互单元，进一步用于：

依据各个目标子任务的任务标识，从所述预定数据中查询所述各个目标子任务对应的各条业务数据；从各个目标子任务对应的各条业务数据中，抽取出与外部系统进行交互时所需的各个目标子任务的目标业务数据；并将每条目标业务数据按预设格式作为一条记录登记至预先创建的处理结果明细表中；从所述处理结果明细表中，按顺序读取出当前待处理的目标子任务的目标业务数据，并对读取的所述目标业务进行请求封装处理，得到所述待处理目标子任务对应的交互处理请求；将所述交互处理请求发送至相应的外部系统，并接收响应信息；基于所述响应信息，确定响应是否正常；如果正常，则将所述响应信息中包含的业务数据处理结果信息，添加至所述处理结果明细表中当前处理的目标子任务对应的当前记录中，并更新所述当前记录的状态为处理成功；如果响应异常，则依据预设的异常处理机制对响应异常的目标子任务进行相应的异常处理。

上述装置，优选的，所述交互单元依据预设的异常处理机制对响应异常的目标子任务进行相应的异常处理，进一步包括：

确定异常响应所对应的异常类型；如果异常类型为通信故障或外部系统故障且外部系统无响应，则在处理结果明细表中标记所述当前处理的目标子任务的当前记录状态为等待重发；并在各目标子任务所需的交互处理结束后，按设定的定时重发机制对处理结果明细表中标记有等待重发的各记录进行重发处理；如果异常类型为外部系统故障且外部系统有响应，则在处理结果明细表中标记所述当前处理的目标子任务的记录状态为失败；如果异常类型为业务数据导致的正常失败，则在处理结果明细表中标记所述当前处理的目标子任务的记录状态为拒绝。

上述装置，优选的，所述交互单元，在各目标子任务所需的交互处理结束后，按设定的定时重发机制对处理结果明细表中标记有等待重发的各记录重发处理，进一步包括：

扫描所述处理结果明细表中所有被标记为等待重发的记录；针对每个被标记为等待重发的记录，将所述记录对应的交互处理请求重新发送至相应的外部系统进行处理；对处理成功或失败的记录进行相应的处理结果标记，同时按异常类型对需等待重发的记录标记等待重发；判断是否满足以下条件中任意一种：处理结果明细表中记录的请求重发次数达到设定的重发次数上限，或处理结果明细表中不存在等待重发的记录，如果不满足，则在经过预定的时间间隔后，对于处理结果明细表中剩余的等待重发的各条记录，采用循环方式重复执行以上各步骤，直至重发次数达到设定的重发次数上限，或重发次数未达上限但处理结果明细表中不存在等待重发的记录为止。

上述装置，优选的，还包括：

回退处理单元，用于基于所述处理结果明细表中记录的记录状态，确定记录的交互处理过程是否成功；针对处理结果明细表中交互未成功的记录，在所述预定数据库中对未成功的所述记录对应的业务数据进行回退处理。

由以上方案可知，本发明公开的业务处理方法及装置，在获得前端系统的业务处理请求，并对其进行所需的实时处理(未跨系统)后，即向前端系统返回一个响应结果，如具体可返回一个“已提交前端系统请求”的提示信息，后续，则采用异步方式进行与外部系统间的交互(即指对前端系统的响应并不以该交互处理的实时执行为前提)，以此实现对所述业务处理请求中需与外部系统进行交互的部分进行处理，可见，本发明方案通过前移对前端系统进行响应的时间节点，使得对前端系统的响应无需以跨系统交互处理的实时执行为前提，从而解决了响应时间与业务量的线性相关问题，且不会受跨系统调用时的响应速度、故障状态、通信状态等多种因素的限制，有效缩减了前端系统的响应等待时间。

附图说明

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

图1是现有技术的一个典型的企业现金管理系统与前端系统及外部系统间的交互时序图；

图2是本发明实施例一提供的业务处理方法流程图；

图3是本发明实施例一提供的对前端请求进行实时处理的示例图；

图4是本发明实施例二提供的对异常响应进行异常处理的流程图；

图5是本发明实施例二提供的异步自动任务的处理过程示例图；

图6是本发明实施例三提供的定时重发的流程示意图；

图7是本发明实施例三提供的定时重发的一个详细实现过程示例图；

图8是现有技术的一个典型的企业现金管理系统进行异常处理时的交互时序图；

图9是本发明实施例四提供的本发明方案对前端请求进行处理的处理机制示意图；

图10是本发明实施例五提供的业务处理装置的结构示意图。

具体实施方式

为了引用和清楚起见，下文中使用的技术名词、简写或缩写总结解释如下：

外部系统:是指向本系统(当前执行处理逻辑的系统)提供服务的其他系统或子系统，可以理解为本系统的后端系统。

前端系统：前端系统是需要本系统提供服务的其他系统或子系统。

API：Application Programming Interface，应用程序编程接口，是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，无需访问源码或理解工作机制。

JavaBean：是一种Java语言写成的可重用组件。

构件：是系统中实际存在的可更换部分，能够实现特定的功能，符合一套接口标准并实现一组接口。

银行票据池系统：是客户将票据全部外包给银行，银行为客户提供商业汇票鉴别、查询、保管、托收等一揽子服务，并可以根据客户的需要，随时提供商业汇票的提取、贴现、质押开票等融资保证企业经营需要的一种综合性票据增值服务,这样客户自己就可以将全部精力集中于主业。

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

实施例一

本发明实施例一提供了一种业务处理方法，该方法可应用于金融领域的业务处理场景中，例如具体地，可应用于银行的现金管理系统中，参考图2示出的业务处理方法流程图，该方法可以包括以下步骤：

步骤201、获得前端系统的业务处理请求；所述业务处理请求包括：待处理业务对应的总任务的总任务标识，及总任务包含的各个子任务的子任务标识。

本实施例中，将本发明方法的执行体称作为本系统，以有效区别所述前端系统以及后端的外部系统，进而方便描述及理解，其中，所述本系统具体可以是上文所述的银行现金管理系统。

基于此，本步骤中，可在所述本系统如所述银行现金管理系统，接收由前端系统基于实际的业务需求所提交的业务处理请求，前端系统发起一次业务处理请求，通常会包含对若干条业务数据进行处理的需求，此处，将所述若干条业务数据对应的处理任务称为总任务，则每条业务数据对应的处理任务可称之为子任务。

所述业务处理请求包括待处理业务对应的总任务的总任务标识，及总任务包含的各个子任务的子任务标识，例如对于待处理的一批现金贴现业务而言，所述总任务标识可以是该批现金贴现业务的批次号或业务流水号等，所述子任务标识可以是该批现金贴现业务中每个单笔现金贴现业务对应的票据编号等。

步骤202、依据所述总任务标识及各个子任务标识，从预定数据库中确定出与所述业务处理请求相对应的业务数据。

所述预定数据库，可以是所述本系统维护的一个存放有原始业务数据的数据库，示例性地，所述数据库中的原始业务数据可以是诸如现金贴现等业务对应的业务票据数据等，每个票据数据对应数据库中的一条记录，也就是说，对于前端系统所上送请求中待处理业务对应的各个子任务而言，每个子任务均可在所述数据库中查询出一条相对应的业务数据记录，该记录中的业务数据将作为后续对所述子任务进行处理时的数据依据。

当本系统获得前端系统的业务处理请求后，一般来说，需对请求的待处理业务数据进行两步处理，一是本系统的业务逻辑处理，如状态修改、条件校验等等，二是在通过本系统的业务逻辑处理之后，对所筛选出的需进行跨系统处理的业务数据继续进行跨系统的交互处理。

以现金管理系统中的票据池系统为例，假设在前端系统没有向票据池系统发起业务请求时，票据状态为A，当发起请求后，根据票据池的工作流设置，对票据数据的业务处理逻辑必须经过：申请-复核-终审几个步骤，对应的处理后相应地将票据状态调整为B-C-D，在终审步骤，当对票据数据终审通过后，则针对终审通过的票据数据，向相应的外部系统发出交互处理请求，最终通过与外部系统进行交互实现票据数据的跨系统处理。

区别于现有技术，在跨系统的交互处理完成后才向前端系统作出响应，例如向前端系统返回诸如“您的请求已提交”等提示信息(后续前端系统通过查询本系统数据库进行结果查看)，本发明将响应的时间节点前移，在跨系统交互处理之前即向前端系统反馈响应信息，也就是说，现有技术的请求响应依赖于整个处理过程(本系统处理及跨系统交互处理)的实时/同步执行，而本发明的响应仅依赖于本系统的实时处理，在对前端请求进行本系统实时处理后即向前端反馈响应信息，后续的跨系统交互处理可异步执行。接下来，将通过本发明方法的各个步骤对本系统的实时处理以及跨系统的交互处理实现过程进行详细阐述。

当本系统获得前端系统的业务处理请求，并对其进行本系统的实时处理之前，如对其进行本系统的业务逻辑处理之前，需首先依据该请求中的总任务标识及各个子任务标识，对本系统数据库进行查询，以确定出前端系统所上送的请求在数据库中对应的需处理的各条业务数据记录。

步骤203、对所述业务数据进行预定的包含业务逻辑处理，得到业务逻辑处理结果。

在通过查询数据库，确定出此次请求需处理的各条业务数据后，则本系统继续对确定出的各业务数据进行所需的实时处理，本实施例中，在本系统对业务处理请求所进行的实时处理具体包括：1)本系统中的业务逻辑处理；2)在通过本系统的业务逻辑处理后，针对前端系统请求中对应的需与外部系统进行交互的部分(如通过终审的各票据需要依赖跨系统交互才能实现最终处理)，为其在预先创建的自动任务待执行列表(具体可在本系统数据库中预先创建)中登记一条异步自动任务记录/跨系统交互任务记录，该记录中具体登记有一个待执行的跨系统交互任务。

所述业务逻辑处理，例如，具体可以是对各条业务数据进行所需的状态修改，进行所需的条件校验等等。所述业务逻辑处理结果包括：各条业务数据所对应的各个子任务的子任务信息表，各个子任务信息表存储在所述预定数据库中，其中，子任务信息表包括子任务标识、子任务所属总任务的总任务标识以及子任务的状态信息；所述子任务的状态信息例如具体可以是子任务所对应的业务数据处于复核状态、终审通过状态或者终审拒绝状态等等。后续可以本系统的业务逻辑处理结果为依据，来判定需与外部系统进行交互处理的各个目标子任务。

在对前端请求进行所需的业务逻辑处理后，需继续针对前端系统请求中对应的需与外部系统进行交互的部分，在本系统数据库的自动任务待执行列表中，为其登记一条异步自动任务记录。

为提升登记异步自动任务的效率，降低由于大量写数据库所带来的性能开销，优选地，本实施例在所述异步自动任务记录中，仅登记能够从本系统数据库中成功定位、抽取出需与外部系统进行交互的业务数据的最少量指示信息。

本实施例中，所述最少量指示信息包括前端请求的总任务标识，例如可以是所请求的一批待处理票据的批次号、业务流水号等，除此之外，在实际实施本发明时，还可以包含一个用于抽取所需业务数据的业务逻辑控件的控件标识，以及异步自动任务的执行时间等，该业务逻辑控件具体用于依据自动异步任务中登记的总任务标识，从本系统数据库中定位并抽取出前端请求对应的需进行跨系统交互的业务数据。示例性地，该业务逻辑控件具体可以是一个JavaBean控件，所对应的控件标识具体为JavaBean id。

异步自动任务的执行时间可以是基于异步自动任务的相应触发模式所确定的时间，例如，立即执行模式下，异步自动任务的执行时间则是响应完成时间，即在完成对前端系统的响应后立即执行异步自动任务；定时执行模式下，异步自动任务的执行时间则是预先定时的时间，在达到定时时间时，执行异步自动任务，实际应用中异步自动任务的执行时间可基于实际需求进行确定，如可综合考虑最终处理结果的时效性(方便前端系统尽早查询结果)、以及本系统的当前资源占用情况进行确定，一般来说，在本系统资源充足的情况下，优先采用立即执行模式。

参考图3，图3示出了在本系统对前端请求进行实时处理的流程示意图。

在对前端请求完成所需的业务逻辑处理，并完成异步自动任务的登记后，则前端请求的实时处理部分已经完成。

步骤204、向前端系统返回响应结果。

在完成对前端请求所需的实时处理后，本发明即向前端系统返回一个响应信息，例如具体返回一个类似“您的请求已提交”的提示信息等，而不必等待至后续的跨系统交互处理部分完成后才作出响应。通过前移对前端系统进行响应的时间节点，使得前端系统的响应不再依赖于耗时较多(具体耗时与待处理的业务量呈线性关系，且还会受外部系统的响应速度、故障状态、通信状态等多种因素的限制)的跨系统处理部分的实时执行。后续，跨系统交互处理的环节则可采用异步方式执行。

步骤205、依据所述业务逻辑处理结果，确定需与后端的外部系统进行交互处理的各个目标子任务。

在向前端系统作出响应之后，当达到异步自动任务的执行时间时，需继续调起自动任务待执行列表中，为前端请求登记的异步自动任务进行后续的跨系统交互处理。

具体地，首先，需从登记的前端请求的异步自动任务中，获得前端请求的总任务标识，之后，依据所述总任务标识从本系统数据库中确定出各个子任务的子任务信息表；在此基础上，基于各个子任务信息表中记录的各个子任务的状态信息，确定需与后端的外部系统进行交互处理的各个目标子任务。例如，假设子任务的状态为终审通过，则表示该子任务需进行后续的跨系统交互处理，如果子任务的状态为终审拒绝，则表示该子任务不需进行跨系统交互处理。

步骤206、对于每个目标子任务，通过与后端的相应外部系统进行交互来获得所述每个目标子任务对应的任务结果信息并存储。

该步骤可以通过以下过程实现：(1)依据各个目标子任务的任务标识，从所述预定数据中查询所述各个目标子任务对应的各条业务数据；从各个目标子任务对应的各条业务数据中，抽取出与外部系统进行交互时所需的各个目标子任务的目标业务数据；并将每条目标业务数据按预设格式作为一条记录登记至预先创建的处理结果明细表中；(2)从所述处理结果明细表中，按顺序读取出当前待处理的目标子任务的目标业务数据，并对读取的所述目标业务进行请求封装处理，得到所述待处理目标子任务对应的交互处理请求；(3)将所述处理交互请求发送至相应的外部系统，并接收响应信息；(4)基于所述响应信息，确定响应是否正常；(5)如果正常，则将所述响应信息中包含的业务数据处理结果信息，添加至所述处理结果明细表中当前处理的目标子任务对应的当前记录中，并更新所述当前记录的状态为处理成功；如果响应异常，则依据预设的异常处理机制对响应异常的目标子任务进行相应的异常处理。

实际实施本发明时，当异步自动任务处理逻辑开始执行时，会创建异步自动任务记录中登记的JavaBean id所对应的实例，并根据前端请求的总任务标识(如批次号、业务流水号等)，调用该实例所实现的业务数据抽取方法，按上述抽取过程从数据库中抽取出与外部系统交互时所需的目标业务数据。

所述响应信息包括响应情况(例如响应正常与否，响应异常时的异常类型等)的相关指示信息，以及响应正常时外部系统的业务数据处理结果信息，基于此，当本系统向外部系统发出交互处理请求，并接收到响应信息后，可通过对响应信息的相关字段进行分析，来获知响应是否正常。并在响应正常时，向处理结果明细表的对应记录中添加外部系统反馈的业务数据处理结果信息，并对记录状态进行标记，标记为处理成功；否则，如果异常，则依据预设的异常处理机制对响应异常的目标子任务进行相应的异常处理，关于异常处理的实现过程将在接下来的实施例中详细阐述。

最终，本地数据库可通过存储处理结果明细表中的数据，为前端系统的结果查询提供数据支持。

由以上方案可知，本发明公开的业务处理方法，在获得前端系统的业务处理请求，并对其进行所需的实时处理(未跨系统)后，即向前端系统返回一个响应结果，如具体可返回一个“已提交前端系统请求”的提示信息，后续，则采用异步方式进行与外部系统间的交互(即指对前端系统的响应并不以该交互处理的实时执行为前提)，以此实现对所述业务处理请求中需与外部系统进行交互的部分进行处理，可见，本发明方案通过前移对前端系统进行响应的时间节点，使得对前端系统的响应无需以跨系统交互处理的实时执行为前提，从而解决了响应时间与业务量的线性相关问题，且不会受跨系统调用时的响应速度、故障状态、通信状态等多种因素的限制，有效缩减了前端系统的响应等待时间。

实施例二

本实施例二，具体对跨系统交互处理中响应异常时的异常处理过程进行描述，参考图4，在响应异常时，依据预设的异常处理机制对响应异常的目标子任务进行相应的异常处理，包括：

步骤401、确定异常响应所对应的异常类型；

步骤402、如果异常类型为通信故障或外部系统故障且外部系统无响应，则在处理结果明细表中标记所述当前处理的目标子任务的当前记录状态为等待重发；并在各目标子任务所需的交互处理结束后，按设定的定时重发机制对处理结果明细表中标记有等待重发的各记录进行重发处理；

步骤403、如果异常类型为外部系统故障且外部系统有响应，则在处理结果明细表中标记所述当前处理的目标子任务的记录状态为失败；

步骤404、如果异常类型为业务数据导致的正常失败，则在处理结果明细表中标记所述当前处理的目标子任务的记录状态为拒绝。

具体地，异常响应所对应的异常类型可通过对本系统所接收的响应信息进行分析得到。本实施例将响应异常时的异常类型划分为以下四种：通信故障、外部系统故障且外部系统无响应、外部系统故障且外部系统有响应，以及业务数据导致的正常失败。

针对每种类型的响应异常，分别进行以下的异常处理：

1)通信故障

向外部系统发送交互处理请求后马上收到异常信息，此种类型下更新处理结果明细表中当前所处理的业务数据的处理结果为失败，并将业务数据对应的记录状态标记为等待重发。后续在各目标子任务所需的交互处理结束后，按设定的定时重发机制对处理结果明细表中标记有等待重发的各记录进行重发处理。

2)外部系统故障(无响应)

向外部系统发送交互处理请求后马上收到异常信息，此种类型下更新处理结果明细表中当前所处理的业务数据的处理结果为失败，并将业务数据对应的记录状态标记为等待重发。后续在各目标子任务所需的交互处理结束后，按设定的定时重发机制对处理结果明细表中标记有等待重发的各记录进行重发处理。

3)外部系统故障(有响应)

向外部系统发送交互处理请求后，能够收到外部系统的响应信息，但该响应信息表示处理失败，此种情况下，更新处理结果明细表中当前所处理的业务数据的处理结果为失败，同时将业务数据所对应记录的状态标记为失败。为了便于前端系统重新发起业务处理请求(例如针对处理失败的业务数据重新请求处理)，针对此种情况还调用回退API，将本系统数据库中当前未处理成功的业务数据的状态回退至前端请求发起之前的状态。

4)业务数据导致的正常失败

向外部系统发送交互处理请求后，能够收到外部系统的响应信息，但是通过对响应信息相关字段进行分析得知该请求已经被外部系统拒绝，此时更新处理结果明细表中当前所处理的业务数据的处理结果为失败，并将该业务数据的记录状态标记为拒绝，然后，同样调用回退API，将本系统数据库中当前未处理成功的业务数据的状态回退至前端请求发起之前的状态，以便于前端系统重新发起业务请求。

参考图5，图5示出了基于本实施例异常处理方案的异步自动任务的处理过程流程图。

区别于现有技术一旦响应异常，即对异常响应不加区分地进行请求重发(不断进行请求重发，直至到达重发次数上限或正常响应)的处理方式，本实施例对异常类型进行了更细粒度的划分，并针对各种异常类型的实际情况确定是否需对其进行请求重发处理，通过对不再需要进行请求重发的异常类型(如业务数据导致的正常失败，被外部系统拒绝等)，进行异常结果的直接记录处理，可有效节约异常处理过程的耗时，提升异常处理效率。

实施例三

本实施例三对本发明的定时重发处理过程进行详细阐述。参考图6，具体可通过以下的定时重发处理逻辑，实现对处理结果明细表中标记有等待重发的各条记录进行重发处理：

步骤601、扫描所述处理结果明细表中所有被标记为等待重发的记录；

步骤602、针对每个被标记为等待重发的记录，将所述记录对应的交互处理请求重新发送至相应的外部系统进行处理；

步骤603、对处理成功或失败的记录进行相应的处理结果标记，同时按异常类型对需等待重发的记录标记等待重发；

步骤604、判断是否满足以下条件中任意一种：处理结果明细表中记录的请求重发次数达到设定的重发次数上限，或处理结果明细表中不存在等待重发的记录，如果不满足，则在经过预定的时间间隔后，对于处理结果明细表中剩余的等待重发的各条记录，采用循环方式重复执行以上各步骤，直至重发次数达到设定的重发次数上限，或重发次数未达上限但处理结果明细表中不存在等待重发的记录为止。

此处，为避免误解，需要说明的是，所述重发次数是以处理结果明细表中的一个记录为准进行计数的，而非处理结果明细表中所有记录重发次数的累计。

具体地，定时重发处理逻辑独立于异步自动任务处理逻辑之外，该处理逻辑按照经过预估的等待时间间隔自动调起。

以下提供该定时重发处理逻辑的一个更为详细的实现过程，参考图7，定时重发处理逻辑会首先扫描处理结果明细表中所有被标记为等待重发的记录，并读取处理结果明细表中已在首次执行交互时存储的交互处理请求，然后顺序执行重发操作。

重发执行完成后，首先将当前重发次数加一，若接收到外部系统响应(无论是处理成功或处理失败)，对处理结果明细表的更新策略与异步自动任务处理逻辑一致。若向外部系统发送请求后马上收到异常信息，应判断当前业务记录处理的重发次数是否达到系统规定的重发次数上限，若已达上限，则更新处理结果为失败，并将记录状态标记为“失败”，然后调用回退API。若未达上限，则仍将记录标记为“等待重发”，并采用循环方式，继续对处理结果明细中剩余的仍需等待重发的个记录继续进行重发操作。

此处，需要说明的是，现有技术中，在进行跨系统交互时，当本系统向外部系统发送请求后，如果响应异常，则本系统对响应异常的请求不加区分地进行重发处理，参考图8示出的一个典型的企业现金管理系统交互时序图，在设定的重发次数范围内，尝试向外部系统重发请求，直到外部系统响应或重发尝试次数用尽。采用此种重发机制的异常处理效果不显著，由于几次重试间隔时间非常接近(毫秒级)，当通信故障延续时间较长(如分钟级)时，重发请求均会失败。这是由于此种技术方案并不能有效地将几次重试在时间上均匀分布，因而无法规避具有一定时间持续性的故障。

而本发明提供的上述重发处理逻辑有效解决了这一问题，本发明的定时重发机制，当第一次请求失败后，并不会马上进行重发，而是会在经过预估的等待时间后，针对所有需要等待重发的记录按所述预估的等待时间为时间间隔，进行多轮请求重发处理，每一轮的请求重发处理中，针对一条记录，仅对其请求重发一次，而不会在一个较短的时间内(如毫秒级)将一条记录拥有的重发次数用尽。从而实现了多次的请求重发在时间上能够均匀分布。可有效规避具有一定时间持续性的故障，进一步降低了因通信故障等原因导致的系统处理失败率。

实施例四

本实施例提供本发明方法的一种可能的实现方式。

参考图9示出的本发明方案对前端请求进行处理的处理机制示意图，本发明将本系统对前端请求的处理流程分为实时处理逻辑、异步自动任务处理逻辑及定时重发处理逻辑三个部分，并通过提出异步自动任务、与外部系统交互时所需的交互数据/业务数据抽取、定时自动重发三项主要技术，在确保业务功能稳定性的基础上，极大减少了前端请求的响应等待时间，并进一步降低了因通信故障等原因导致的系统处理失败率。

本发明基于以上三项技术实现了本系统与外部系统之间所需的全部交互功能(包括异步自动任务处理环节及异常处理时的定时重发环节)，本实施例通过功能模块化设计来实现上述三项技术，将其实现为一个独立的构件来提供外部系统交互服务，而负责本系统实时处理部分的业务功能构件只需继承外外部交互功能的构件，即可实现在本系统与外部系统进行交互。通过此种方式，可实现将本系统的核心业务处理逻辑与本系统跟外部系统间的交互逻辑进一步分离，从而降低了系统耦合度，提高了核心业务处理逻辑的开发效率，在代码开发工作量、代码可维护性、系统稳定性、系统可扩展性、客户体验方面都远优于现有技术的设计方案。

在具体实施时，可采用Java开发语言、Spring开发框架和Oracle数据库存储作为技术实现方式。

实施例五

本实施例五公开一种业务处理装置，参考图10示出的业务处理装置结构示意图，该装置包括：

获取单元11，用于获得前端系统的业务处理请求；所述业务处理请求包括：待处理业务对应的总任务的总任务标识，及总任务包含的各个子任务的子任务标识；第一确定单元12，用于依据所述总任务标识及各个子任务标识，从预定数据库中确定出与所述业务处理请求相对应的业务数据；处理单元13，用于对所述业务数据进行包含预定的业务逻辑处理的实时处理，得到业务逻辑处理结果；响应单元14，用于向前端系统返回响应结果；第二确定单元15，用于依据所述业务逻辑处理结果，确定各个子任务中需与后端的外部系统进行交互处理的各个目标子任务；交互单元16，用于针对每个目标子任务，通过与后端的相应外部系统进行交互来获得所述每个目标子任务对应的任务结果信息并存储。

在本发明实施例的一实施方式中，所述处理单元，进一步用于：对所述业务数据进行预定的业务逻辑处理，得到业务逻辑处理结果；向预先创建的自动任务待执行列表中，为所述业务处理请求登记一条待执行的跨系统交互任务的任务记录，所述任务记录中包括所述总任务标识。

在本发明实施例的一实施方式中，所述第二确定单元，进一步用于：从所述自动任务待执行列表中，读取所述业务处理请求所对应的任务记录中的总任务标识；依据所述总任务标识从所述预定数据库中确定出各个子任务的子任务信息表；基于各个子任务信息表中记录的各个子任务的状态信息，确定需与后端的外部系统进行交互处理的各个目标子任务。

在本发明实施例的一实施方式中，所述交互单元，进一步用于：

依据各个目标子任务的任务标识，从所述预定数据中查询所述各个目标子任务对应的各条业务数据；从各个目标子任务对应的各条业务数据中，抽取出与外部系统进行交互时所需的各个目标子任务的目标业务数据；并将每条目标业务数据按预设格式作为一条记录登记至预先创建的处理结果明细表中；从所述处理结果明细表中，按顺序读取出当前待处理的目标子任务的目标业务数据，并对读取的所述目标业务进行请求封装处理，得到所述待处理目标子任务对应的交互处理请求；将所述交互处理请求发送至相应的外部系统，并接收响应信息；基于所述响应信息，确定响应是否正常；如果正常，则将所述响应信息中包含的业务数据处理结果信息，添加至所述处理结果明细表中当前处理的目标子任务对应的当前记录中，并更新所述所述当前记录的状态为处理成功；如果响应异常，则依据预设的异常处理机制对响应异常的目标子任务进行相应的异常处理。

在本发明实施例的一实施方式中，所述交互单元依据预设的异常处理机制对响应异常的目标子任务进行相应的异常处理，进一步包括：

确定异常响应所对应的异常类型；如果异常类型为通信故障或外部系统故障且外部系统无响应，则在处理结果明细表中标记所述当前处理的目标子任务的当前记录状态为等待重发；并在各目标子任务所需的交互处理结束后，按设定的定时重发机制对处理结果明细表中标记有等待重发的各记录进行重发处理；如果异常类型为外部系统故障且外部系统有响应，则在处理结果明细表中标记所述当前处理的目标子任务的记录状态为失败；如果异常类型为业务数据导致的正常失败，则在处理结果明细表中标记所述当前处理的目标子任务的记录状态为拒绝。

在本发明实施例的一实施方式中，所述交互单元，在各目标子任务所需的交互处理结束后，按设定的定时重发机制对处理结果明细表中标记有等待重发的各记录重发处理，进一步包括：

扫描所述处理结果明细表中所有被标记为等待重发的记录；针对每个被标记为等待重发的记录，将所述记录对应的交互处理请求重新发送至相应的外部系统进行处理；对处理成功或失败的记录进行成功与否的处理结果标记，同时标记处理失败的记录的状态为等待重发；在经过预定的时间间隔后，对于处理结果明细表中剩余的等待重发的各条记录，采用循环方式重复执行以上各步骤，直至重发次数达到设定的重发次数上限，或重发次数未达上限但处理结果明细表中不存在等待重发的记录为止。

在本发明实施例的一实施方式中，所述装置还包括：回退处理单元，用于基于所述处理结果明细表中记录的记录状态，确定记录的交互处理过程是否成功；针对处理结果明细表中交互未成功的记录，在所述预定数据库中对未成功的所述记录对应的业务数据进行回退处理。

此处，需要说明的是，本实施例涉及的业务处理装置的描述，与上文方法的描述是类似的，且同方法的有益效果描述，对于本发明的业务处理装置在本实施例中未披露的技术细节，请参照本发明方法实施例的说明，本实施对此不再作赘述。

综上所述，本发明方案具有以下优势：采用异步自动任务可以显著提高实时交易的响应速度，提升用户体验；在登记异步自动任务时只保留最小量信息，在保证数据准确性的前提下，降低了由于大量写数据库所带来的性能开销；采用独立构件的形式实现本系统与外部系统间的交互机制，降低了系统耦合度，减少了业务逻辑构件的代码开发工作量、提升了业务逻辑构件的代码可维护性及系统稳定性、并具有良好的系统可扩展性；可灵活配置重发次数阈值上限，当异步自动任务处理逻辑需增加多线程并发处理功能时，可快速开发并部署；定时重发机制在时间上是均匀分布的，可以有效避免具有一定时间持续性的故障。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

为了描述的方便，描述以上系统或装置时以功能分为各种模块或单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

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

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