审批处理方法、装置、设备及存储介质

技术领域

本申请实施例涉及互联网技术领域，尤其涉及一种审批处理方法、装置、设备及存储介质。

背景技术

企业资源计划(enterprise resource planning，ERP)系统是指建立在信息技术基础上，集信息技术与先进管理思想于一身，以系统化的管理思想，为企业员工及决策层提供决策手段的管理平台，ERP系统中的业务流程管理(business process management，BPM)可以用于执行审批处理，以提高组织业务绩效。

现有技术中，ERP系统的BPM审批流程中，有很多场景都是BPM审批服务与应用服务一体化，即处理BPM审批服务的同时需要同步执行应用服务。具体的，在该场景中，终端设备在确定调用的BPM审批服务成功后，再调用该BPM审批服务所涉及的各应用服务，只有在BPM审批服务和该BPM审批服务所涉及的各应用服务均成功时，才能确定BPM审批流程结束。一旦BPM审批服务失败或者该BPM审批服务所涉及的某个应用服务失败，则不再继续。而且，若BPM审批服务成功，但该BPM审批服务所涉及的某个应用服务失败，则需要调用BPM审批服务进行逆向操作回滚，即将BPM审批服务退回到未审批的状态。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：BPM审批服务和其所涉及的各应用服务之间具有较强的耦合性，当BPM审批服务所涉及的应用服务较多时，需要调用的应用服务就越多，存在应用服务调用失败的可能性就越大，因而，若某个应用服务失败，则BPM审批服务的回滚操作过程就越复杂，存在业务处理效率低、维护成本高的问题。

发明内容

本申请实施例提供一种审批处理方法、装置、设备及存储介质，用以解决现有审批处理方案中存在的业务处理效率低、成本高的问题。

根据本申请的第一方面，本申请实施例提供一种审批处理方法，包括：

获取终端设备的审批处理请求，所述审批处理请求包括：目标审批事务的标识；

根据所述目标审批事务的标识，确定出所述目标审批事务包括的目标审批服务和所述目标审批服务关联的所有目标应用服务；

若确定所述目标审批服务的审批结果为成功，则通过调用消息队列服务，获取每个目标应用服务的服务结果；

若确定所述目标审批服务关联的所有目标应用服务的服务结果均为正确，则向所述终端设备推送审批完成通知。

在第一方面的一种可能设计中，在所述获取审批处理请求之前，所述方法还包括：

获取至少一个待审批事务的信息，所述至少一个待审批事务包括：所述目标审批事务，每个待审批事务的信息包括：待审批服务的信息和所述待审批服务关联的至少一个应用服务的信息；

根据每个待审批事务的信息，生成每个待审批事务对应的服务注册信息；

根据每个待审批事务对应的服务注册信息，生成并存储已注册服务信息表。

可选的，所述根据所述目标审批事务的标识，确定出所述目标审批事务包括的目标审批服务和所述目标审批服务关联的所有目标应用服务，包括：

根据所述目标审批事务的标识，查询所述已注册服务信息表，确定出所述目标审批事务包括的目标审批服务和所述目标审批服务关联的所有目标应用服务；

相应的，所述通过调用消息队列服务，获取每个目标应用服务的服务结果，包括：

根据每个目标应用服务的信息，生成所述目标审批服务对应的每个应用服务处理消息；

将所述目标审批服务对应的所有应用服务处理消息依次推送至消息队列中；

利用所述消息队列对应的消息队列服务，调用每个目标应用服务的业务接口对每条应用服务处理消息进行处理，获取每个目标应用服务的服务结果。

可选的，所述将所述目标审批服务对应的所有应用服务处理消息依次推送至消息队列中，包括：

周期性的将所述目标审批服务对应的所有应用服务处理消息依次推送至消息队列中；

相应的，在所述利用所述消息队列对应的消息队列服务，调用每个目标应用服务的业务接口对每条应用服务处理消息进行处理，获取每个目标应用服务的服务结果之前，所述方法还包括：

确定出所述消息队列中的已成功处理的应用服务处理消息；

剔除掉所述消息队列中的已成功处理的应用服务处理消息。

在第一方面的另一种可能设计中，所述方法还包括：

若确定所述目标审批服务的审批结果为失败，则中断所述审批处理请求的处理过程；

向所述终端设备返回审批失败的通知。

在第一方面的再一种可能设计中，所述方法还包括：

若确定所述目标审批服务关联的所有目标应用服务的服务结果中存在核查错误的服务结果，则执行弃审操作；

