一种业务流程执行方法及相关装置与流程

本申请涉及计算机技术领域，特别涉及一种业务流程执行方法、业务流程执行系统、服务器以及计算机可读存储介质。

背景技术：

随着信息技术的不断发展，在实际应用的环境中通过信息技术实现流程的管控，例如管理流程、控制流程或生成流程，可以极大的提升流程管理的效率，提高工作环境中的工作效率。因此，就出现了一种常用的流程管理架构，就是通过流程定义文件自定义化流程，再通过流程引擎执行流程定义文件以实现流程中定义的相关功能。并且流程引擎中通常包括流程引擎和对应的流程服务，在执行中是通过流程引擎调用相应的流程服务以实现流程定义文件中的功能。

现有技术中，通常把流程定义文件和流程引擎打包在同一个工程里，也就是在执行业务流程时，所有文件均在同一个工程中，并且流程引擎也是以程序接口的形式直接调用业务代码逻辑。而此时如果需要修改流程定义文件或修改业务逻辑代码就需要对整个工程进行处理，造成不必要的麻烦，降低整体业务流程维护的效率。

因此，如何提高流程执行时的可维护性是本领域技术人员关注的重点问题。

技术实现要素：

本申请的目的是提供一种业务流程执行方法、业务流程执行系统、服务器以及计算机可读存储介质，通过生成的流程定义脚本实现流程定义文件和流程引擎之间相互解耦，再通过流程引擎的代理类去调用业务逻辑代码，实现了对流程引擎和业务逻辑代码进行解耦，此时如果需要修改流程定义文件或修改业务逻辑代码，就可以在不修改整体工程的情况下进行修改，提高了业务流程维护的效率，提高了可维护性。

为解决上述技术问题，本申请提供一种业务流程执行方法，包括：

对流程定义文件进行脚本生成处理，得到流程定义脚本；

通过流程引擎执行所述流程定义脚本；

当执行到所述流程定义脚本的节点时，通过所述流程引擎的代理类调用所述节点对应的业务逻辑代码的restful接口，得到返回数据，以便继续执行所述流程定义脚本直至完成对业务流程的执行操作。

可选的，对流程定义文件进行脚本生成处理，得到流程定义脚本，还包括：

将所述流程定义脚本保存到数据库中；

相应的，通过流程引擎执行所述流程定义脚本，包括：

从所述数据库中获取到所述流程定义脚本，并通过所述流程引擎执行所述流程定义脚本。

可选的，对流程定义文件进行脚本生成处理，得到流程定义脚本，包括：

将所有流程定义文件进行打包处理，得到压缩包；

对所述压缩包进行脚本生成处理，得到所述流程定义脚本。

可选的，当流程引擎执行所述流程定义脚本之前，还包括：

根据restful协议对所述流程引擎的调用接口进行代理类封装处理，得到所述代理类。

可选的，当流程引擎执行所述流程定义脚本之前，还包括：

对业务逻辑代码进行业务工程打包处理，得到业务微服务；

根据restful协议将所述业务微服务的程序接口封装为restful接口。

本申请还提供一种业务流程执行系统，包括：

脚本获取模块，用于对流程定义文件进行脚本生成处理，得到流程定义脚本；

脚本执行模块，用于通过流程引擎执行所述流程定义脚本；

业务逻辑调用模块，用于当执行到所述流程定义脚本的节点时，通过所述流程引擎的代理类调用所述节点对应的业务逻辑代码的restful接口，得到返回数据，以便继续执行所述流程定义脚本直至完成对业务流程的执行操作。

可选的，所述脚本获取模块，包括：

打包处理单元，用于将所有流程定义文件进行打包处理，得到压缩包；

脚本生成单元，用于对所述压缩包进行脚本生成处理，得到所述流程定义脚本。

可选的，还包括：

代理类封装模块，用于当流程引擎执行所述流程定义脚本之前，根据restful协议对所述流程引擎的调用接口进行代理类封装处理，得到所述代理类。

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

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如上所述的业务流程执行方法的步骤。

