CN110032571A - 业务流程处理方法、装置、存储介质及计算设备 - Google Patents

Abstract

本申请提供的一种业务流程处理方法、装置、存储介质及计算机设备，使用第一数据库缓存未结束的业务流程实例的实例数据，使用第二数据库存储已结束的业务流程实例的实例数据，实现了内存空间的动态伸缩，避免了所有实例数据都缓存在第一数据库，占用第一数据库的存储空间，影响其他业务流程实例的正常工作；同时，对于已经结束的业务流程实例，当需要查阅其实例数据时，直接对第二数据库进行读取操作即可，减少了对第一数据库的访问次数，提高了写服务的可用性；而且，因第一数据库的高并发处理能力，本申请实现了业务流程实例的实例数据高并发的同时，保证了数据的一致性。

Description

业务流程处理方法、装置、存储介质及计算设备

技术领域

本申请涉及通信技术领域，具体涉及一种无业务流程处理方法、装置、存储介质及计算机设备。

背景技术

工程流引擎是指workflow作为应用系统的一部分，并为之提供对各应用系统有决定作用的，根据角色、分工和条件的不同决定信息，传递路由、内容等级等核心解决方案。工作流引擎通常包括流程的节点管理、流向管理、流程样例管理等重要功能。

目前，常用的工作流引擎有K2、Activiti等，都属于基础数据库事务操作模式的工作流引擎，因此，受数据库的并发处理能力的限制，现有的这种工作流引擎的并发处理能力一般，如图1所示的K2工作流引擎在不同场景下，每秒处理数据量，从图1所示表格的最后一列可以直接看出，并行处理性能较差，每秒事务处理数据很低。

发明内容

本申请实施例提供一种业务流程处理方法、装置、存储介质及计算机设备，实现了业务流程实例的实例数据的高并发的同时，保证了数据的一致性，且采用两种数据库存储不同状态下的实例数据，实现了内存空间的动态伸缩。

为实现上述目的，本申请实施例提供如下技术方案：

一种业务流程处理方法，所述方法包括：

检测业务流程实例中各节点的实例状态；

在所述实例状态表明所述业务流程实例未结束的情况下，将所述业务流程实例的实例数据缓存至第一数据库；

在所述实例状态表明所述业务流程实例结束的情况下，将所述第一数据库缓存的所述业务流程实例的实例数据同步至第二数据库，并删除所述第一数据库缓存的所述业务流程实例的实例数据。

一种业务流程处理装置，所述装置包括：

检测模块，用于检测业务流程实例中各节点的实例状态；

第一存储模块，用于在所述实例状态表明所述业务流程实例未结束的情况下，将所述业务流程实例的实例数据缓存至第一数据库；

第二存储模块，用于在所述实例状态表明所述业务流程实例结束的情况下，将所述第一数据库缓存的所述业务流程实例的实例数据同步至第二数据库，并删除所述第一数据库缓存的所述业务流程实例的实例数据。

一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行，实现如上所述的业务流程处理方法的各步骤。

一种计算机设备，所述计算机设备包括：

通信接口；

存储器，用于存储实现如上所述的业务流程处理方法的计算机程序；

处理器，用于记载并执行所述存储器存储的计算机程序，所述计算机程序用于实现如上所述的业务流程处理方法的各个步骤。

基于上述技术方案，本申请实施例提供的一种业务流程处理方法、装置、存储介质及计算机设备，本实施例可以使用第一数据库缓存未结束的业务流程实例的实例数据，使用第二数据库存储已结束的业务流程实例的实例数据，通过这种定时将第一数据库中流程结束的实例数据同步至第二数据库的方式，实现了内存空间的动态伸缩，避免了所有实例数据都缓存在第一数据库，占用第一数据库的存储空间，影响其他业务流程实例的正常工作；同时，对于已经结束的业务流程实例，当需要查阅其实例数据时，直接对第二数据库进行读取操作即可，减少了对第一数据库的访问次数，提高了写服务的可用性；而且，因第一数据库的高并发处理能力，本申请实现了业务流程实例的实例数据高并发的同时，保证了数据的一致性。

附图说明

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

图1为一种K2工作流引擎的测试结果示意图；

图2为本申请实施例提供的一种业务流程处理系统的结构示意图；

图3为本申请实施例提供的另一种业务流程处理系统的结构示意图；

图4为本申请实施例提供的一种业务流程处理方法的流程示意图；

图5为本申请实施例提供的另一种业务流程处理方法的流程示意图；

图6为本申请实施例提供的一种控制类图；

图7为本申请实施例提供的一种业务流程定义图；

图8为本申请实施例提供的针对图7所示的业务流程定义图的一应用场景下的业务流程处理方法的流程示意图；

图9为本申请实施例提供的业务流程处理方法中第一数据库的存储对象关系设计图；

图10为本申请实施例提供的针对图7所示的业务流程定义图的一种业务流程处理方法的流程示意图；

图11为本申请实施例提供的针对图7所示的业务流程定义图的另一种业务流程处理方法的流程示意图；

图12为本申请实施例提供的业务流程处理方法的压测结果示意图；

图13为现有业务流程处理方法的压测结果示意图；

图14为本申请实施例提供的业务流程处理方法得到的业务流程图；

图15为本申请实施例提供的业务流程处理方法的请求耗时测试结果示意图；

图16为本申请实施例提供的业务流程处理装置的结构示意图；

图17为本申请实施例提供的另一种业务流程处理装置的结构示意图；

图18为本申请实施例提供的一种计算机设备的硬件结构示意图。

具体实施方式

结合上文背景技术部分的分析，现有的工作流引擎在实际应用中，为了保证数据一致性，导致数据库承载压力大，并发性能较差，并不适用于多实例高并发交互业务场景。对此，本申请的发明人希望提出一种新高性能工作流引擎，使其能够支持常见的顺序流程、分支流程、异或流程、会签流程等，同时也支持过程中动态增加讨论类型待办和会签类型待办等操作，同时满足这些流程各自的需求。