向所述终端设备推送审批失败通知。

根据本申请的第二方面，本申请实施例提供一种审批处理装置，包括：

获取模块，用于获取终端设备的审批处理请求，所述审批处理请求包括：目标审批事务的标识；

处理模块，用于根据所述目标审批事务的标识，确定出所述目标审批事务包括的目标审批服务和所述目标审批服务关联的所有目标应用服务；

调用模块，用于在确定所述目标审批服务的审批结果为成功时，通过调用消息队列服务，获取每个目标应用服务的服务结果；

推送模块，用于在确定所述目标审批服务关联的所有目标应用服务的服务结果均为正确时，向所述终端设备推送审批完成通知。

在第二方面的一种可能设计中，所述获取模块，还用于获取至少一个待审批事务的信息，所述至少一个待审批事务包括：所述目标审批事务，每个待审批事务的信息包括：待审批服务的信息和所述待审批服务关联的至少一个应用服务的信息；

所述处理模块，还用于：

根据每个待审批事务的信息，生成每个待审批事务对应的服务注册信息；

根据每个待审批事务对应的服务注册信息，生成并存储已注册服务信息表。

可选的，所述处理模块，具体用于根据所述目标审批事务的标识，查询所述已注册服务信息表，确定出所述目标审批事务包括的目标审批服务和所述目标审批服务关联的所有目标应用服务；

相应的，所述调用模块，具体用于：

根据每个目标应用服务的信息，生成所述目标审批服务对应的每个应用服务处理消息；

将所述目标审批服务对应的所有应用服务处理消息依次推送至消息队列中；

利用所述消息队列对应的消息队列服务，调用每个目标应用服务的业务接口对每条应用服务处理消息进行处理，获取每个目标应用服务的服务结果。

可选的，所述调用模块，具体用于周期性的将所述目标审批服务对应的所有应用服务处理消息依次推送至消息队列中；

相应的，所述处理模块，还用于：

确定出所述消息队列中的已成功处理的应用服务处理消息；

剔除掉所述消息队列中的已成功处理的应用服务处理消息。

在第二方面的另一种可能设计中，所述处理模块，还用于在确定所述目标审批服务的审批结果为失败时，中断所述审批处理请求的处理过程；

所述推送模块，还用于向所述终端设备返回审批失败的通知。

在第二方面的再一种可能设计中，所述处理模块，还用于在确定所述目标审批服务关联的所有目标应用服务的服务结果中存在核查错误的服务结果时，执行弃审操作；

所述推送模块，还用于向所述终端设备推送审批失败通知。

根据本申请的第三方面，本申请实施例提供一种审批处理设备，包括处理器、存储器及存储在所述存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面及各种可能设计所述的方法。

根据本申请的第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如上述第一方面及各种可能设计所述的方法。

根据本申请的第五方面，本申请实施例提供一种计算机程序产品，包括：计算机程序，所述计算机程序被处理器执行时用于实现如上述第一方面及各种可能设计所述的方法。

本申请实施例提供的审批处理方法、装置、设备及存储介质，通过获取终端设备的审批处理请求，根据该审批处理请求包括的目标审批事务的标识，确定出目标审批事务包括的目标审批服务和该目标审批服务关联的所有目标应用服务，进而在确定目标审批服务的审批结果为成功时，通过调用消息队列服务，获取每个目标应用服务的服务结果，以及在确定目标审批服务关联的所有目标应用服务的服务结果均为正确时，向终端设备推送审批完成通知。该技术方案中，审批服务和各应用服务的调用是分离的，避免了现有技术中先给出审批服务的结果再进行应用服务处理时出现的需要回退问题，提高了业务处理效率，降低了成本。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1为本申请实施例提供的审批处理方法的应用场景示意图；

图2为本申请提供的审批处理方法实施例一的流程示意图；

图3为本申请提供的审批处理方法实施例二的流程示意图；

图4为图3所示实施例中对应用服务消息进行处理的架构示意图；

图5为本申请实施例提供的审批处理方法实施例三的流程示意图；

图6为本申请提供的审批处理装置实施例的结构示意图；

图7为本申请提供的审批处理设备实施例的结构示意图。

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

首先对本申请实施例所涉及的名词进行解释：

企业资源计划(enterprise resource planning，ERP)系统，是指建立在信息技术基础上，以系统化的管理思想，为企业决策层及员工提供决策运行手段的管理平台。