本申请还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的业务流程执行方法的步骤。

本申请所提供的一种业务流程执行方法，包括：对流程定义文件进行脚本生成处理，得到流程定义脚本；通过流程引擎执行所述流程定义脚本；当执行到所述流程定义脚本的节点时，通过所述流程引擎的代理类调用所述节点对应的业务逻辑代码的restful接口，得到返回数据，以便继续执行所述流程定义脚本直至完成对业务流程的执行操作。

通过在流程引擎之外就生成相应的流程定义脚本，使流程引擎直接执行脚本，避免了在流程引擎中包含流程定义文件，也就是通过流程定义脚本的方式向流程引擎传递流程定义文件的内容，再通过流程引擎的代理类去调用业务逻辑代码，实现了对流程引擎和业务逻辑代码进行解耦，此时如果需要修改流程定义文件或修改业务逻辑代码，就可以在不修改整体工程的情况下进行修改，提高了业务流程维护的效率，提高了可维护性。

本申请还提供一种业务流程执行系统、服务器以及计算机可读存储介质，具有以上有益效果，在此不做赘述。

附图说明

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

图1为本申请实施例所提供的一种业务流程执行方法的流程图；

图2为本申请实施例所提供的一种业务流程执行系统的结构示意图。

具体实施方式

本申请的核心是提供一种业务流程执行方法、业务流程执行系统、服务器以及计算机可读存储介质，通过生成的流程定义脚本实现流程定义文件和流程引擎之间相互解耦，再通过流程引擎的代理类去调用业务逻辑代码，实现了对流程引擎和业务逻辑代码进行解耦，此时如果需要修改流程定义文件或修改业务逻辑代码，就可以在不修改整体工程的情况下进行修改，提高了业务流程维护的效率，提高了可维护性。

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

现有技术中是将流程定义文件和业务逻辑代码都放在同一个工程中再执行相应的业务流程，也就是在执行的过程中流程引擎直接读取流程定义文件的内容，并执行，再流程引擎的内部直接以调用程序接口的方式调用业务逻辑代码。但是在这种执行方式下，如果需要修改流程定义文件或修改业务逻辑代码就需要对整个工程进行处理，造成不必要的麻烦，降低整体业务流程维护的效率，可维护性极低。

因此，本实施例提供一种业务流程执行方法，通过在流程引擎之外就生成相应的流程定义脚本，使流程引擎直接执行脚本，避免了在流程引擎中包含流程定义文件，也就是通过流程定义脚本的方式向流程引擎传递流程定义文件的内容，再通过流程引擎的代理类去调用业务逻辑代码，实现了对流程引擎和业务逻辑代码进行解耦，此时如果需要修改流程定义文件或修改业务逻辑代码，就可以在不修改整体工程的情况下进行修改，提高了业务流程维护的效率，提高了可维护性。

具体的，请参考图1，图1为本申请实施例所提供的一种业务流程执行方法的流程图。

该方法可以包括：

s101，对流程定义文件进行脚本生成处理，得到流程定义脚本；

本旨在对流程定义文件先在流程引擎之外生成相应的流程定义脚本。

其中，流程定义文件是技术人员对流程输入的相关的定义文件，该文件具有一定的定义格式，通过流程引擎可以实现相应的流程功能。而现有技术中一般是将流程定义文件直接导入到流程引擎中进行执行，此时必要就是将流程定义文件与流程引擎打包在同一个工程中。本步骤中在业务流程执行的过程中不需要将流程定义文件输入到流程引擎中，而是对流程定义文件进行脚本生成处理，得到流程定义脚本。

也就是以流程定义脚本的方式将流程定义文件的内容传递到流程引擎中。流程引擎可以对流程定义脚本直接进行读取，而不需要进行其他的处理。