具体的，本申请可以利用如Redis数据库单线程原子操作特性，基于内存与Redis数据库，实现流程实例交互数据的高并发的同时，保证数据一致性。具体可以将已经结束的流程实例数据存储至持久数据库(如MySql、SQL SERVER)，将未结束的流程实例数据存储至Redis数据库(即键值数据库)，从而利用Redis数据库接口的高并发性能，保证未结束的流程实例并行工作，同时，因已经结束的流程实例数据不会占用Redis数据库，减少了对Redis数据库内存空间的占用，避免了内存不足导致服务不可用的情况，同时也减少了对Redis数据库的访问次数，提升写服务的可用性。

另外，针对现有工作流引擎，将流程流转嵌入到业务流程处理过程中，导致难以跟踪定位，流转不清晰的问题，本申请的发明人还提出将流程流转与业务逻辑处理分离开，使得业务系统可以通过调用相关API(Application ProgramInterface，应用程序接口)实现业务流程实例流转，解决业务系统数据处理与业务流程流转之间的强耦合关系，使得业务流程处理更清晰，且各业务系统只需要注重各环节的业务逻辑处理即可。

还有，基于上述改进，本申请提出的实现业务流程处理方法的新的工作流引擎，可以采用JSON格式，使其可读性及移植性更好，同时，采用同步交互方式取代现有的异步处理方式，以使得异常信息返回更加及时，并据此及时且准确定位异常节点；进一步地，还可以采用SVG(Scalable Vector Graphics，可缩放矢量图形)图形化定义流程，以使得实例状态跟踪更直观。

其中，本申请可以采用HTTP通信协议与各业务系统进行交互，降低了学习成本，且便于新流程的接入。

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

参照图2，为实现本申请提供的业务流程处理方法的系统架构示意图，该系统可以包括网页服务器11、应用服务器12、第一数据库13及第二数据库14，其中：

网页服务器11部署在web层，主要用来部署流程定义和监控站点、引入web负载，以及支持服务器横向扩展等，本申请对web层所部署的网页服务器11的数量不做限定。

参照图3所示的系统模块组成的架构图，流程定义与监控站点主要用来制定标准流程定义规范，提供SVG图形化流程定义(JSON协议存)工具及流程实例数据运营维护工具等，以使得用户流程定义及实例跟踪更便捷更直观。关于本实施例提及到的各工具的具体使用可以参照下文方法实施例相应部分的描述。

应用服务器12可以是提供某项业务的服务设备，在实际应用中，通常在用户终端侧设置与应用服务器12匹配的客户端，即实现该业务的应用程序。可见，对于系统支持的不同业务，通常部署有相应的应用服务器，本申请对该应用服务器类型及其数量不作限定。

本申请中，应用服务器12作为整个系统的中间层，结合图3所示的系统模块组成的架构图，应用服务器12主要可以用来对外提供API服务、逻辑处理、数据适配以及引入负载层等功能，还支持服务器横向扩展，并提供一些基础服务。

如图3所示，工作流引擎对外提供的API接口数量往往是多个，具体可以针对如创建实例、终止流程、提交待办、拉人讨论、转交流程、驳回流程、待办中心及实例中心等不同应用场景，配置相应可调用的消息接口，以供业务系统通过调用所需的消息接口，向工作流引擎发起业务请求消息，具体实现过程本申请不做限定。因此，本申请提供的工作流引擎可以对外发布由多个API接口及其功能组成的接口列表，以使开发人员根据需要选择所需API接口，且通过HTTP API交互方式，使得业务系统的接入更加简单。

对于应用服务器所要实现的逻辑处理，主要可以用来实现所有流程实例状态更新操作，是整个工作流引擎的逻辑处理核心组件。本实施例中，为了满足业务的不同逻辑处理需求，参照图3，其可以部署有访问安全控制中心、用户Ticket中心、实例内存数据上下文、Redis实例上下文以及流程实例控制中心等几部分，但并不局限于此，关于各部分的工作过程，可以参照下文方法实施例相应部分的描述，本实施例在此不作详述。

对于应用服务器实现数据适配的适配层，按照业务领域可以分为DBAdapter适配层和RedisAdapter适配层，主要用来实现流程数据的动态查询与存储，具体实现流程可以参照下文方法实施例相应部分的描述

还有，对于应用服务器所实现的一些基础服务，如图3中基础服务中心所能够提供的组织架构信息、汇报链信息、人员基础信息、邮件/短信/微信等消息、日志等服务，可以根据实际需要，确定基础服务中心包含的服务内容及其实现方法，并不局限于图3所示的服务内容。

第一数据库13和第二数据库14均可以是数据库服务器，但两者可以选用不同类型的数据库服务器，在本申请中，第一数据库13主要用来存储未结束的业务流程实例数据，其可以选用Redis数据库。第二数据库14可以用来备份所有流程实例数据，会存储所有已经结束的流程实例数据，可以选用MySQL数据库服务器，但并不局限于这种关系型数据库。

由此可见，在业务运行期间，所有其对应的流程实例数据可以存储至第一数据库13，在该业务结束的情况下，可以将此时存储的该业务的所有流程实例数据同步至第二数据库14，之后，清除第一数据库13存储的该业务的流程实例数据，减少对第一数据库的内存空间的占用，保证其他业务服务的正常使用。

基于本申请提出的流程实例数据的分类存储方式，对于已经结束的流程实例数据，可以直接从第二数据库14中读取，这样就减少了对第一数据库的访问请求次数，提升了写服务的可用性。所以说，本申请通过这种分类存储方式，实现了第一数据库数据存储的可伸缩性，在保证数据一致性的同时，对外提供了高并发交互接口。