业务流程管理(business process management，BPM)，是一种以规范化的构造端到端的卓越业务流程为中心，以持续的提高组织业务绩效为目的的系统化方法。通常，BPM也指针对流程管理的信息化系统，其特点是注重流程驱动为核心，实现端到端全流程信息化管理。

现阶段，在企业ERP系统的BPM审批流中，事务审批的很多场景在确定审批服务通过的同时，还需要同时审批服务所关联的应用服务，即需要针对审批服务和应用服务做同步操作的(审批服务与应用服务一体化)。在这种场景下，终端设备在确定调用的BPM审批服务成功后，再进行应用服务自身及其他外部应用服务的同步调用，一旦审批服务或有应用服务失败，则不再继续。当调用的审批服务成功后但某个应用服务失败，还需再次调用BPM审批服务进行逆向操作回退，将BPM审批服务退回到未审批的状态。

上述方案中应用服务与BPM审批服务之间的耦合性及依赖性强，同步操作性能低下，高并发场景下性能会产生瓶颈，而且对于审批服务是一个完整事务，没有履行单一职责原则，而是在有应用服务存在时，去执行审批服务外其他应用服务的调用，包括为保证完整事务，业务应用层需要多次调用其他应用服务的接口进行逆向操作，当同时调用的外部应用服务越多，回滚越复杂、容错性越差，加重了应用业务层的复杂度和开发维护成本。

针对上述类似的分布式微服务架构，通常应用和该应用关联的数据库是拆分开的，这就出现了针对一个应用服务，需要同时访问两个或两个以上的数据库情况。因而，针对上述技术问题，本申请技术方案的技术构思过程如下：采用分布式事务来保证审批服务和应用服务的最终一致性，将需要分布式处理的应用服务通过消息队列的方式异步执行，从而来解决同步执行性能瓶颈，同时将审批服务和应用服务进行分层解耦，通过封装维护BPM中心层及消息队列层统一进行事务一致性的管理，这时，终端设备的业务层只需注册应用服务及对应的事务标识即可，无需再关心完整事务是否一致的问题。

基于上述技术构思过程，本申请实施例提供了一种审批处理方法，通过获取终端设备的审批处理请求，根据该审批处理请求包括的目标审批事务的标识，确定出目标审批事务包括的目标审批服务和该目标审批服务关联的所有目标应用服务，进而在确定目标审批服务的审批结果为成功时，通过调用消息队列服务，获取每个目标应用服务的服务结果，以及在确定目标审批服务关联的所有目标应用服务的服务结果均为正确时，向终端设备推送审批完成通知。该技术方案中，审批服务和各应用服务的调用是分离的，避免了现有技术中先给出审批服务的结果再进行应用服务处理时出现的需要回退问题，提高了业务处理效率，降低了成本。

示例性的，图1为本申请实施例提供的审批处理方法的应用场景示意图。如图1所示，该应用场景可以包括：至少一个终端设备(图1示出了三个终端设备，分别为终端设备111、终端设备112、终端设备113)、网络12和审批处理设备13。其中，每个终端设备与审批处理设备13均可以通过网络12进行通信，使得审批处理设备13可以获取到用户通过终端设备发出的审批处理请求或者每个待审批事务的信息。

示例性的，在图1所示的应用场景中，审批处理设备13可以根据接收到的审批处理请求中携带的目标审批事务的标识，进而确定出目标审批事务包括的目标审批服务和该目标审批服务关联的所有目标应用服务，从而由审批处理设备13的不同层将目标审批服务和关联的所有目标应用服务分离执行。关于具体执行的操作可以由下述实施例给出，此处不作赘述。

在本实施例中，审批处理设备13可以基于获取到的终端设备的审批处理请求，执行本申请提供的审批处理方法的程序代码，以得到针对目标审批事务的审批结果。

可选的，图1所示的应用场景还可以包括数据存储设备14，该数据存储设备14可以与审批处理设备13连接，能够用于存储审批处理设备13的操作日志数据。

需要说明的是，附图1仅是本申请实施例提供的一种应用场景的示意图，本申请实施例不对图1中包括的设备进行限定，也不对图1中设备之间的位置关系进行限定，例如，在图1中，数据存储设备14相对于审批处理设备13可以是外部存储器，在其它情况下，也可以将数据存储设备14置于审批处理设备13中，本申请实施例并不对其进行限定。