进一步的，本步骤中进行的脚本生成处理是将流程定义文件转化成机器可读的脚本文件，即流程定义脚本。其中，本步骤具体可以采用现有技术提供的任意一种脚本生成处理，在此不做具体限定。

可选的，本步骤可以包括：

步骤一、将所有流程定义文件进行打包处理，得到压缩包；

步骤二、对压缩包进行脚本生成处理，得到流程定义脚本。

本可选方案中主要是通过压缩包的形式将流程定义文件进行脚本生成处理，得到流程定义脚本。主要是因为在实际使用过程中有多个流程定义文件，此时需要将多个流程定义文件生成相应的压缩包，再统一对该压缩包进行脚本生成处理，得到流程定义脚本。

s102，通过流程引擎执行流程定义脚本；

在步骤s101的基础上，本步骤旨在通过流程引擎执行上一步骤得到的流程定义脚本。由于流程定义脚本是引擎可以直接读取的文件，因此本步骤中可以使流程引擎直接执行流程定义脚本。

在此，需要说明的是，流程定义脚本中存在多个节点需要执行相应的服务，也就是业务逻辑代码。

s103，当执行到流程定义脚本的节点时，通过流程引擎的代理类调用节点对应的业务逻辑代码的restful接口，得到返回数据，以便继续执行流程定义脚本直至完成对业务流程的执行操作。

在步骤s102的基础上，本步骤旨在当执行到流程定义脚本的节点时，执行流程引擎中的代理类，通过代理类调用业务逻辑代码的接口。具体的，本步骤中是在流程引擎中统一封装出相应的代理类，用于统一调用业务逻辑代码。同时，业务逻辑代码的接口统一封装为restful协议的restful接口。在该基础上，本步骤中通过该代理类调用节点对应的业务逻辑代码的restful接口，得到返回数据。

总的来说，本实施例是在业务流程执行的过程中实现业务流程执行中的流程定义文件、流程引擎以及业务逻辑代码之间的相互解耦。也就是上述过程中对流程定义文件进行脚本生成处理，得到流程定义脚本，实现流程定义文件和流程引擎之间的相互解耦。另一方面通过流程引擎的代理类调用业务逻辑代码的restful接口，实现流程引擎和业务逻辑代码之间的相互解耦。通过以上两个方面总体就实现了流程引擎与流程定义代码、业务逻辑代码之间的相互解耦。

进一步的，在流程引擎与流程定义文件、业务逻辑代码相互解耦之后，在业务流程执行的过程中也可以对流程定义文件和业务逻辑代码进行相应的维护操作，而不需要对流程引擎的工程进行改动，提高了业务流程执行过程中的可维护性。

可选的，s101还可以包括：

将流程定义脚本保存到数据库中；

相应的，s102包括：

从数据库中获取到流程定义脚本，并通过流程引擎执行流程定义脚本。

本可选方案中具体说明了本实施例中当得到流程定义脚本后，是通过数据库的方式将流程定义脚本的数据传递到流程引擎中。具体的就是将流程定义脚本保存在数据库中，在流程引擎执行的过程中从数据库获取到该流程定义脚本。在实际应用的过程中，只需要流程引擎不断监控数据库即可获取到流程定义脚本的内容，此时如果对流程定义脚本进行修改，只需要将修改后的流程定义脚本重新传送到该数据库中即可，提高了流程定义文件到流程引擎之间的可维护性。

综上，本实施例通过在流程引擎之外就生成相应的流程定义脚本，使流程引擎直接执行脚本，避免了在流程引擎中包含流程定义文件，也就是通过流程定义脚本的方式向流程引擎传递流程定义文件的内容，再通过流程引擎的代理类去调用业务逻辑代码，实现了对流程引擎和业务逻辑代码进行解耦，此时如果需要修改流程定义文件或修改业务逻辑代码，就可以在不修改整体工程的情况下进行修改，提高了业务流程维护的效率，提高了可维护性。

在上一实施例的基础上，本申请实施例还提供一种更加具体的对业务流程执行过程进行解耦的方法。