可选的，如图2所示，本申请上述第一数据库和第二数据库均可以采用主从模式，实现对业务流程实例数据的存储，具体实现过程本申请不作详述，且并不局限于图2所示的两组主从数据库。

另外，需要说明，对于图2所示的三层网络部署的系统结构，仅是实现本申请提供的业务流程处理方法的系统架构的示例，并不局限于图2所示的这种结构，也并不局限于各层给出的两组服务器，其可以根据实际开发需求，灵活调整各层服务器的数量，本申请不再一一列举详述。

结合上图2和3所示的系统结构，为了更清楚了解工作流引擎在具体应用场景下的工作过程，下面将从业务处理流程的整体上进行说明，参照图4所示的本申请提供的一种业务处理方法的一实施例的信令流程示意图，该方法可以应用于服务侧，如图4所示，该方法可以包括但并不局限于以下步骤：

步骤S101，客户端向应用服务器的认证系统发起凭证获取请求；

本实施例中，认证系统可以是应用服务器的逻辑处理层部署的用户凭据颁发中心，可以用来为用户发放表明用户身份的凭证ticket，也是保证该用户能够访问系统中的应用的访问凭证。这样，用户客户端可以携带该凭证访问其他应用，以使其他应用能够基于该凭证，识别用户身份，进而确定该用户是否被允许访问应用。

其中，凭证获取请求通常可以包括用户输入的登录信息，以便用户据此对用户的身份进行验证，本申请对该登录信息包含的内容不作限定，如用户身份ID、用户图像等等，可以根据认证系统对用户身份认证的要求确定。

步骤S102，认证系统响应凭证获取请求，为客户端用户分配相应的身份凭证；

步骤S103，认证系统将该身份凭证反馈至客户端；

继上文分析，认证系统接收到凭证获取请求后，可以对其包含的登录信息进行验证，确定通过客户端发起凭证获取请求的用户具有访问权限，即登录信息合格，可以为该用户分配唯一身份凭证ticket，并将其反馈至客户端，本申请对认证系统如何为各用户分配身份凭证ticket的方法不作限定。

可选的，上述身份凭证ticket可以包括SHA1(Secure Hash Algorithm，安全哈希算法)签名算法TOKEN(临时的令牌)、消息对称加解密AES算法密钥、凭据过期时间等信息。

步骤S104，客户端利用该身份信息，生成业务请求消息；

本实施例中，在用户需要获取某业务流程实例的某类型消息的情况下，用户使用客户端从认证系统得到该用户的身份凭证后，可以依据该身份凭证，自定义该请求的头部字段，如用户唯一标识符、请求消息SHA1签名等。之后，可以利用身份凭证中的消息对称加解密AES算法密钥，对请求消息进行加密，再利用加密后的请求消息，生成业务请求消息，保证了对外发送的业务请求的安全性，具体加密过程本申请不做详述。

可选的，在不同应用场景下，本实施例生成的业务请求消息的消息类型可以包括：发起消息、提交待办消息、终止流程消息、转交消息、会签待办消息、驳回消息等，基于不同类型的消息，将生成相应类型的业务请求，但并不局限于本文列举的这几种类型。

结合上图2所示的系统架构，本申请可以在客户端侧的显示界面中，展示工作流引擎提供的可调用的消息接口列表，用户可以从中选择本次发起业务流程所需要的消息接口，以通过调用该消息接口，生成的相应的业务请求消息并发送至工作流引擎。如用户需要发起一招聘流程，可以选择发起消息这一消息类型的消息接口，实现对该消息接口的调用，告知工作流引擎用户当前业务需求，具体实现过程本申请不作限定。

可见，本实施例业务系统采用调用工作流引擎的提供的消息接口的方式，发起相应的业务请求消息，使其只需要关注自身业务，无需关注业务流程的流转逻辑，而是由工作流引擎基于该业务请求消息，执行相应的业务逻辑，所以说，本申请提供的工作流引擎将业务流程流转与业务逻辑处理分离，使得业务流程处理更加清晰，便于追踪定位业务流程实例中的异常节点。

且，本申请采用HTTP API交互方式，简化了业务系统的接入，降低了学习成本。

步骤S105，客户端将该业务请求消息发送至工作流引擎；

步骤S106，工作流引擎从认证系统获取该用户的身份凭证；

步骤S107，工作流引擎利用该身份凭证，对业务请求消息进行有效性校验；

步骤S108，工作流引擎在校验通过的情况下，依据该身份凭证，获取该业务请求消息的消息内容；

本实施例中，工作流引擎接收到用户发送的业务请求消息后，可以先验证该业务请求消息的有效性，即发起该业务请求消息的用户是否具有合法权限，所以，工作流引擎可以从认证系统，获取该用户的身份凭证，进而利用该身份凭证对该业务请求消息进行有效性校验，具体校验过程本实施例不做详述。

经过上述校验，在校验通过的情况下，再利用获取的身份凭证中的密钥，对业务请求消息的消息内容进行解密，得到用户所请求的消息内容，该解密过程与上述加密过程对应，本实施例不作详述。

步骤S109，工作流引擎获取与该消息内容匹配的业务流程实例，并将该业务流程实例的实例数据存储至Redis数据库；

步骤S110，工作流引擎对该业务流程实例进行处理，更新相应节点的实例状态；

步骤S111，工作流引擎将更新后的实例状态以及业务流程实例的实例数据反馈至客户端。

应该理解，对于用户请求操作的业务，其业务流程实例并未结束，因此，在获取与用户发起的业务请求消息的消息内容相匹配的业务流程实例后，即工作流引擎响应业务请求消息，得到本次请求的业务流程实例后，可以将其实例数据缓存至Redis数据库(即上述系统架构中的第一数据库)，具体存储方式不做限定。