在实际应用中，由于终端设备和服务器均是具有数据处理能力的处理设备，因而，上述图1所示应用场景中的审批处理设备既可以通过终端设备实现，也可以通过服务器实现，本申请实施例以审批处理方法的执行主体为审批处理设备进行解释说明。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图2为本申请提供的审批处理方法实施例一的流程示意图。如图2所示，该审批处理方法可以包括如下步骤：

S201、获取终端设备的审批处理请求，该审批处理请求包括：目标审批事务的标识。

在本申请的实施例中，当用户有审批处理的需求时，可以通过终端设备发起审批处理请求，这样审批处理设备对获取到的审批处理请求进行解析，能够获取到目标审批事务的标识，进而有针对性的执行审批处理流程。

可以理解的是，审批处理设备可以同步执行多个不同终端设备的审批处理请求，这样每个审批处理请求中还可以包括发出该审批处理请求的终端设备的标识，以便审批处理设备能够有针对性的返回审批处理结果。本申请实施例并不对审批处理设备能够同时执行的审批处理请求数量进行限定，其可以根据实际场景或实际需要确定，此处不作赘述。

S202、根据目标审批事务的标识，确定出目标审批事务包括的目标审批服务和目标审批服务关联的所有目标应用服务。

在本步骤中，审批处理设备中可以事先注册有多个审批事务的信息，例如，审批事务的标识、审批事务的类型、审批事务的创建时间和修改时间，以及各审批事务关联的至少一个应用服务的信息等，所以，审批处理设备在获取到审批处理请求后，能够基于该审批处理请求中的目标审批事务的标识，确定出目标审批事务包括的目标审批服务和目标审批服务关联的所有目标应用服务。

在实际应用中，对于ERP系统的BPM审批流，由审批处理设备执行目标审批事务的审批操作。可选的，审批处理设备可以包括：BPM中心封装层、消息队列服务层和审批持久化操作层，其中，BPM中心封装层主要用于与终端设备的应用业务层进行对接，获取应用服务的注册请求，消息队列服务层用于对目标审批事务对应的应用服务进行处理，审批持久化操作层用于执行审批服务的操作。

因而，在本申请的实施例中，由审批处理设备的审批持久化操作层目标审批事务的标识确定目标审批服务，而由消息队列服务层根据目标审批事务的标识确定目标审批服务关联的所有目标应用服务。

S203、判断目标审批服务的审批结果是否为成功，若是，则执行S204；若否，则执行S208和S209。

在本申请的实施例中，审批处理设备确定出目标审批事务包括的目标审批服务后，可以通过BPM中心封装层调用审批持久化操作层，在审批持久化操作层对该目标审批服务执行审批操作，并得到该目标审批服务的审批结果。

可选的，由于ERP系统的BPM审批操作，首先需要保证审批服务成功，然后再确定是否需要调用应用服务的业务接口。因而，在本步骤中，审批处理设备的审批持久化操作层得到目标审批服务的审批结果后，可以判断该审批结果是否为成功，然后根据判断结果，向BPM中心封装层返回后续可执行的操作流程。

S204、通过调用消息队列服务，获取每个目标应用服务的服务结果。

作为一种示例，在审批处理设备的审批持久化操作层确定目标审批服务的审批结果为成功时，则可以向BPM中心封装层发送审批成功的通知，使得该BPM中心封装层将目标审批服务的状态修改为“已审批”，同时通过调用消息队列服务，由消息队列服务异步执行每个应用服务，得到每个目标应用服务的服务结果。

关于该步骤的具体实现可以参见下述实施例中的记载，此处不作赘述。

S205、判断目标审批服务关联的所有目标应用服务的服务结果是否均为正确，若是，则执行S206；若否，则执行S207和S209。

在本申请的实施例中，由于ERP系统的BPM审批操作，需要同时保证审批服务成功且该目标审批服务关联的所有目标应用服务成功，因而，在本步骤中，审批处理设备的消息队列服务层得到目标审批服务关联的所有目标应用服务的服务结果后，可以判断每个目标应用服务的服务结果是否为成功，然后根据判断结果，向BPM中心封装层返回最终的审批结果，进而回调给终端设备的应用服务层。

S206、向终端设备推送审批完成通知。

作为一种示例，在审批处理设备的消息队列服务层目标审批服务关联的所有目标应用服务均正确(或成功)时，便可以向审批处理设备的BPM中心封装层返回所有目标应用服务的处理结果，将目标审批事务的状态修改为“审批完成”，进而将目标审批事务的审批结果回调给终端设备，并向终端设备推送审批完成通知。