该方法具体内容如下：

当流程引擎对流程定义脚本进行执行之前还包括：

根据restful协议对流程引擎的调用接口进行代理类封装处理，得到代理类。

以及，对业务逻辑代码进行业务工程打包处理，得到业务微服务；根据restful协议将业务微服务的程序接口封装为restful接口。

通过该方法流程引擎可以通过代理类调用业务逻辑代码的restful接口，实现流程引擎对业务逻辑代码的调用。并且通过本实施例流程引擎与业务逻辑代码之间相互解耦，当需要对流程引擎或业务逻辑代码之间的任一方进行维护，不会影响到剩余的一方，提高了整体工程的可维护性。

其中，代理类可以通过设置统一参数的方式，配置restful接口协议中的定义的几个固定参数值。

具体来说，本实施例中将业务逻辑代码单独放在一个业务工程中，独立成业务微服务，对应的应用程序接口根据restful协议封装成restful协议接口；流程引擎代码独立于易变的业务逻辑代码和流程定义文件，单独打包为流程引擎微服务，对调用业务的restful接口进行统一代理封装成代理类，该代理类能够通过节点定义的restful接口调用业务代码逻辑；流程定义文件通过单独的流程引擎所在的开发环境生成对应的流程定义脚本，将脚本导入到对应的环境中，流程定义文件以数据库脚本的方式从流程引擎中分离出来；流程引擎通过统一封装代理类restful接口方式调用业务代码逻辑；流程引擎通过直接加载数据库中流程定义脚本的方式来读取流程定义文件；通过上述步骤就能够实现在微服务架构下业务和流程引擎的完全解耦，各自由不同开发团队进行开发运维，提升了引擎服务的通用性，降低了应用升级的风险及团队的沟通成本。

本申请实施例提供了一种业务流程执行过程进行解耦的方法，可以通过在流程引擎之外就生成相应的流程定义脚本，使流程引擎直接执行脚本，避免了在流程引擎中包含流程定义文件，也就是通过流程定义脚本的方式向流程引擎传递流程定义文件的内容，再通过流程引擎的代理类去调用业务逻辑代码，实现了对流程引擎和业务逻辑代码进行解耦，此时如果需要修改流程定义文件或修改业务逻辑代码，就可以在不修改整体工程的情况下进行修改，提高了业务流程维护的效率，提高了可维护性。

下面对本申请实施例提供的一种业务流程执行系统进行介绍，下文描述的一种业务流程执行系统与上文描述的一种业务流程执行方法可相互对应参照。

请参考图2，图2为本申请实施例所提供的一种业务流程执行系统的结构示意图。

该系统可以包括：

脚本获取模块100，用于对流程定义文件进行脚本生成处理，得到流程定义脚本；

脚本执行模块200，用于通过流程引擎执行流程定义脚本；

业务逻辑调用模块300，用于当执行到流程定义脚本的节点时，通过流程引擎的代理类调用节点对应的业务逻辑代码的restful接口，得到返回数据，以便继续执行流程定义脚本直至完成对业务流程的执行操作。

可选的，该脚本获取模块100，可以包括：

打包处理单元，用于将所有流程定义文件进行打包处理，得到压缩包；

脚本生成单元，用于对压缩包进行脚本生成处理，得到流程定义脚本。

可选的，该系统还可以包括：

代理类封装模块，用于当流程引擎执行流程定义脚本之前，根据restful协议对流程引擎的调用接口进行代理类封装处理，得到代理类。

本申请实施例还提供一种服务器，包括：

存储器，用于存储计算机程序；

处理器，用于执行计算机程序时实现如以上实施例的业务流程执行方法的步骤。

本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如以上实施例的业务流程执行方法的步骤。

该计算机可读存储介质可以包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

以上对本申请所提供的一种业务流程执行方法、业务流程执行系统、服务器以及计算机可读存储介质进行了详细介绍。本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。