可选的，对于Redis数据库这类型的键值数据库，可以将各业务流程实例的实例ID(即该业务流程实例的唯一标识)作为键key，并将其对应的实例数据(可以是JSON格式的数据)作为该key的值value，实现对不同业务流程实例的实例数据的存储。因此，当需要获取某业务流程实例的实例数据时，可以直接利用该业务流程实例的实例ID，查询得到相应的实例数据。

其中，对于本申请的业务流程实例，通常是针对用户提供的业务流程定义图生成的，且该业务流程定义图可以采用JSON协议定义，并针对不同的业务流程定义配置相应的流程定义ID，来区分各业务流程定义图，本申请对业务流程定义的过程不做详述。本申请实际应用中，对于不同类型的业务请求消息，工作流引擎获取相应业务流程实例的过程可能不同。假设该业务请求消息是发起消息，如发起招聘流程，工作流引擎可以按照业务流程定义图，初始化业务流程实例上下文类，得到招聘流程实例，同时，本申请会将发起的这个招聘流程实例的实例数据缓存到Redis数据库中。

之后，在招聘流程的执行过程中，可以从Redis数据库中读取该招聘流程的实例数据，并将其应用到具体招聘过程中，即利用该实例数据，执行招聘流程实例中各节点对应的服务，并更新相应节点的实例状态，以使得招聘者能够及时得知招聘流程各节点的最新状态，得知当前处于招聘流程的什么节点，同时，保证该Redis数据库能够存储各被招聘者在招聘流程中的状态。

可选的，对于用户发起的业务请求消息，如上文描述，其还可以是其他类型的消息，如上文列举的业务流程执行过程中的各类业务请求消息，这种情况下，工作流引擎可以依据该业务的业务流程实例的实例ID，实例化实例上下文类及Redis流程实例类，得到业务流程中的当前处理节点，之后，通过接口多态机制，利用不同类型节点实现业务流程实例数据更新，以及各节点实例状态的更新，并对更新后的实例数据进行加密，将加密后的实例数据以及更新后的实例状态反馈至客户端，以满足用户发起的业务请求消息的业务需求。

其中，在业务流程实例的运行过程中，所产生的更新后的实例数据，可以缓存至Redis数据库(即上述系统结构中的第一数据库)中，实现对业务流程实例执行过程中产生的数据的持久化存储。且在更新后的实例状态表明业务流程实例结束的情况下，本申请可以将此时Redis数据库中该业务流程实例的实例数据同步至MySQL数据库(即上述系统结构中的第二数据库)存储，同时可以将该Redis数据库缓存的该实例数据删除，留出存储空间继续缓存其他业务流程实例的实例数据。

基于上文实施例的描述，结合上图2和图3所示的系统架构，参照图5，为本申请实施例提供的另一种业务流程处理方法的流程示意图，该方法可以包括：

步骤S201，检测业务流程实例中各节点的实例状态；

步骤S202，依据该实例状态，验证该业务流程实例是否结束，如果否，进入步骤S203；如果是，执行步骤S204；

步骤S203，将该业务流程实例的实例数据缓存至第一数据库；

如上述分析，第一数据库可以是Redis数据库，业务流程实例未结束，说明该业务流程实例的至少一个节点对应的服务未执行完毕，即存在至少一个节点对应的服务待执行。

可选的，本申请的Redis数据库可以采用如Hash、Lish、String等数据结构实现实例数据的存储，并通过事务在提升性能的同时，保证数据的一致性。由于Redis数据库属于键值数据库，所以，其在存储业务流程的相关数据时，如业务流程定义信息、各业务流程实例的实例数据等，可以设置相应的唯一标识作为键key，并将相应的数据作为value进行存储。

具体的，可以将流程定义ID、实例ID、待办ID等通过指定步长方式，生成全局唯一主键，即用来查询相应数据的唯一标识，但并不局限于这一种标识生成方式，以Hash数据结构为例，Redis数据库存储的数据主要可以包括业务流程定义、业务流程实例、实例节点、待办任务、处理人待办以及个人待办中心等存储对象的Hash值，且这些存储对象之间可以具有如图7所示的存储关系示意图。

步骤S203，将第一数据库缓存的该业务流程实例的实例数据同步至第二数据库，并删除第一数据库缓存的该业务流程实例的实例数据。

其中，第二数据库可以是Mysql数据库，但并不局限于此。

综上，本实施例可以使用第一数据库缓存未结束的业务流程实例的实例数据，使用第二数据库存储已结束的业务流程实例的实例数据，通过这种定时将第一数据库中流程结束的实例数据同步至第二数据库的方式，实现了内存空间的动态伸缩，避免了所有实例数据都缓存在第一数据库，占用第一数据库的存储空间，影响其他业务流程实例的正常工作；同时，对于已经结束的业务流程实例，当需要查阅其实例数据时，直接对第二数据库进行读取操作即可，减少了对第一数据库的访问次数，提高了写服务的可用性；而且，因第一数据库的高并发处理能力，本申请实现了业务流程实例的实例数据高并发的同时，保证了数据的一致性。

下面将结合具体应用场景，对本申请上述实施例描述的业务处理方法进行说明，结合图7所示的业务流程定义图，该业务流程图可以是用户根据实际需要确定的流程定义，但实际应用中并不局限于图7所示的业务流程定义图，其仅作为一示例进行说明。假设用户在该应用场景下的当前处理节点是“审批1”，当前处理人是A，相应执行的业务处理方法如图8所示：

步骤S301，客户端向工作流引擎提交待办消息；

应该理解，步骤S301实际上可以是当前处理节点的处理人通过客户端提交的待办消息，本实施例仅以待办消息这一消息类型为例进行说明，对于其他类型的业务请求消息的业务处理方法类似，本申请不做一一详述。

步骤S302，工作流引擎依据该待办消息中的流程实例标识，实例化流程实例上下文类及流程实例类；