S207、执行弃审操作。

在本申请实施例的一种可能设计中，在审批处理设备的消息队列服务层确定目标审批服务关联的所有目标应用服务中存在错误(或失败)的服务结果时，这时，消息队列服务层会向审批处理设备的审批持久化操作层发送弃审指示，使得审批持久化操作层执行弃审操作，并直接将审批操作的结果返回给BPM中心封装层，使得BPM中心封装层向终端设备推送审批失败通知。

S208、中断审批处理请求的处理过程。

在本申请的一种可能设计中，在审批处理设备的审批持久化操作层确定目标审批服务的审批结果为失败时，无需执行后续应用服务的处理过程，则可以直接向BPM中心封装层发送中断指示的通知，使得该BPM中心封装层中断该审批处理请求的处理过程，并向终端设备推送失败通知。

S209、向终端设备推送审批失败通知。

示例性的，在目标审批服务的审批结果为失败或者目标审批服务关联的所有目标应用服务中存在错误(或失败)的服务结果时，表明目标审批事务的审批结果为失败，可以直接向终端设备推送该审批失败通知，以便终端设备将审批结果展示给用户。

可选的，该审批失败通知中还可以包括：审批失败的位置、审批失败的具体原因等，本申请实施例不对审批失败通知中的具体内容进行限定，其可以根据实际场景确定，此处不作赘述。

本申请实施例提供的审批处理方法，通过获取终端设备的审批处理请求，根据该审批处理请求包括的目标审批事务的标识，确定出目标审批事务包括的目标审批服务和该目标审批服务关联的所有目标应用服务，进而在确定目标审批服务的审批结果为成功时，通过调用消息队列服务，获取每个目标应用服务的服务结果，以及在确定目标审批服务关联的所有目标应用服务的服务结果均为正确时，向终端设备推送审批完成通知。该技术方案中，审批服务和各应用服务的调用是分离的，避免了现有技术中先给出审批服务的结果再进行应用服务处理时出现的需要回退问题，提高了业务处理效率，降低了成本。

示例性的，在上述实施例的基础上，图3为本申请提供的审批处理方法实施例二的流程示意图。如图3所示，在上述S201之前，该审批处理方法还可以包括如下步骤：

S301、获取至少一个待审批事务的信息。

其中，至少一个待审批事务包括：上述目标审批事务，每个待审批事务的信息包括：待审批服务的信息和所述待审批服务关联的至少一个应用服务的信息。

在本申请的实施例中，当企业的各个部门(例如，生产部门、管理部门、采购部门、财务部门等)基于实际场景需求生成待审批事务时，通常会将其传输至审批处理设备中，以便对应的领导通过终端设备进行审批处理。

可选的，正式生成的待审批事务会被存储至审批处理设备中，因而，审批处理设备可以获取到至少一个待审批事务的信息。通常情况下，每个待审批事务可以包括待审批服务的信息以及待审批服务关联的至少一个应用服务的信息。

其中，待审批服务的信息可以包括：待审批服务的标识、待审批服务的类型、待审批服务的时间信息，待审批服务关联的至少一个应用服务的信息可以包括：应用服务的类型信息、数值信息、时间信息等。本申请实施例并不对待审批服务的信息和待审批服务关联的至少一个应用服务的信息的具体内容进行限定，其可以根据实际需求确定，此处不作赘述。

S302、根据每个待审批事务的信息，生成每个待审批事务对应的服务注册信息。

在本步骤中，审批处理设备获取到每个待审批事务的信息后，为了便于后续的审批处理，首先可以根据待审批事务的信息，生成每个待审批事务对应的服务注册信息，这样在后续接收到审批处理请求时，无需通过终端设备的业务应用层，也可以根据审批处理请求中的待审批事务的标识，定位出待审批事务包括的待审批服务以及待审批服务关联的至少一个应用服务。

S303、根据每个待审批事务对应的服务注册信息，生成并存储已注册服务信息表。

可选的，审批处理设备(具体可以是BPM中心封装层)可以将每个待审批事务的服务注册信息整合成服务信息表的形式。例如，在本实施例中，审批处理设备可以事先生成一个已注册服务信息表，进而在获取到每个待审批事务对应的服务注册信息后，将其存储至该已注册服务信息表中，并对其进行更新。

示例性的，表1为生成的BMP服务注册表。如表1所示，该表中示出了BMP服务注册表的部分信息，可选的，BMP服务注册表中的注册内容主要包括待审批服务以及待审批服务关联的应用服务等。

其中，ID：待审批事务的标识，也称为为主键ID，数据类型是可变长字符串(varchar)，长度为36字节；

Operationtype：审批服务的操作类型，目前，可以包括审批同意(例如，用0表示)、弃审(例如，用1表示)、审批不通过且退回(例如，用2表示)，数据类型为整型(Int)，长度为10字节；

billtypeid：单据类型Id，即待审批事务的类型，例如，合同单、采购单、出库单等，数据类型是可变长字符串(varchar)，长度为36字节；

url：审批服务后续操作的应用服务，或，修改单据状态的应用服务，也称为业务的url(不需要ip和端口号)，数据类型是可变长字符串(varchar)，长度为200字节；

rollbackurl：请求url失败后，回滚的应用服务，也称为回滚的url(不需要ip和端口号)，数据类型是可变长字符串(varchar)，长度为200字节；

state_flag：标识位，用于区分是审批后续操作，或者是修改单据类型审批状态，主要包括0(正常请求)、1(回执)；

creationtime：创建时间，lastmodifiedtime：最后一次修改时间，两者用于表征待审批事务的时间信息。

可以理解的是，上述表1仅示出了BPM服务注册表的部分信息，关于具体包括的其他信息可以根据实际场景确定，此处不作赘述。

在上述各步骤的基础上，如图3所示，在本申请的实施例中，上述S202可以通过如下步骤实现：

S304、根据目标审批事务的标识，查询已注册服务信息表，确定出目标审批事务包括的目标审批服务和目标审批服务关联的所有目标应用服务。

在本步骤中，审批处理设备对获取到的审批处理请求进行解析，能够获取到目标审批事务的标识，由于已注册服务信息表中包括上述目标审批事务的信息，因而，通过查询已注册服务信息表，能够在已注册服务信息表中定位到目标审批事务，从而确定出目标审批事务包括的目标审批服务和目标审批服务关联的所有目标应用服务。

相应的，上述S204可以通过如下步骤实现：

S305、根据每个目标应用服务的信息，生成目标审批服务对应的每个应用服务处理消息。

可选的，审批处理设备确定出目标审批服务关联的所有目标应用服务后，可以根据在已注册服务信息表中获取到的每个目标应用服务的信息，生成目标审批服务对应的每个应用服务处理消息，以便能够将其推送至消息队列中由消息队列服务进行处理。

S306、将目标审批服务对应的所有应用服务处理消息依次推送至消息队列中。

可选的，为了实现消息队列服务异步执行目标审批服务关联的各个应用服务，审批处理设备在生成目标审批服务对应的每个应用服务处理消息后，可以按照一定的顺序，将每个应用服务处理消息推送至消息队列中，以便消息队列服务能够对其异步执行，避免了多个应用服务同步执行时具有的性能瓶颈。

S307、利用消息队列对应的消息队列服务，调用每个目标应用服务的业务接口对每条应用服务处理消息进行处理，获取每个目标应用服务的服务结果。

可选的，消息队列服务层是审批处理设备中独立部署的一个层，其能够用于统一管理服务的调用处理过程。因而，在本申请的实施例中，审批处理设备可以基于软件开发工具包(software development kit，SDK)开发的消息队列服务，通过在开发代码在发起服务调用，从而调用每个目标应用服务的业务接口对每条应用服务处理消息进行处理，获取每个目标应用服务的服务结果。

可以理解的是，在本实施例中，消息队列服务层中需要配置定时任务、回执接收接口和消息队列服务地址，这样消息队列服务在确定消息队列中有待处理的应用服务处理消息时，能够自动调用每个应用服务的业务接口，以对应用读物处理消息进行处理，得到每个目标应用服务的服务结果。

在本申请的一种可能设计中，该步骤S306具体可以通过如下步骤实现：

周期性的将目标审批服务对应的所有应用服务处理消息依次推送至消息队列中。

在实际应用中，为了最大程度的提高审批成功率，审批处理设备可以利用定时装置周期性的将获取到目标审批服务对应的所有应用服务处理消息推送至消息队列中，以便消息队列服务可以针对未处理成功的应用服务再次进行处理，在实现自动处理的同时，提高处理成功率。

相应的，在S307之前，该审批处理方法还可以包括如下步骤：

确定出消息队列中的已成功处理的应用服务处理消息，并剔除掉消息队列中的已成功处理的应用服务处理消息。