本实施例中，对于不同的业务流程实例，通常配置有唯一的流程实例标识，如上文描述的业务流程实例的实例ID，本申请对该实例ID的配置方法不做限定，可以采用Redis自增key方式生成，也可以利用SnowFlake算法(即一种分布式ID生成算法)生成等。

参照图9所示的业务流程流转控制类图，本申请可以利用业务请求消息如上述提交待办消息SubmitMsg中的实例ID，实例化流程实例上下文类(FlowInstanceContext类)和业务流程实例类(FlowRedisContext类)。

其中，关于工作流引擎接收到消息后，有效性校验及消息内容加解密过程，可以参照上述实施例的描述，本实施例在此不做赘述。

步骤S303，工作流引擎确定当前处理节点为待办类型节点，获取待办类型节点类；

步骤S304，工作流引擎对该待办类型节点类进行实例化，并存储当前处理节点的审批结果状态；

在确定当前处理节点为“审批1”，其为待办类型节点，对应TaskNode类(即待办类型节点类)，工作流引擎可以实例化该TaskNode类，执行Execute方法存储该当前处理节点的审批结果状态，具体实现过程本实施例不作详述。步骤S305，工作流引擎获取下一级执行节点；

本实施例可以通过执行ChangeFlowState()方法，获取当前处理节点的下一级执行节点，如图7中的“分支1”。

步骤S306，工作流引擎确定该下一级执行节点为分支类型节点，返回步骤S305继续执行，直至所获取的下一级执行节点为待办类型节点，将该待办类型的下一级执行节点更新为当前处理节点；

在本申请中，业务流程实例中的网关类型节点可以包括分支类型节点ForkNode、会签类型节点JoinNode及异或类型节点XorNode，其中，异或类型节点即异或节点在业务流程流转过程中，通常采用自动提交策略，即默认为已处理状态，处理结果为审批通过。除此之前，业务流程实例中的实例节点还可以包括开始节点StartNode、任务节点TaskNode、结束节点EndNode等，具体可以参照如图7所示的业务流程定义图中的各类型节点。

在由图7所示的业务流程定义图得到的业务流程实例中，确定当前处理节点为“审批1”，其下一级执行节点为“分支1”，其为网关类型节点，具体为分支类型节点，可以自动触发ChangeFlowState()方法，获取下一级执行节点，流转到“分支2”，同理继续自动流转到其下一级执行节点“审批2”和“审批3”即待办类型节点；在当前处理节点更新为“分支1”的情况下，自动流转到的下一级执行节点还可能是“分支3”，此时也将自动流转到其下一级执行节点“审批4”和“审批5”，即待办类型节点。

步骤S307，工作流引擎更新该当前处理节点的实例状态；

步骤S308，工作流引擎将流程实例中节点的更新后的实例状态反馈至客户端。

具体的，本实施例在确定当前处理节点为待办类型节点的情况下，可以调用ChangeFlowState()实例化节点待办状态，即更新实例状态，确定当前执行的业务流程实例的节点为审批2、审批3、审批4和审批5，同时还可以获取各待办节点对应的处理人，之后，将更新后的实例状态反馈至客户端，更新客户端展示的业务流程中各节点的状态，以提醒各待办节点的处理人及时进行处理，本申请对业务流程的更新过程不做限定。

另外，结合上述实施例的描述，在如上述业务流程执行过程中，对于业务流程实例未结束的实例数据，更新后可以继续缓存至Redis数据库，按照业务流程的顺序(即该业务流程实例中节点执行顺序)执行节点对应的服务，同时依据所执行的节点的类型，更新其实例状态及实例数据，若确定该业务流程结束，可以将Redis数据库缓存的该业务流程实例的实例数据同步至MySQL数据库存储，同时删除Redis数据库缓存的该实例数据。其中，关于业务流程中各节点对应服务的执行顺序，将按照用户预先定义的业务流程定义图确定，并不局限于图7所示的业务流程定义图。

基于上述构思，在本申请实际应用中，对于不同场景下的定义的业务流程，可以采用相应的实例节点处理策略(其可以是一种数据处理算法)，获取该业务流程的实例数据，其中，该实例节点处理策略可以包括最近分支节点匹配策略CBNM、基于DFSP(Depth FirstSearch Path)的节点间路径遍历策略、驳回策略、XOR异或流转策略、可终止策略、Join会签流转策略等策略中的一个或多个的组合，可以根据实际流程需求选择，下面将列举几个应用场景的业务流程处理中，业务逻辑流转过程的实现进行说明，但并不局限于本申请列举的几个应用场景的业务逻辑流转。

在实际应用中，在执行业务流程实例的当前处理节点后，其是否能够流转到下一级执行节点，如图7所示，若当前处理节点为“会签2”节点，其是否能够流转到“审批6”节点，需要检查“会签2”节点与其匹配的分支节点之前的所有路径中的节点是否都执行完毕，如果是，才会继续流转到“审批6”节点，否则，需要等待执行尚未结束的节点对应的服务。由此可见，在业务流程实例执行过程中，往往需要查找当前处理节点(此处是指会签节点或异或节点)的最近分支节点，以及当前处理节点及其最近分支节点之间的所有路径等。

基于此，本申请将结合图7所示的业务流程定义图，对如何查找最近分支节点的实现方法进行说明，具体以“当业务流程流转到“会签1”节点时，返回分支节点“分支2”；当业务流程流转到“会签2”节点时，返回分支节点为“分支1”，而不是返回分支2或分支3”这一应用场景为例。

由于分支节点与会签节点、分支节点与异或节点在流程定义的时规定必须成对出现，所以，在需要确定与会签节点或异或节点相匹配的最近分支节点的场景下，本实施例可以选用CBNM策略实现，具体实现过程可以参照图10所示流程示意图，针对这一应用场景并不局限于本实施例给出的业务流程处理方法，如图10所示，本实施例主要针对实现上述应用场景的实现过程进行说明，使用节点匹配策略CBNM来获取当前处理节点的最近分支节点，具体实现过程如下：