可选的，当审批处理设备周期性的将目标审批服务对应的所有应用服务处理消息依次推送至消息队列中时，消息队列中则很大可能存在重复的应用服务消息，这时为了避免对应用服务处理消息被重复处理，则对消息队列中的应用服务消息进行处理之前，首先判断进入消息队列中的应用服务处理消息是否是已成功处理的应用服务处理消息；若是，将其剔除掉，若否，执行上述S307。

示例性的，图4为图3所示实施例中对应用服务消息进行处理的架构示意图。如图4所示，在本申请的实施例中，BPM中心封装层可以包括：日志记录装置、定时发送装置和回执处理装置。其中，日志记录装置用于记录BPM中心封装层的相关日志信息，例如，基于获取到的待审批事务的信息生成已注册服务信息表等，定时发送装置用于周期性的将生成的应用服务处理消息推送至消息队列服务层的消息队列等，回执处理装置用于从消息队列服务层接收各应用服务的服务结果，并将其传输给日志记录装置。

消息队列服务层可以包括：消息接收装置、消息队列管理装置、重复检测装置、服务调用装置、回执发送装置和消息日志记录装置等。其中，消息接收装置用于从BPM中心封装层的定时发送装置接收应用服务处理消息；消息队列管理装置用于管理不同应用服务使用的消息队列，例如，kafka的管理端用于管理使用kafka的所有应用服务处理消息；重复检测装置用于检测从消息队列中输出的应用服务处理消息是否是已成功处理的应用服务处理消息，若是，则删除，不再调用服务调用装置进行处理，而能够对调用异常的应用服务消息，例如，服务宕机、网络失败进行处理。服务调用装置用于调用应用服务系统的业务接口，对待处理的应用服务处理消息进行处理，一方面将得到的各个应用服务的服务结果发送给回执发送装置，回执发送装置再将各个应用服务的服务结果返回给BPM中心封装层的回执处理装置，另一方面，服务调用装置和回执发送装置还可以将处理的日志信息记录到消息日志记录装置中。

进一步的，在本申请的实施例中，当消息队列服务通过服务调用装置调用应用服务系统的业务接口进行应用服务处理消息处理时，应用服务系统的调用处理装置也会获取到相关的调用处理信息，并将生成的调用信息存储至调用日志记录装置中，以便后续的查看。

本申请实施例提供的审批处理方法，采用注册应用服务、消息队列服务处理机制对目标审批事务进行处理，能够保证目标审批事务的目标审批服务和目标应用服务的一致性和数据的幂等性，提高了业务处理效率、降低了维护成本。

进一步的，在上述实施例的基础上，图5为本申请实施例提供的审批处理方法实施例三的流程示意图。该方法以终端设备和审批处理设备之间的信息交互进行解释说明。可选的，终端设备可以包括应用业务层，审批处理设备可以包括：BPM中心封装层、消息队列服务层和审批持久化操作层。

如图5所示，假设某个待审批事务包括应用服务A、应用服务B和应用服务C，则终端设备可以通过该应用业务层向BPM中心封装层发起注册应用服务的过程，即将应用服务A、应用服务B和应用服务C分别注册到审批处理设备的BPM中心封装层，然后再调用审批持久化操作层执行审批服务的操作。

作为一种示例，在审批结果为“否”时，向BPM中心封装层返回中断，以使其返回应用业务层，输出审批失败的通知。

作为另一种示例，在审批结果为“是”时，向BPM中心封装层返回已审批的通知，即BPM中心封装层可以将审批状态修改为“已审批”，并调用消息队列的SDK，从而在消息队列服务层中，基于SDK根据待审批事务的标识，确定出待审批事务关联的应用服务，并对其进行分组，将待审批事务关联的应用服务推送至消息队列中，由消息队列服务层异步执行应用服务，输出应用服务结果。

可选的，在应用服务结果为“是”时，使得BPM中心封装层将应用服务结果回调给应用，并更改状态为“审批完成”；在应用服务结果为“否”时，由审批持久化操作层执行弃审操作，并返回给BPM中心封装层，使得BPM中心封装层获取到审批失败的结果，并返回给终端设备的应用业务层。

本申请实施例中，审批事务一致性的方案通过配置注册应用服务的信息，并调用统一的消息队列服务对BPM中心封装层进行封装维护，解决了微服务架构下审批服务与应用服务一体化的问题，基于微服务架构的应用一般都可以使用SQL和NoSQL结合的模式，解决了传统的2PC分布式事务处理不支持非关系型数据的难题，通过预设业务规则或重试方案保证任务的最终执行，保证事物的最终一致性。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图6为本申请提供的审批处理装置实施例的结构示意图。参照图6所示，该审批处理装置可以包括：