步骤S401，将业务流程实例的当前处理节点插入堆栈；

栈是一种运算受限的线性表，其限制仅在表的一端(即栈顶)进行插入和删除运算，步骤S401实际上就是当前处理节点进栈步骤。本实施例中，如上文问题描述，当前处理节点可以是用户定义的如图1所示的业务流程实例中的会签或异或类型的节点，即“会签1”节点、“会签2”节点。

步骤S402，依据业务流程实例，获取当前处理节点的前置节点集合；

本实施例中，前置节点集合可以是业务流程实例中的网关类型节点，如图7中的分支节点、会签节点、异或节点等。

步骤S403，选择该前置节点集合中的任一前置节点为待定节点；

步骤S404，检测该待定节点是否为分支类型节点，如果是，进入步骤S405；如果否，执行步骤S407；步骤S405，将当前处理节点从堆栈中删除；

步骤S406，检测当前堆栈是否为空栈，如果否，返回步骤S402；如果是，返回待定节点；

步骤S407，检测该待定节点是否为会签或异或类型节点，如果否，返回步骤S402；如果是，进入步骤S408；

步骤S408，将该待定节点作为当前处理节点插入堆栈，并返回步骤S402。

可见，本实施例中，若当前处理节点为“会签1”节点，与其相匹配的前置节点为分支类型节点，按照本实施例描述的上述步骤，将返回该分支节点执行；若当前处理节点为“会签2”，其前置节点存在会签节点和异或节点，也就是说，流转到“会签2”节点的前置节点有“会签1”节点和“异或1”节点，按照上述方式，可以确定这两个节点分别相匹配的最近分支节点为“分支2”节点和“分支3”节点，进一步可以确定“会签2”节点相匹配的最近分支节点应该为“分支1”节点，所以，在业务流程流转到“会签2”节点时，可以返回其最近分支节点，即返回“分支1”节点，以便查询“分支1”节点与“会签2”节点之间的所有路径。

需要说明，关于查询业务流程实例中会签节点和异或节点各自最近分支节点的实现方法，并不局限于本实施例描述的方法。

结合上述实施例描述应用场景，本申请可以采用基于DFSP算法的节点间路径遍历策略，来获取会签节点(或异或节点)与其最近分支节点(即相匹配的分支节点)之间的路径，仍以图7所示的业务流程定义图为例进行说明，参照图11所示的流程示意图，获取不同类型节点之间的路径的过程可以包括但并不局限于以下步骤：

步骤S501，获取业务流程描述信息，确定该业务流程描述信息中的分支节点，并将该分支节点插入堆栈；

步骤S502，获取当前该堆栈的栈顶节点之后未被访问的节点集合；

若栈顶节点之后的节点存在未被访问的节点，说明该分支节点与会签节点之间存在至少一条路径未被查询到；反之，说明查询到的两节点之间的所有路径。

步骤S503，检测该分支节点的下一级执行节点是否为业务流程描述信息中的会签节点，如果否，进入步骤S504；如果是；进入步骤S505；

步骤S504，将该下一级执行节点插入堆栈，返回步骤S501，直至堆栈为空栈；

步骤S505，获取该分支节点与该会签节点之间的路径，并输出获取的该路径。

以获取“分支1”节点与“会签2”节点之间的所有路径为例，将分支1节点进栈，若栈顶节点之后存在未被访问过的节点集合，检测该分支1节点的下一级执行节点是否为会签2节点，如果是，获取该分支1节点到该会签2节点的路径，如果否，将该下一级执行节点进栈，按照上述方式继续检测栈顶节点之后存在未被访问的节点集合，并将其其下一级执行节点是否为“会签2”，直至得到分支1与会签2节点之间的所有路径，即当前处理节点没有未被访问的下一级执行节点。

需要说明，关于不同类型节点之间的路径查询方法，并不局限于本实施例描述的上述方法，还可以采用其他深度优化算法，本申请不再一一详述。

在业务流程中，通常会遇到从当前处理节点驳回到之前的某一执行节点的流转情况，此时就需要执行驳回策略来实现这一业务流程流转，具体以“当前待办节点驳回至前面任何已处理节点”这一应用场景为例进行说明，参照图7所示的业务流程定义图，可以从“审批6”节点驳回到“审批2”节点。为了实现该应用场景内容，使用驳回策略的实现过程可以为：

获取业务流程描述信息的驳回节点的下一级执行节点，检测该下一级执行节点是否为终止节点或结束节点，如果是，结束流程；如果否，将实例化的下一级执行节点添加到待调整列表，并将其作为当前处理节点，继续对其下一级执行节点进行检测，直至终止节点或结束节点，最后，将待调整列表中的各节点的状态调整为驳回状态，并将驳回节点的状态调整为处理中状态。

可见，本实施例执行该驳回策略，可以将审批6节点与审批2节点之间的所有节点的实例状态更新为驳回状态，并调整审批2的处理状态为“处理中”，重新生成审批2环节的处理人待办，通过这种驳回操作方式，实现了对业务流程实例中各节点的实例状态的统一更新，保证了操作的原子性。

对于业务流程实例中的异或Xor节点，可以按照异或流转策略执行，如以遇到Xor类型节点时，清理以当前XOR节点为终节点的来源分支中所有未处理的待办；如流程执行到节点“异或1”这一业务流程描述信息为例，对本申请使用的异或流转策略进行说明，即实现该业务流程中的异或流程的策略内容可以包括：

以当前异或节点为终止节点为例进行说明，利用上文实施例描述的最近分支节点匹配策略，向前查找该异或节点最近匹配分支节点，查找到的最近匹配分支节点为开始节点，异或节点为终止节点，按照上文给出的节点间路径遍历策略，查询这两个节点之间所有路径，强制终止各分支节点尚未处理的待办分支节点，并调整节点状态，获取下一级执行节点并自动流转，其中，业务流程实例中节点的处理状态通常可以包括初始值、处理中、已处理及被驳回等四种状态。

对于业务流程实例执行过程中，处理结果为未通过或否决的节点，本申请通常执行可终止策略图7，具体在这种情况下，可以自动判断整个业务流程实例是否可终止，如在图7所示的业务流程定义图中，“审核4”节点未通过，对于这一应用场景可以按照如下方法实现：

首先，可以利用上文描述的节点间路径遍历策略，获取开始节点与终止节点之间的所有路径，其次，判断所获取的路径中是否存在未终止路径，即该路径中某节点服务未结束或未执行，如果存在，流程不可终止，可以维持在当前处理节点，等待该未终止路径中的各节点对应的服务工作完毕；如果不存在，更新终止节点的实例状态，并结束流程。

结合上述各实施例的描述，对于业务流程实例中的会签类型节点，可以执行Join会签流转策略，确定会签类型节点的流转，具体可以在遇到会签类型节点时，自动判断该业务流程实例是否可向下一步流转，仍以图7所示的业务流程定义图为例，执行到“会签2”节点，是否可以流转到审批6，具体处理过程如下：

获取会签节点(会签2)的最近匹配的分支节点(分支1)，查询该分支节点与会签节点之间的所有路径，并获取该会签节点上一级审批通过的节点，在查询到的所有路径中，过滤包含该上一级审批通过的节点的路径；获取分支节点下一级节点(如审批2、审批3)中未实例化的节点，再从剩余的路径中，过滤掉包含该未实例化的节点的路径，判断最后剩余路径中的最后一个执行分支节点是否通过，如果通过，自动流转该会签节点的下一级节点，如果未通过，将在该会签节点等待，直至最后一个执行分支节点通过。

需要说明，在业务流程的各分支处理过程中，可以采用如上述举例的相应策略实现，但并不局限于本文描述的策略，可以根据实际需要进行灵活调整。

综上所述，在业务流程执行过程中，在确定当前处理节点为会签节点或异或节点的情况下，可以利用最近分支节点匹配策略，确定当前处理节点的最近匹配分支节点，再遍历该最近匹配分支节点与当前处理节点之间的路径后，确定这些路径中存在未终止路径，将维持在当前处理节点，执行未终止路径中的各节点对应的服务；若这些路径中不存未终止路径，更新当前处理节点的实例状态，流转到下一级执行节点。

基于上述实施例描述的本申请提出的新的工作流引擎实现的业务流程处理方法，通过在具有Windows i7 4核8线程8GB内存，Redis Windows 2.8版本配置的计算机设备上进行流程接口的压测，得到如图12所示的测试结果，其中，在图12中，1000/20可以表示：共发起1000个请求，每次并发请求20个，横坐标的后续数据可以依此类推。可见，本申请的工作流引擎的并发性能在900～1000/QPS(Query Per Second，每秒查询率)，相较于K2，以及图13所示的Activiti都很明显的性能提升。

另外，从流程跟踪性能来看，参照图14所示的生产环境下某业务流程实例图，本申请采用图形化描述业务流程，使得业务流程实例的实例状态展示更加直观。进一步地，本申请还可以通过调整不同状态的节点的显示状态，如改变当前处理节点背景颜色等，使得当前处理节点相较于其他节点更加明显，比如将已执行完成的节点显示为绿色；未执行的节点采用蓝色表示等等。

此外，从生产环境接口请求耗时来看，在如上文描述的生产环境下，抽取部分最近访问日志，可以得到参照图15所示的请求耗时统计结果，由图15可知，本申请工作流引擎的各接口整体性能稳定，平均响应时间大部分维持在10毫秒左右。

参照图16，为本申请实施例提供的一种业务流程处理装置的结构示意图，该装置可以包括：

检测模块21，用于检测业务流程实例中各节点的实例状态；

第一存储模块22，用于在所述实例状态表明所述业务流程实例未结束的情况下，将所述业务流程实例的实例数据缓存至第一数据库；

第二存储模块23，用于在所述实例状态表明所述业务流程实例结束的情况下，将所述第一数据库缓存的所述业务流程实例的实例数据同步至第二数据库，并删除所述第一数据库缓存的所述业务流程实例的实例数据。

可选的，如图17所示，该装置还可以包括：

消息获取模块24，用于获取业务请求消息，所述业务请求消息通过调用相应消息接口的方式生成；

消息响应模块25，用于响应所述业务请求消息，得到本次请求的业务流程实例；

实例节点处理模块26，用于利用所述业务流程实例的实例数据，执行所述业务流程实例中各节点对应的服务，并更新相应节点的实例状态；

数据传输模块27，用于将所述实例数据及更新后的节点的实例状态反馈至客户端。

可选的，上述消息响应模块25可以包括：

初始化单元，用于依据所述业务请求消息的类型，初始化实例上下文类，得到相应的业务流实例；

相应地，实例节点处理模块26可以包括：

第一确定单元，用于确定所述业务流程实例的当前处理节点；

第一更新单元，用于依据所述当前处理节点的类型，更新所述当前处理节点的实例状态及实例数据；

第二更新单元，用于按照所述业务流程实例中节点执行顺序，依据所述当前处理节点的下一级执行节点的类型，更新相应下一级执行节点的实例状态及实例数据。

可选的，该装置还可以包括：

信息获取模块，用于获取业务流程描述信息；

业务流程实现模块，用于利用至少一种实例节点处理策略，得到与所述业务流程描述信息相匹配的业务流程，所述业务流程包括所述业务流程实例的不同节点之间的流转；