获取模块601，用于获取终端设备的审批处理请求，所述审批处理请求包括：目标审批事务的标识；

处理模块602，用于根据所述目标审批事务的标识，确定出所述目标审批事务包括的目标审批服务和所述目标审批服务关联的所有目标应用服务；

调用模块603，用于在确定所述目标审批服务的审批结果为成功时，通过调用消息队列服务，获取每个目标应用服务的服务结果；

推送模块604，用于在确定所述目标审批服务关联的所有目标应用服务的服务结果均为正确时，向所述终端设备推送审批完成通知。

在本申请实施例的一种可能设计中，所述获取模块601，还用于获取至少一个待审批事务的信息，所述至少一个待审批事务包括：所述目标审批事务，每个待审批事务的信息包括：待审批服务的信息和所述待审批服务关联的至少一个应用服务的信息；

所述处理模块602，还用于：

根据每个待审批事务的信息，生成每个待审批事务对应的服务注册信息；

根据每个待审批事务对应的服务注册信息，生成并存储已注册服务信息表。

可选的，所述处理模块602，具体用于根据所述目标审批事务的标识，查询所述已注册服务信息表，确定出所述目标审批事务包括的目标审批服务和所述目标审批服务关联的所有目标应用服务；

相应的，所述调用模块603，具体用于：

根据每个目标应用服务的信息，生成所述目标审批服务对应的每个应用服务处理消息；

将所述目标审批服务对应的所有应用服务处理消息依次推送至消息队列中；

利用所述消息队列对应的消息队列服务，调用每个目标应用服务的业务接口对每条应用服务处理消息进行处理，获取每个目标应用服务的服务结果。

可选的，所述调用模块603，具体用于周期性的将所述目标审批服务对应的所有应用服务处理消息依次推送至消息队列中；

相应的，所述处理模块602，还用于：

确定出所述消息队列中的已成功处理的应用服务处理消息；

剔除掉所述消息队列中的已成功处理的应用服务处理消息。

在本申请实施例的另一种可能设计中，所述处理模块602，还用于在确定所述目标审批服务的审批结果为失败时，中断所述审批处理请求的处理过程；

所述推送模块604，还用于向所述终端设备返回审批失败的通知。

在本申请实施例的再一种可能设计中，所述处理模块602，还用于在确定所述目标审批服务关联的所有目标应用服务的服务结果中存在核查错误的服务结果时，执行弃审操作；

所述推送模块604，还用于向所述终端设备推送审批失败通知。

本申请实施例提供的装置，可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，在此不再赘述。

需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。例如，处理模块可以为单独设立的处理元件，也可以集成在上述装置的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上处理模块的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘solid state disk(SSD))等。

图7为本申请提供的审批处理设备实施例的结构示意图。如图7所示，该审批处理设备可以包括：处理器701、存储器702、收发器703及存储在存储器702上并可在处理器701上运行的计算机程序，处理器701执行所述计算机程序时实现如上述方法实施例的技术方案。

可选的，在本实施例中，收发器703用于和其他设备进行通信。该审批处理设备还可以包括系统总线704。存储器702和收发器703通过系统总线704与处理器701连接并完成相互间的通信

可选的，上述的处理器可以是通用处理器，包括中央处理器CPU、网络处理器(network processor，NP)等；还可以是数字信号处理器DSP、专用集成电路ASIC、现场可编程门阵列FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

存储器可能包含随机存取存储器(random access memory，RAM)，也可能包括只读存储器(read-only memory，RAM)，还可能包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

收发器也可以称为通信接口，用于实现数据库访问装置与其他设备(例如客户端、读写库和只读库)之间的通信。

系统总线可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。系统总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

可选的，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当该计算机执行指令在计算机上运行时，使得计算机执行如上述方法实施例的技术方案。

可选的，本申请实施例提供一种计算机程序产品，包括：计算机程序，所述计算机程序存储在可读存储介质中，审批处理设备的至少一个处理器可以从所述可读存储介质读取所述计算机程序，所述至少一个处理器执行所述计算机程序使得审批处理设备执行上述方法实施例的技术方案。

本领域技术人员在考虑说明书及实践这里公开的申请后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求书指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求书来限制。