其中，所述实例节点处理策略包括最近分支节点匹配策略、节点间路径遍历策略、驳回策略、异或流转策略、可终止策略以及会签流转策略之中的一个或多个的组合。

本实施例中，该业务流程实现模块可以包括：

最近匹配分支节点确定单元，用于在业务流程实例的当前处理节点为会签节点或异或节点的情况下，利用最近分支节点匹配策略，确定当前处理节点的最近匹配分支节点；

路径获取单元，用于遍历所述最近匹配分支节点与所述当前处理节点之间的路径；

第一处理单元，用于若所述路径中存在未终止路径，维持在所述当前处理节点，执行所述未终止路径中的各节点对应的服务；

第三更新单元，用于若所述路径中不存未终止路径，更新当前处理节点的实例状态。

此外，该装置还可以包括：

数据交互模块，用于采用同步交互方式，实现与业务系统的数据交互。

关于上述各虚拟模块实现相应功能的过程，可以参照上述方法实施例的描述，本实施例不作详述。

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

本申请实施例还提供一种计算机设备，该计算机设备可以是上述应用服务器，如图18所示，该计算机设备的硬件结构可以包括：通信接口31、存储器32和处理器33；

在本申请实施例中，通信接口31、存储器32、处理器33可以通过通信总线实现相互间的通信，且该通信接口31、存储器32、处理器33及通信总线的数量可以为至少一个。

可选的，通信接口31可以为通信模块的接口，如GSM模块的接口；

处理器33可能是一个中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。

存储器32可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。

其中，存储器2存储有计算机程序，处理器33调用存储器32所存储的计算机程序，以实现上述应用于计算机设备的业务流程处理方法的各步骤，具体实现过程可以参照上述方法实施例相应部分的描述。

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

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

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

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

Claims (10)

1.一种业务流程处理方法，其特征在于，所述方法包括：

检测业务流程实例中各节点的实例状态；

在所述实例状态表明所述业务流程实例未结束的情况下，将所述业务流程实例的实例数据缓存至第一数据库；

在所述实例状态表明所述业务流程实例结束的情况下，将所述第一数据库缓存的所述业务流程实例的实例数据同步至第二数据库，并删除所述第一数据库缓存的所述业务流程实例的实例数据。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取业务请求消息，所述业务请求消息通过调用相应消息接口的方式生成；

响应所述业务请求消息，得到本次请求的业务流程实例；

利用所述业务流程实例的实例数据，执行所述业务流程实例中各节点对应的服务，并更新相应节点的实例状态；

将所述实例数据及更新后的节点的实例状态反馈至客户端。

3.根据权利要求2所述的方法，其特征在于，所述响应所述业务请求消息，得到本次请求的业务流程实例，利用所述业务流程实例的实例数据，执行所述业务流程实例中各节点对应的服务，并更新相应节点的实例状态，包括：

依据所述业务请求消息的类型，初始化实例上下文类，得到相应的业务流实例；

确定所述业务流程实例的当前处理节点；

依据所述当前处理节点的类型，更新所述当前处理节点的实例状态及实例数据；

按照所述业务流程实例中节点执行顺序，依据所述当前处理节点的下一级执行节点的类型，更新相应下一级执行节点的实例状态及实例数据。

4.根据权利要求2所述的方法，其特征在于，所述方法还包括：

获取业务流程描述信息；

利用至少一种实例节点处理策略，得到与所述业务流程描述信息相匹配的业务流程，所述业务流程包括所述业务流程实例的不同节点之间的流转；

其中，所述实例节点处理策略包括最近分支节点匹配策略、节点间路径遍历策略、驳回策略、异或流转策略、可终止策略以及会签流转策略之中的一个或多个的组合。

5.根据权利要求4所述的方法，其特征在于，所述利用至少一种实例节点处理策略，得到与所述业务流程描述信息相匹配的业务流程，包括：

在所述业务流程实例的当前处理节点为会签节点或异或节点的情况下，利用最近分支节点匹配策略，确定所述当前处理节点的最近匹配分支节点；

遍历所述最近匹配分支节点与所述当前处理节点之间的路径；

若所述路径中存在未终止路径，维持在所述当前处理节点，执行所述未终止路径中的各节点对应的服务；

若所述路径中不存未终止路径，更新所述当前处理节点的实例状态。

6.根据权利要求2～5任一项所述的方法，其特征在于，所述方法还包括：

采用同步交互方式，实现与业务系统的数据交互。

7.一种业务流程处理装置，其特征在于，所述装置包括：

检测模块，用于检测业务流程实例中各节点的实例状态；

第一存储模块，用于在所述实例状态表明所述业务流程实例未结束的情况下，将所述业务流程实例的实例数据缓存至第一数据库；

第二存储模块，用于在所述实例状态表明所述业务流程实例结束的情况下，将所述第一数据库缓存的所述业务流程实例的实例数据同步至第二数据库，并删除所述第一数据库缓存的所述业务流程实例的实例数据。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

信息获取模块，用于获取业务流程描述信息；

业务流程实现模块，用于利用至少一种实例节点处理策略，得到与所述业务流程描述信息相匹配的业务流程，所述业务流程包括所述业务流程实例的不同节点之间的流转；

其中，所述实例节点处理策略包括最近分支匹配策略、节点间路径遍历策略、驳回策略、异或流转策略、可终止策略以及会签流转策略之中的一个或多个的组合。

9.一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行，实现如权利要求1-10任意一项所述的业务流程处理方法的各步骤。

10.一种计算机设备，其特征在于，所述计算机设备包括：

通信接口；

存储器，用于存储实现如权利要求1-10任意一项所述的业务流程处理方法的计算机程序；

处理器，用于记载并执行所述存储器存储的计算机程序，所述计算机程序用于实现如权利要求1-10任意一项所述的业务流程处理方法的各个步骤。