CN118132212A - 一种数据处理方法、装置、设备、介质及程序产品 - Google Patents

Abstract

本申请实施例公开了一种数据处理方法、装置、设备、介质及程序产品；其中的方法包括：获取业务场景中待处理的流程实例；在第一驱动事件的驱动下，执行N1个流程任务；以及，对第一驱动事件对应的驱动过程进行事务化处理，得到第一驱动事件对应的事务化处理结果；若第一驱动事件对应的事务化处理结果指示N1个流程任务的执行结果均为执行成功，则在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务提交。本申请实施例可应用于云技术、人工智能、智慧交通、辅助驾驶等各种场景，且采用本申请能够在流程实例的任务驱动过程中确保事务的原子性和数据一致性，确保数据库中数据查询的可靠性。

Description

一种数据处理方法、装置、设备、介质及程序产品

技术领域

本申请涉及计算机技术领域，尤其涉及数据处理领域，具体涉及一种数据处理方法、装置、设备、介质及程序产品。

背景技术

流程实例是指按照流程设定的环节和步骤、遵照流程的规则和规范实际运行的一个业务流程；该业务流程中包括多个待执行的流程任务，且通过驱动该多个流程任务的执行以达到流程实例的业务目标。

目前，流程实例中各流程任务的执行结果是相互独立地被提交至数据库，而执行结果的提交具有一定的延时性，这导致任务驱动过程中不能确保事务的数据一致性，可能给实际业务流程的处理带来潜在风险。

因此，如何确保流程实例的任务驱动过程的数据一致性成为研究热点。

发明内容

本申请实施例提供一种数据处理方法、装置、设备、介质及程序产品，能够在流程实例的任务驱动过程中确保事务的原子性和数据一致性。

一方面，本申请实施例提供了一种数据处理方法，该方法包括：

获取业务场景中待处理的流程实例；流程实例中包括N1个流程任务，且N1个流程任务均在第一驱动事件的驱动下执行；流程任务中包含业务场景对应的业务逻辑；N1为大于1的整数；

在第一驱动事件的驱动下，执行N1个流程任务；

对第一驱动事件对应的驱动过程进行事务化处理，得到第一驱动事件对应的事务化处理结果，第一驱动事件对应的事务化处理结果用于指示N1个流程任务的执行结果；

若第一驱动事件对应的事务化处理结果指示N1个流程任务的执行结果均为执行成功，则在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务提交；与第一驱动事件相关的数据库事务提交用于指示在数据库中保存执行N1个流程任务所产生的操作。

另一方面，本申请实施例提供了一种数据处理装置，该装置包括：

获取单元，用于获取业务场景中待处理的流程实例；流程实例中包括N1个流程任务，且N1个流程任务均在第一驱动事件的驱动下执行；流程任务中包含业务场景对应的业务逻辑；N1为大于1的整数；

处理单元，用于在第一驱动事件的驱动下，执行N1个流程任务；

处理单元，还用于对第一驱动事件对应的驱动过程进行事务化处理，得到第一驱动事件对应的事务化处理结果，第一驱动事件对应的事务化处理结果用于指示N1个流程任务的执行结果；

处理单元，还用于若第一驱动事件对应的事务化处理结果指示N1个流程任务的执行结果均为执行成功，则在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务提交；与第一驱动事件相关的数据库事务提交用于指示在数据库中保存执行N1个流程任务所产生的操作。

在一种实现方式中，处理单元，还用于：

若第一驱动事件对应的事务化处理结果指示N1个流程任务中存在执行结果为执行失败的流程任务，则在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务回滚；与第一驱动事件相关的数据库事务回滚用于指示在数据库中撤销执行N1个流程任务所产生的操作；

其中，执行N1个流程任务所产生的操作被保存至数据库后，客户端能够从数据库中实时查询与N1个流程任务相关的流程数据；执行N1个流程任务所产生的操作包括以下至少一种：将与N1个流程任务相关的流程数据写入数据库的增加操作；将与N1个流程任务相关的流程数据从数据库中删除的删除操作；对与N1个流程任务相关的流程数据进行修改的修改操作；以及在数据库中针对与N1个流程任务相关的流程数据的查询操作。

在一种实现方式中，处理单元，还用于：

为流程实例设置流程实例锁；流程实例锁用于在驱动过程中对与N1个流程任务相关的流程数据执行锁定操作，被执行锁定操作的与N1个流程任务相关的流程数据处于锁定状态；

在与N1个流程任务相关的流程数据处于锁定状态下，触发执行在第一驱动事件的驱动下，执行N1个流程任务的步骤。

在一种实现方式中，处理单元，用于为流程实例设置流程实例锁时，具体用于：

获取业务场景对应的数据库的流程实例表；流程实例表用于存储至少一个流程实例的实例标识，至少一个流程实例中包括待处理的流程实例；

从流程实例表中确定出待处理的流程实例的实例标识；

基于待处理的流程实例的实例标识，为待处理的流程实例增加流程实例锁。

在一种实现方式中，处理单元，用于为流程实例设置流程实例锁时，具体用于：

获取业务场景对应的数据库的流程实例表；流程实例表用于存储至少一个流程实例的实例标识，至少一个流程实例中包括待处理的流程实例；

为流程实例表增加流程实例锁；其中，流程实例表中的每个实例标识对应的流程实例均被增加流程实例锁。

在一种实现方式中，在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务提交的同时，或者，在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务回滚的同时，处理单元，还用于：

释放流程实例锁针对与N1个流程任务相关的流程数据的锁定操作；释放锁定操作后，与N1个流程任务相关的流程数据处于可更新状态。

在一种实现方式中，流程实例中还包括N2个流程任务，N2个流程任务的执行顺序位于N1个流程任务之后，且N2个流程任务均在第二驱动事件的驱动下执行；N2为大于1的整数；处理单元，还用于：

在第二驱动事件的驱动下，执行N2个流程任务；

对第二驱动事件对应的驱动过程进行事务化处理，得到第二驱动事件对应的事务化处理结果；第二驱动事件对应的事务化处理结果用于指示N2个流程任务的执行结果；

若第二驱动事件对应的事务化处理结果指示N2个流程任务的执行结果均为执行成功，则在业务场景对应的数据库中进行与第二驱动事件相关的数据库事务提交；与第二驱动事件相关的数据库事务提交用于指示在数据库中保存执行N2个流程任务所产生的操作；

其中，流程实例停止驱动的结束条件为流程实例中的最后一个流程任务被执行。

在一种实现方式中，在驱动过程中N1个流程任务中的每个流程任务均创建有对应的任务节点，任务节点承载有相应流程任务所包含业务场景对应的业务逻辑；N1个流程任务中存在有流程任务对应的任务节点绑定任务执行器，任务执行器承载有相应流程任务所包含的参考业务逻辑，参考业务逻辑是由用户自定义的业务逻辑；处理单元，还用于：

执行任务节点中绑定的任务执行器。

在一种实现方式中，M个任务节点绑定有任务执行器，M为正整数，且M≤N1；处理单元，用于执行任务节点中绑定的任务执行器时，具体用于：

对M个任务节点中绑定的任务执行器进行异步并行执行。

在一种实现方式中，流程任务对应的任务节点在节点创建的开始阶段和结束阶段均绑定有任务执行器；

其中，M个任务节点中绑定的任务执行器中，被异步并行执行的任务执行器包括：M个任务节点中除属于对象类型的任务节点外的每个任务节点在节点创建的开始阶段和结束阶段绑定的任务执行器，以及，M个任务节点中属于对象类型的任务节点在节点创建的开始阶段绑定的任务执行器；

M个任务节点中属于对象类型的任务节点在节点创建的结束阶段绑定的任务执行器，在第一驱动事件的下一个驱动事件中被执行。

另一方面，本申请实施例提供了一种计算机设备，该计算机设备包括：

处理器，用于加载并执行计算机程序；

计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，该计算机程序被处理器执行时，实现上述数据处理方法。

另一方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，该计算机程序适于由处理器加载并执行上述数据处理方法。

另一方面，本申请实施例提供了一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序被处理器执行时，实现上述数据处理方法。

本申请实施例中，获取的业务场景中待处理的流程实例中包括N1个流程任务，且在第一驱动事件的驱动下可以执行该N1个流程任务。然后，支持对第一驱动事件对应的驱动过程（即执行N1个流程事务的任务驱动过程）进行事务化处理，得到第一驱动事件对应的事务化处理结果，该第一驱动事件对应的事务化处理结果用于指示N1个流程任务的执行结果；通过在N1个流程任务的驱动过程中引入事务化机制，即将N1个流程任务的执行当作同一事务中的处理，可以确保流程实例中的驱动过程具有事务的原子性，即N1个流程任务要么全部驱动成功，要么全部驱动失败。进一步的，在第一驱动事件对应的事务化处理结果指示N1个流程任务均执行成功时，在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务提交；数据库事务提交后N1个流程任务的执行过程中的所有流程数据的更改同时生效，从而确保数据库中与该N1个流程任务相关的流程数据的数据状态具有一致性（即数据库中与N1个流程任务相关的流程数据均为流程任务被成功执行后的有效数据或正常数据）。综上所述，本申请实施例有效利用数据库事务的特性来确保流程实例中N1个流程任务的流转过程（或驱动过程）的原子性和数据一致性，以实现完成一次任务驱动（或称为流程驱动）所产生的流程数据立即生效，避免数据不可信等问题，提高业务流程的可靠性。

附图说明

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

图1是本申请一个示例性实施例提供的一种流程实例的示意图；

图2a是一种外部系统无法查询新数据时间隔性重试的示意图；

图2b是一种流程变量信息未及时生效导致返回资源不存在的示意图；

图2c是一种流程变量的示意图；

图2d是一种乐观锁冲突回滚的示意图；

图3是本申请一个示例性实施例提供的一种数据处理方案的总体技术流程的示意图；

图4是本申请一个示例性实施例提供的一种数据处理系统的架构示意图；

图5是本申请一个示例性实施例提供的一种数据处理方法的流程示意图；

图6是本申请一个示例性实施例提供的一种基于事务的任务驱动的流程示意图；

图7是本申请一个示例性实施例提供的一种转账场景下基于事务的任务驱动的流程示意图；

图8是本申请一个示例性实施例提供的另一种数据处理方法的流程示意图；

图9是本申请一个示例性实施例提供的一种异步并行执行多个任务执行器的示意图；

图10是本申请一个示例性实施例提供的一种数据处理装置的结构示意图；

图11是本申请一个示例性实施例提供的一种计算机设备的结构示意图。

具体实施方式

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

在本申请实施例中，提供了一种数据处理方案，具体涉及流程实例和数据库事务等内容。下面对本申请实施例提供的数据处理方案所涉及的技术术语和相关概念进行简单介绍，其中：

一、数据库事务。

数据库事务简称事务，是属于数据库管理系统（Database Management System，DBMS）中的一个概念。具体地，数据库事务是数据库管理系统执行过程中的一个逻辑单元，该逻辑单元可以是由一个有限的数据库操作序列构成；通俗来讲，数据库事务可以指的是访问并可能操作数据库中的各种数据项的一个数据库操作序列；该数据库操作序列中包括访问并可能操作数据库中的数据项的一系列操作，且该一系列操作要么全部执行，要么全部不执行，是一个不可分割的工作单位。例如，客户端请求对数据库中的数据项A进行更改，那么响应于客户端想要访问并更改该数据项A的请求，可能需要在数据库中按照顺序执行如下操作：操作1→操作2→操作3，那么操作1→操作2→操作3的操作序列可以称为数据库操作序列，该数据库操作序列构成一个数据库事务。

数据库事务是数据库保持一致性的一个关键机制，其遵循ACID（AtomicityIsolation Durability）属性；下面对数据库事务的ACID属性进行介绍：

1、原子性（Atomicity）：是指一个数据库事务中的一系列操作组成一个原子包，该原子包中的多个操作要么全部完成（或理解为全部执行成功），要么全部不完成（或理解为全部执行失败），不会在一系列操作的中间某个操作结束。其中，如果数据库事务中的一系列操作都正常完成（即全部执行成功），那么进行数据库事务提交（commit），即将数据库事务提交给数据库管理系统，并由该数据库管理系统确保该数据库事务中的所有操作都成功执行且执行结果被永久保存在数据库中，具体是保存这些操作对数据库中相关的数据项的影响（如将经过数据库事务中一系列操作后，发生了更新的数据项的新数值写入至数据库中，再如将经过数据库事务中一系列操作后产生的新数据项和相应的数值写入数据库中等）。反之，如果数据库事务中的一系列操作在执行过程中发生错误（如存在一个操作没有完成），那么进行数据库事务回滚（Rollback），即数据库事务中的所有操作均需要被回滚，回到数据库事务执行前的状态，且数据库管理系统需要确保该数据库事务对数据库或者其他事务的执行无影响。

2、一致性（Consistency）：或称为数据一致性，是指数据库从一个一致的状态转换到另一个一致的状态；换句话说，数据库事务执行的结果必须是使数据库从一个有效状态变到另一个有效状态，以此保证数据库的数据完整性。例如，账户A中有100元，账户B中有50元，在需要将账户A中的20元转移至账户B的转账事务中，事务开始时数据库中存储数据的有效状态是账户A中有100元和账户B中有50元，那么事务结束时数据库中存储数据的有效状态应该是账户A中有80元和账户B中有70元；事务结束时数据库中的存储数据的状态为账户A中有80元，但账户B中有50元（即账户A已扣款，但账户B未收到扣款），那么就认为不具有数据一致性。数据库事务的一致性可以有效确保数据库中的数据在事务执行前后的完整性没有被破坏，从而可以避免针对数据库中数据的查询错误，也提高数据库的稳定性和可靠性。

3、隔离性（Isolation）：是指一个数据库事务中的一系列操作对数据库中数据所做的修改（或操作）在最终提交（commit）至数据库（具体是提交至数据库管理系统）之前，对数据库管理系统中的其他事务是不可见的。数据库事务的隔离性可以防止数据库管理系统中的多个数据库事务并发执行时，由于交叉执行而导致数据的不一致。

4、持久性（Durability）：是指一个数据库事务一旦提交至数据库（具体是提交至数据库管理系统，由该数据库管理系统实现数据库的维护），那么该数据库事务中的一系列操作对数据库中相应数据所作的修改会永久保存在数据库中，确保数据库即使发生故障，数据库事务执行的结果也不会丢失，保证数据库中数据的可靠性。

正如前述所描述的，数据库事务是数据库管理系统执行过程中的逻辑单元，此处的数据库管理系统是为管理数据库而设计的电脑软件系统，一般具有存储、截取、安全保障、备份等基础功能；可以依据它所支持的数据库模型来作分类，例如关系式、XML（eXtensible Markup Language，可扩展标记语言）；或依据所支持的计算机类型来作分类，例如服务器群集、移动电话；或依据所用查询语言来作分类，例如SQL（Structured QueryLanguage，结构化查询语言)、XQuery（XML XQuery，XML查询语言）；或依据性能冲量重点来作分类，例如最大规模、最高运行速度；亦或其他的分类方式。不论使用哪种分类方式，一些数据库管理系统能够跨类别，例如，同时支持多种查询语言。其中，数据库管理系统所管理的数据库可以视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作；也就是说，数据库是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

需要说明的是，数据库事务的管理也需要依赖数据库管理系统来实现。例如，在关系型数据库处于autocommit（自动提交事务）模式下，在数据库管理系统中可以用SQL（Structured Query Language，结构化查询语句）语句来控制数据库事务，具体是一个SQL语句为一个数据库事务，该SQL语句执行结束后，自动提交数据库事务。其中，SQL语句可以包括：BEGIN TRANSACTION（控制语句，用于控制一个数据库事务的开始）、COMMIT（事务控制语句，用于提交对数据库所做的更改）和ROLLBACK（事务撤销语句，用于撤销数据库事务对数据库所做的更改）。

再如：数据管理系统提供了必要的机制来保证数据库事务的ACID属性，这些机制可以包括但是不限于事务日志、恢复、回滚和锁机制等机制。其中，事务日志：支持记录数据库事务的操作，包括数据插入、数据更新、数据删除、事务提交、事务回滚和数据库模式的变更等。恢复机制：当数据库发生意外关闭或崩溃时，恢复机制可以利用事务日志中记录的信息来帮助数据库快速恢复到一个可用的状态。事务回滚即前述提及的数据库事务回滚，可以参见前述关于数据库事务回滚的相关描述，在此不作赘述。锁机制：数据库中的同一数据可能同时被并发的多个数据库事务操作，就会导致出现脏数据（即数据库中存在错误、不一致或不完整的数据）的问题，因此为数据库管理系统设计锁机制来解决多事务并发操作带来的问题。锁机制可以包括多种锁，如表级锁（用于锁定整个表）、页级锁（用于锁定一页）、行级锁（用于锁定一行）、共享锁和排他锁等；例如，在数据库管理系统中引入锁之后，就可以并发处理数据库事务，如果并发的多个数据库事务之间涉及到相同的数据，那么会使用排他锁（或互斥锁）让先进入的数据库事务独占数据，其他数据库事务被阻塞，等待前面的数据库事务释放锁。

除上述给出的几种实际存在的锁之外，还有两种并发控制手段（是抽象性的锁），分别为乐观并发控制（或称为乐观锁（Optimistic Concurrency Control，OCC））和悲观并发控制（或称为悲观锁（Pessimistic Concurrency Control，PCC））。其中，悲观锁指的是对数据被外界（包括数据库管理系统中与当前占据数据的数据库事务并行的其他数据库事务，以及来自外部系统的事务处理）修改持保守态度（悲观），因此，在针对数据的整个数据处理过程中均将该数据设置为锁定状态，等当前数据库事务完成后再释放针对该数据的锁定状态。相反地，乐观锁指的是假设多并发的数据库事务在处理时不会彼此互相影响，各数据库事务能够在不产生锁的情况下处理各自影响的那部分数据；在提交数据更新之前，每个数据库事务会先检查在该数据库事务读取数据后，有没有其他数据库事务又修改了该数据，如果其他数据库事务针对该数据有更新的话，正在提交的数据库事务会进行回滚。

二、流程实例（Process Instance）。

在业务流程体系平台（或简称为业务平台、业务客户端等）中的流程实例，通常代表一个具体的工作流程或业务过程的单次运行过程；也就是说，流程实例可以是属于业务场景中的一个实际业务流程。流程实例更上位的一个概念为流程定义，流程定义是一组工作规范（如请假流程定义等），而流程实例是流程定义下的一个具体流程实施过程（如某个员工的一次请假流程），即一种类型的流程定义可以启动多个流程实例。其中，流程实例由多个流程任务（Process Task）组成，流程任务可以是指流程实例中以特定顺序调用或驱动执行的一组与业务场景相关的活动，这些活动旨在实现业务场景下特定的业务目标。示例性地，流程实例为接口（API）接入申请流程的流程示意图可以参见图1；如图1所示，该流程实例中的流程任务依次可以包括：API接入申请流程中的授权同步任务、预授权确认任务、流程责任人确认任务、确认检查任务等等。值得注意的是，如图1所示的流程实例中每个流程任务其实是流程中的一个任务节点；当流转流程实例中的任一流程任务时，该任一流程任务对应的任务节点被创建，且该任务节点中可以绑定任务执行器（TaskListener）；该任务执行器中包括相应流程任务所包含的参考业务逻辑，该参考业务逻辑可以是由用户自定义的业务逻辑。

进一步的，工作流引擎（WorkflowEngine）是业务流程体系平台的核心服务之一，负责对业务流程体系平台中流程实例中的流程任务的驱动与流转、以及对实际任务处理逻辑的分发。也就是说，在业务流程体系平台中可以通过工作流引擎（或称为流程引擎）实现流程实例的流程驱动（或称为任务驱动），以使得流程实例在流程运行过程中，按照流程实例中各流程任务的执行顺序一步一步地进行流程任务的流转。其中，在一次流程任务的流转过程中，会执行流程实例中顺序连接的一个或多个流程任务，而一次流程任务的流转过程可以称为任务驱动（Task-Driven），该任务驱动具体可以理解为接收到驱动事件后进行流程实例中流程任务进行流转的过程。值得注意的是，一个流程实例从启动到结束，往往需要进行多次任务驱动（每次任务驱动都由驱动事件触发），每次驱动都代表上一次驱动所产生的业务逻辑执行完成，进入下一步需要执行的业务逻辑。

其中，上述提及的业务流程体系平台可以是任一业务场景对应的业务平台（如业务流程管理的平台，工作流系统或事件驱动系统等）；业务场景可以包括但是不限于：网络运营场景（如电商运营场景中，当消费者购买商品时需要经过商品流程→下单→发货→售后等流程性操作）、审批场景（如财务审批场景，当企业需要购买设备和支付供应商费用或进行其他财务活动时，可能需要经过购买单位提交购买清单→财务部分审批→财务领导审批→企业资金变动等流程性操作）和库存管理场景（如库存调用场景中，当需要调货时可能需要经过申请调货→有货物的门店审批→接收货物的门店审批→货物签收等流程性操作）等等。根据业务场景的不同，该业务场景对应的业务平台也不相同。举例来说，网络运营场景对应的业务平台可以是自动化运营流程开发体系与运行平台；其中，该自动化运营流程开发体系与运行平台是为网络运营人员打造的一种自动化开发与运行平台，通过低代码、低门槛和高效率的流程开发方式，流程化与标准化的网络运营事务，同时通过统一的模式提供数据管理、自动化操作、以及事务管理等能力。进一步的，工作流引擎可以是为业务流程体系平台设计的一种引擎，主要负责业务流程体系平台中的业务流程（如流程实例）在运行过程中对流程任务的流转驱动，以及对流经流程任务的任务逻辑分发。具体可以负责流程实例/任务/顺序流/变量的存储与管理、流程路径决策、任务逻辑分发、各类执行器执行和流程异常控制等工作。本申请实施例对涉及的工作流引擎的类型不作限定，可以是针对专属的业务流程体系平台自研的工作流引擎，也可以是适用于普通业务流程体系平台的工作流引擎。

在实际应用中，工作流引擎对业务流程体系平台中的流程实例进行任务驱动的过程中，不能确保事务的原子性和数据一致性，且任务节点上绑定的任务执行器在任务驱动过程中被自动执行。现有工作流引擎这种驱动模式（即任务驱动过程中执行任务执行器，且各任务节点执行后的结果自行提交）存在一定的缺陷，其中：

一方面，一次任务驱动的过程中不能确保事务的原子性和数据一致性，可能导致一次任务驱动完成后，由于与该任务驱动相关的流程数据（或者理解为该任务驱动所驱动执行的多个流程任务相关的流程数据）未及时在数据库中生效（或者并未真正写入到数据库），导致外部系统无法立即查询到新的数据（如前述提及的与多个流程任务相关的流程数据，如新创建的任务节点信息和新设置的流程变量信息）。如图2a所示，在外部系统无法查询到执行任务节点A所产生的新数据的情况下，必须通过间隔性重试纠错（即间隔性地向数据库查询该任务驱动结束后的相关数据）；在这种情况下，会导致各系统之间的配合不够顺畅（如外部系统和数据库管理系统之间的配合），严重拖慢流程的整体流转速度。同时，由于本次任务驱动过程中事务的数据一致性得不到保证，导致为流程实例的下一次驱动所设置的流程变量信息在一定程度上并不绝对可信（或者下一次驱动所需设置的流程变量信息无法获取，如图2b所示，流转至任务节点B时无法及时获取执行任务节点A所产生的新数据），导致在实际业务流程事务的处理上，存在潜在的数据错误风险。其中，流程变量信息是指进行一次任务驱动前，根据用户提供的流程变量数据（一系列的key-value（键值对）值）设置到流程引擎中的流程变量信息；如果流程引擎中的变量key不存在，可以认为是创建一个新变量key并赋予初始值value，如果变量key已经存储，则是使用新的value值更新原有的value值。示例性地，一些常见流程变量可以参见图2c所示的流程变量表格（如创建信息（creator）变量）。

另一方面，现有工作流引擎中使用乐观锁，且驱动模式下流程任务对应的任务节点中绑定的任务执行器是在任务驱动的过程被执行，这使得当出现乐观锁冲突时，本次任务驱动失败，内部机制会进行重试，导致本次任务驱动所驱动的同一任务节点中绑定的相同任务执行器的逻辑被重复执行。而任务执行器的逻辑被重复执行，在一些敏感的业务场景处理过程中（如网络事务处理过程中），会导致业务处理过程存在潜在的运营风险。并且，由于前续流程任务对应的任务节点上绑定的任务执行器的逻辑执行完成后，进行任务提交驱动下一次驱动时，因任务已被回滚或没有实际写入存储，从而报404（即服务器无法查找到客户端想要访问的资源时，返回给用户的提示信息）任务不存在的错误，即下发无效任务（示例性地乐观锁冲突导致下发无效任务的示意图可以参见图2d）。以图1所示的API接入申请流程为例对上述提及的乐观锁冲突导致任务驱动失败的过程进行示例性说明；如图1所示的流程实例中，当流程同时运行到“直接审批人”和“特定审批人”两个任务节点时，如果外部处理逻辑同时完成处理，在同一时刻提交了这两个任务，那么工作流引擎会对这两个任务节点同时流转。在流转过程中会有乐观锁检测机制，如果发现有另一个任务节点在流转过程中对数据进行了修改，将触发乐观锁导致其中一个任务节点回滚，即发生乐观锁冲突导致任务驱动回滚。简而言之，因为乐观锁机制在同一个流程实例中同一时刻对多个任务节点进行驱动，会因乐观锁检测机制存在冲突回滚的情况；冲突回滚后工作流引擎内部会自动触发重试，不仅导致任务节点上绑定的任务执行器重复执行，提高流程驱动成本，而且导致业务流程存在运营风险。

基于此，本申请实施例涉及的数据处理方案具体提供一种基于事务的任务驱动与执行器后置的驱动模式；该驱动模式部署于工作流引擎（如一种自研工作流引擎）的流程驱动层，该流程驱动层是工作流引擎的关键组件，一方面控制业务流程体系平台中流程实例中的流程任务的驱动和流转，另一方面控制具体的任务逻辑（即任务执行器）的执行；并且部署该驱动模式的工作流引擎相对于传统工作流引擎的引擎性能提升约12倍。详细地，本申请实施例提供的数据处理方案主要从以下几个点在驱动模式的设计进行针对性地改进，其中：

①将数据库管理系统中的事务机制应用到业务流程体系平台的流程实例的任务驱动过程中，旨在保证流程实例中的任务驱动过程的原子性和数据一致性；确保完成一次流程驱动所产生的数据立即生效，避免数据不可查询和不可信的问题。

②在流程驱动过程中移除乐观锁，转而使用更为严格的悲观锁；依赖于悲观锁能够锁定当前处理数据的特点，从源头上控制流程实例中每次任务驱动过程中各流程任务的串行化执行，从而解决由于乐观锁冲突所导致的任务执行器重复执行等问题。

③采用任务执行器后置执行的设计模式，所谓后置执行是指在一次任务驱动过程结束之后，再执行该任务驱动过程中各流程任务对应的任务节点上绑定的任务执行器。这样，整个驱动过程中出现的任何异常引发事务回滚，都不会对业务流程中具体业务逻辑的执行产生任何负面影响，因为此时含有具体业务逻辑的任务执行器并未开始执行。

基于上述对数据处理方案的几个技术点的介绍，为便于理解该数据处理方案的整体技术实现，下面结合图3对数据处理方案的总体技术实现的流程进行简单介绍。如图3所示，获取业务场景中待处理的流程实例；假设该流程实例为请假流程定义下的A员工的请假流程实例，且请假流程实例中包括N1个在第一驱动事件下执行的流程任务（对应到图3中的任务节点（或服务任务）），N1为大于1的整数，如流程任务为小组审批、直接领导审批、高层领导审批等等。然后，工作流引擎检测到第一驱动事件后，可以驱动流程实例中的N1个流程任务进行流转执行；具体地，在驱动流程任务进行流转之前，先启动事务，并初始化流程变量（即前述提及的流程变量信息），此处的初始化流程变量是指进行一次任务驱动前，先将用户提供的一系列流程变量数据设置到工作流引擎的过程，以便于执行N1个流程任务的过程中均可以感知到初始化的流程变量。

进一步的，在事务已经启动，且流程变量已初始化后，开始进行任务的连续驱动。在N1个流程任务的连续驱动过程中，一方面，可以通过增加的悲观锁来锁定与正在被执行的流程任务相关的数据，可以避免驱动过程中并行处理数据时所带来的回滚等。另一方面，可以通过事务化机制（如前述提及的事务机制）来确保在连续驱动过程中出现任何异常（如服务任务执行失败）时，触发回滚操作并自动撤消第一驱动事件下的驱动过程中所有之前已完成的驱动行为；在第一驱动事件下的整个驱动过程无异常（如所有服务任务均执行成功）时，提交事务，完成本次任务驱动。如图3所示，在事务已经启动，且流程变量已初始化后，开始执行服务任务-1（即一个流程任务对应的任务节点），并根据该服务任务-1的执行结果驱动流程任务的流转；具体是，若服务任务-1的执行结果为执行成功（即服务任务-1正常执行），则从服务任务-1流转至服务任务-2，继续执行该服务任务-2，若服务任务-1的执行结果为执行失败（即服务任务-1异常执行），则触发回滚操作；重复上述步骤（如继续执行图3所示的服务任务-4和服务任务-5），得到第一驱动事件对应的事务化处理结果。

最后，若第一驱动事件对应的事务化处理结果指示N1个流程任务的执行结果均为执行成功，则返回结果（即各流程任务的执行结果），并在返回结果的过程中，启动执行器后置异步执行机制，开始进入任务执行器执行阶段。在任务执行器的执行阶段中，多个不同的任务执行器可以并行执行，以提升执行效率，且确保任一任务执行器因进程退出而被中断时，不会影响其他任务执行器的执行。反之，若第一驱动事件对应的事务化处理结果指示N1个流程任务中存在执行失败的流程任务，则确定第一驱动事件下的驱动过程驱动失败。

由此可见，一方面，本申请实施例支持通过事务化机制来将N1个流程任务的操作放置到同一事务中，即将N1个流程任务的执行结果当作一个整体来执行事务提交或事务回滚；相比于单个流程任务各自进行事务提交或事务回滚而言，可以确保一次驱动事件对应的驱动过程（即任务驱动过程）能够确保事务的原子性，即N1个流程任务要么全部驱动成功，要么全部驱动失败。并且，一次驱动事件对应的所有流程任务均执行成功后才进行数据库事务提交，数据库事务提交后N1个流程任务的执行过程中的所有流程数据的更改同时生效，从而确保数据库中与该N1个流程任务相关的流程数据的数据状态具有一致性（即数据库中与N1个流程任务相关的流程数据均为流程任务被成功执行后的有效数据或正常数据），避免数据不可信等问题，提高业务流程的可靠性。另一方面，支持为流程实例增加悲观锁，相比于乐观锁机制会导致同一时刻对N1个流程任务中的至少两个流程任务的驱动所带来的冲突回滚问题，可以确保N1个流程任务的串行化执行，避免了潜在的运营风险。又一方面，设置任务执行器后置执行机制，可以有效规避N1个流程任务中同一流程任务对应的任务节点上绑定的任务执行器被重复执行所带来的潜在风险，提高业务场景的安全和可靠。

基于上述对本申请实施例提供的数据处理方案的大致介绍，还需说明如下几点：

①上述是以流程实例中的一次任务驱动过程为例对数据处理方案的示例性流程进行介绍的；在实际应用中，流程实例往往需要经过多次任务驱动，而本次任务驱动的执行流程与前述描述流程是类似的，在此不作赘述。

②如前述，本申请实施例提供的数据处理方案可以部署到工作流引擎中，且部署有数据处理方案的工作流引擎可以在任一业务场景对应的业务流程体系平台中进行流程驱动；这使得本申请实施例提供的数据处理方案可以适用于任意需要流程驱动的业务场景中。如前述提及的网络运营场景，在该网络运营场景下工作流引擎中部署的新驱动模式（即本申请实施例提供的数据处理方案）可以有效确保网络运营流程的任务驱动过程中事务的原子性和数据一致性，维护网络运营场景中的数据安全性和可靠性。

一种示例性地数据处理方案所适用的业务系统的场景示意图可以参见图4，如图4所示，假设业务系统中包括终端401和服务器402。具体实现中，如果使用该业务流程体系平台的任一企业的员工具有请假需求时，可以通过终端401在业务流程体系平台中增加请假流程申请，该请假流程申请为一个请假流程实例。然后，工作流引擎可以按照其部署的基于事务的任务驱动和任务执行器后置执行的驱动模式对该请假流程实例进行驱动；具体是在通过驱动事件驱动请假流程实例之前，先启动事务机制和初始化流程变量，然后通过驱动事件驱动请假流程实例中的多个流程任务之间进行流转；根据多个流程任务的执行结果，生成本次驱动事件对应的驱动过程的事务化处理结果。在该事务化处理结果指示本次驱动事件所驱动的多个流程任务均执行成功时，将本次驱动事件对应的多个流程任务的执行结果以数据库事务的形式提交至服务器402，以将执行结果永久保存于数据库；反之，在该事务化处理结果指示本次驱动事件所驱动流程任务执行失败时，与服务器402进行交互以进行数据库事务回滚。

进一步的，在该事务化处理结果指示本次驱动事件所驱动的多个流程任务均执行成功后，再对本次驱动事件所驱动的多个流程任务对应的多个任务节点上所绑定的任务执行器进行执行，以完成本次驱动事件所驱动的多个流程任务中由用户自定义的业务逻辑。进一步的，如果请假流程实例中还存在待执行的流程任务，则可以等待接收到下一次驱动事件时继续执行该请假流程实例，直至该请假流程实例中的全部流程任务均已执行，并返回给员工本次请假的请假结果（如请假成功或请假失败）。

其中，终端401可以是部署有业务流程体系平台（如该业务流程体系平台为具有请假功能的客户端）和工作流引擎的终端设备；该终端设备可以包括但是不限于：（MobileInternet Devices，MID）、智能电视、车载设备、头戴设备、游戏手柄、遥控器、街机设备等智能设备。服务器402可以该业务流程体系平台的后台服务器，且该服务器中可以部署有数据库管理系统和数据库（或者能够与数据库管理系统进行交互）；服务器402可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络（Content Delivery Network，CDN）、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端401和服务器402可以通过有线或无线方式进行直接或间接地通信连接，本申请实施例并不对终端设备和服务器之间的连接方式进行限定。值得注意的是，本申请实施例提供的数据处理方案可以由计算机设备执行，该计算机设备可以是图4所示系统中的终端和服务器，还可以是终端或服务器，本申请实施例对此不作限定，

③本申请实施例中相关数据收集处理应该严格根据相关法律法规的要求，获取个人信息需得到个人主体的知情或同意（或具备信息获取的合法性基础），并在法律法规及个人信息主体的授权范围内，开展后续数据使用及处理行为。例如，本申请实施例运用到具体产品或技术中时，需要获得用户的许可或者同意，且相关数据的收集、使用和处理需要遵守相关地区的相关法律法规和标准。

基于上述对基于事务的任务驱动和任务执行器后置执行的驱动模式（即数据处理方案）的相关描述，本申请实施例提出更为详细的数据处理方法，下面将结合附图对本申请实施例提出的数据处理方法进行详细介绍。

图5示出了本申请一个示例性实施例提供的一种数据处理方法的流程示意图；该数据处理方法可以由前述提及的计算机设备来执行，该计算机设备可以是部署有工作流引擎的终端或服务器。参见图5所示，该数据处理方法可包括如下步骤S501-S504：

S501：获取业务场景中待处理的流程实例。

正如前述所描述的，流程实例是属于业务场景的一个具体业务流程；且该具体业务流程中包括多个流程任务，且多个流程任务中的任一个流程任务中包含业务场景对应的业务逻辑，该业务逻辑具体可以是流程实例中需要完成的具体工作。根据业务场景或该业务场景中具体的业务需求和业务规则等差异，属于业务场景的流程实例的类型和步骤有所不同。例如，业务场景为网络运营场景，具体为该网络运营场景下的购物订单处理场景，属于该购物订单处理场景的一个流程实例可以包括：用户选择添加至购物车的商品→购物车更新显示所选商品和总价→用户填写配送地址和支付方式→用户提交订单和进行支付→仓库管理系统接收订单准备发货→用户收到订单确认消息→物流公司接收订单并进行配送→…。

在实际执行流程实例时，是按照流程实例中各流程任务的顺序依次创建各流程任务对应的任务节点，并通过执行任务节点来达到执行流程实例的目的。例如，流程实例中依次包括：流程任务1→流程任务2→流程任务3；当驱动流程实例时，先创建流程任务1对应的任务节点1，并执行该任务节点1，在任务节点1执行成功后，创建流程任务2对应的任务节点2，并执行该任务节点2支持流程实例中全部流程任务对应的任务节点均被执行。

需要说明的是，①根据上述属于该购物订单处理场景的流程实例的例子，不难发现流程任务的具体工作可以是由系统自动完成，也可以是由系统推送给用户由用户完成，如上述例子中的流程任务“用户填写配送地址和支付方式”需要由系统（即业务流程体系平台）推送给用户进行操作，而流程任务“购物车更新显示所选商品和总价”只需由系统执行即可。因此，根据流程任务对应的任务节点的执行是否需要由用户完成，可以将任务节点的节点类型大致分为对象（即用户）类型和非对象类型。其中，属于对象类型的任务节点（或称为用户任务节点（UserTask））的具体工作需要系统推送至用户，由该用户来完成具体工作，而属于非对象类型的任务节点的具体工作可以由系统（如工作流引擎）自动完成；其中，属于非对象类型的任务节点可以包括：开始节点、结束节点、服务任务、互斥网关、包容网关和并行网关等等。

②针对流程实例的一次流程驱动过程是由驱动事件（ComplateTask）触发的；并且，一次流程驱动过程的结束条件为：流转到属于对象类型的用户任务节点，或者流转到结束节点。例如，工作流引擎检测到驱动事件时，响应于该驱动事件触发流程实例中流程任务对应的任务节点进行流转，当流转到流程实例中属于对象类型的用户任务节点时，可以结束本次流程驱动过程，等待下一次的驱动事件；当流转到流程实例中的结束节点时，结束本次流程驱动过程的同时结束整个流程实例的流转。为便于阐述，后续以流程实例中包括N1个流程任务，且该N1个流程任务均在第一驱动事件的驱动下执行（即流程实例中位于N1个流程任务中第一个流程任务之前的任务节点为用户任务节点，且N1个流程任务中仅有最后一个流程任务对应的任务节点为用户任务节点或者结束节点）为例对驱动任务流转的过程进行介绍，N1为大于1的整数，特在此说明。

S502：在第一驱动事件的驱动下，执行N1个流程任务。

S503：对第一驱动事件对应的驱动过程进行事务化处理，得到第一驱动事件对应的事务化处理结果。

S504：若第一驱动事件对应的事务化处理结果指示N1个流程任务的执行结果均为执行成功，则在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务提交。

步骤S502-S504中，工作流引擎检测到第一驱动事件时，该第一驱动事件用于驱动N1个流程任务按执行顺序连续流转执行，响应于该第一驱动事件驱动执行流程实例中的N1个流程任务。具体地驱动执行过程可以描述为：按照流程实例中N1个流程任务之间的顺序，先执行N1个流程任务中第一个流程任务对应的任务节点；当第一个流程任务对应的任务节点的执行结果为执行成功时，从第一个流程任务流转至N1个流程任务中的第二个流程任务，并执行该第二个流程任务对应的任务节点；继续上述步骤直至N1个流程任务中的最后一个流程任务对应的任务节点被执行，或者，存在一个流程任务对应的任务节点的执行结果为执行失败。

进一步的，对第一驱动事件对应的驱动过程进行事务化处理，得到第一驱动事件对应的事务化处理结果。所谓事务化处理是指连续流转N1个流程任务的驱动过程是在同一个事务中处理的，或者理解为执行N1个流程任务所产生的对数据库的操作都是在同一事务中处理的；也就是说，将N1个流程任务的执行当作一个整体，要么N1个流程任务全部执行成功，要么全部执行失败（如有一个流程任务执行失败时就认为N1个流程任务均执行失败）。因此，第一驱动事件对应的事务化处理结果可以用于指示受第一驱动事件所驱动执行的N1个流程任务的执行结果，执行结果可能是流程任务执行成功，也可能是流程任务执行失败。

更进一步的，在第一驱动事件对应的事务化处理结果指示：第一驱动事件所驱动的N1个流程任务的执行结果均为执行成功时，表示连续流转的N1个流程任务的具体工作均执行成功，那么工作流引擎执行与第一驱动事件相关的数据库事务提交。此处与第一驱动事件相关的数据库事务提交具体是在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务提交，该数据库事务提交旨在：在数据库中保存执行N1个流程任务所产生的操作。其中，执行N1个流程任务所产生的操作被保存至数据库后，客户端能够从数据库中实时查询与N1个流程任务相关的流程数据。执行N1个流程任务所产生的操作包括以下至少一种：将与N1个流程任务相关的流程数据写入数据库的增加操作；将与N1个流程任务相关的流程数据从数据库中删除的删除操作；对与N1个流程任务相关的流程数据进行修改的修改操作；以及在流程数据中针对与N1个流程任务相关的流程数据的查询操作等等。由此可见，本申请实施例考虑到执行N1个流程任务时，存储于数据库中的与N1个流程任务相关的流程数据可能发生变化（如数据的），因此支持基于事务机制，在N1个流程任务均执行成功时才将执行N1个流程任务所带来的对数据库中数据的影响写入数据库中，从而保证数据库中数据的一致性和可靠性。

在第一驱动事件对应的事务化处理结果指示：第一驱动事件所驱动的N1个流程任务中存在执行结果为执行失败的流程任务时，表示N1个流程任务均执行失败，那么计算机设备进行数据库事务回滚。此处的数据库事务回滚具体是在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务回滚，与第一驱动事件相关的数据库事务回滚旨在：在数据库中撤销执行N1个流程任务所产生的操作。具体是考虑到若N1个流程任务中存在部分流程任务执行成功，那么部分执行成功的流程任务在执行成功后已对数据库中存储的与这部分执行成功的流程任务相关的流程数据进行了更改，而在流转到执行失败的流程任务时，表明本次驱动过程失败，则需要撤销在数据库中执行的与这部分执行成功的流程任务相关的流程数据的更改操作，以便于重新从N1个流程任务中的第一个流程任务驱动流转时，能够保证任务驱动前后的数据库中的数据的一致性。

由此可见，本申请实施例将数据库管理系统中的事务机制（如数据库事务的ACID属性）应用到流程实例的任务驱动过程中，具体是将一次任务驱动中N1个流程任务对数据库的操作（如增、删、改和查等操作）放置到同一数据库事务中处理，可以确保一次任务驱动的过程能够具有原子性，从而确保一次任务驱动前后数据库中的数据能够保持一致，不仅能够提高数据库中数据的可靠性，而且使得工作流引擎中的数据（即流程实例中的流程变量信息或任务数据等）完全可靠。并且，因为确保了数据的一致性，因此所有的外部处理逻辑从数据库中能够访问到的数据（如根据流程任务新创建的任务节点的任务标识（如ID，将根据此ID提交下一轮的驱动任务），或者新写入的流程变量key）一定是存在的。那么，工作流引擎给出的任务节点的任务标识就一定是有效的，从而避免任务标识提交的重试过程，进而避免了数据资源（如新创建的任务节点的任务标识）不存在引发的重试成本。

为便于理解，下面结合图6对上述描述的基于事务的任务驱动过程进行介绍。在图6所示的流程实例中，如果互斥网关C满足a=1，那么第一驱动事件对应的驱动过程，或者第一次任务节点的流转过程，包括：A→B→C→D→E→F，F为属于对象类型的用户任务节点（即用户任务-5）；在第一驱动事件对应的驱动过程结束后，等待下一次驱动事件（如第二驱动事件），该下一次驱动事件的驱动位置为F。然后，在第一驱动事件的驱动下，执行A→B→C→D→E→F的任务流转，并对从A→B→C→D→E→F的驱动过程进行事务化处理，即从A到F要么全部驱动成功，要么全部驱动失败回到起始位置A。如果第一驱动事件对应的驱动过程驱动成功，即第一驱动事件对应的事务化处理结果指示A→B→C→D→E→F中的每一个任务节点均执行成功，则进行数据库事务提交，第一驱动事件对应的驱动过程中的所有流程数据实时生效，上层应用可以从数据库中查询第一驱动事件对应的驱动过程结束后最新的流程数据，如最新的任务数据和相关设置的流程变量。反之，如果第一驱动事件对应的驱动过程驱动失败，即第一驱动事件对应的事务化处理结果指示A→B→C→D→E→F的驱动过程中存在任务节点执行失败，则进行数据库事务回滚，具体是从数据库中撤销本次驱动过程中产生全部操作，从外部视角来看等价于第一驱动事件对应的驱动过程从未发生。同理，a=2时，一次任务驱动的过程可以包括：A→B→C→用户任务-3；在该任务驱动成功后，下一次任务驱动的过程可以包括：服务任务-6→用户任务-7；上面两次任务驱动的具体实施过程可以参见前述A→B→C→D→E→F驱动过程的相关描述，在此不作赘述。

为进一步理解基于事务的任务驱动过程与具体业务场景之间的结合，下面结合图7对基于事务机制对转账流程实例进行任务驱动的过程进行示例性介绍。如图7所示，假设用户A的账户A中有100元，用户B的账户B中有50元，且用户A需要向用户B转账20元，那么该转账流程实例可以包括：任务节点1→任务节点2；其中，任务节点1的业务逻辑为从账户A中扣除20元，任务节点B的业务逻辑为在账户B中增加20元。如果工作流引擎检测到针对流程实例的驱动事件，那么可以顺序执行任务节点1和任务节点2，且对驱动过程进行事务化处理；若事务化处理结果指示任务节点1和任务节点2均执行成功，表明已经在数据库中为账户A扣除20元，为账户B增加20元，则进行数据库事务提交，以在数据库中永久保存驱动过程中产生的操作（即为账户A扣除20元，为账户B增加20元的操作）。若事务化处理结果指示任务节点1和任务节点2中存在执行失败的任务节点，则进行数据库事务回滚；如任务节点1执行成功，但任务节点2执行失败，则在数据库中撤销从账户A中扣除20元的操作，以保证转账流程实例执行前后数据库中的数据始终处于有效状态（或正确状态）。不难看出，通过将转账的整个驱动过程进行事务化处理，可以保证转账的整个驱动过程对数据库的操作在驱动成功时同时生效，在驱动失败时全部作废（用户的感知效果为驱动过程并未发生过），从而确保驱动过程中事务的原子性和数据一致性。

值得注意的是，上述步骤S501-S504是以流程实例中的一次任务驱动过程为例，对任务驱动过程中的事务化处理进行介绍的。在实际应用中，流程实例可以有多次任务驱动，那么每一次任务驱动过程可以参见前述步骤S501-S504所示实施例的具体实施过程。举例来说，假设流程实例中还包括N2个流程任务，该N2个流程任务的执行顺序位于N1个流程任务之后，且N2个流程任务均在第二驱动事件的驱动下执行，N2为大于1的整数。那么，在第一驱动事件对应的驱动过程驱动成功的情况下，等待下一次驱动事件，若工作流引擎检测到针对N2个流程任务的第二驱动事件，则在该第二驱动事件的驱动下执行N2个流程任务，并对第二驱动事件对应的驱动过程进行事务化处理，得到该第二驱动事件对应的事务化处理结果，该第二驱动事件对应的事务化处理结果用于指示N2个流程任务的执行结果。与前述描述的第一驱动事件对应的事务化处理结果的处理方式类似的，若第二驱动事件对应的事务化处理结果指示N2个流程任务的执行结果均为执行成功，则在业务场景对应的数据库中进行与第二驱动事件相关的数据库事务提交，此时与第二驱动事件相关的数据库事务提交用于指示在数据库中保存执行N2个流程任务所产生的操作。

反之，若第二驱动事件对应的事务化处理结果指示N2个流程任务中存在执行结果为执行失败的流程任务，则在业务场景对应的数据库中进行与第二驱动事件相关的数据库事务回滚，以在数据库中撤销第二驱动事件对应的驱动过程所产生的操作，使数据库中保持第一驱动事件对应的驱动过程执行结束后的数据；并且，等待下一次驱动事件，以再次驱动N2个流程任务的执行。当然，如果流程实例中还包括执行顺序晚于N2个流程任务的N3个流程任务（N3为大于1的整数），那么在N2个流程任务均驱动成功的情况下，继续执行该流程实例，支持达到流程实例停止驱动的结束条件；该流程实例停止驱动的结束条件为：流程实例中的最后一个流程任务被执行，即流程实例中的全部流程任务均被执行。由此可见，本申请实施例基于事务机制实现流程实例中各任务驱动，可以保证每个任务驱动过程均具有原子性和数据一致性，不仅维护数据库中数据的可靠性，还能够确保每次任务驱动过程后的数据立即生效，避免数据不可信的问题，从而确保流程实例能够正确流转。

综上所述，本申请实施例在基于第一驱动事件对N1个流程任务进行驱动的驱动过程中，支持基于事务机制来对该驱动过程进行事务化处理，即将N1个流程任务的执行当作同一事务中的处理，可以确保流程实例中的驱动过程具有事务的原子性，即N1个流程任务要么全部驱动成功，要么全部驱动失败。进一步的，在第一驱动事件对应的事务化处理结果指示N1个流程任务均执行成功时，在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务提交；数据库事务提交后N1个流程任务的执行过程中的所有流程数据的更改同时生效，从而确保数据库中与该N1个流程任务相关的流程数据的数据状态具有一致性（即数据库中与N1个流程任务相关的流程数据均为流程任务被成功执行后的有效数据或正常数据）。

图8示出了本申请一个示例性实施例提供的另一种数据处理方法的流程示意图；该数据处理方法可以由前述提及的计算机设备来执行，该计算机设备可以是部署有工作流引擎的终端或服务器。参见图8所示，该数据处理方法可包括如下步骤S801-S807：

S801：获取业务场景中待处理的流程实例。

需要说明的是，步骤S801所示的具体内容可以参见前述图5所示实施例中步骤S501所示的具体实施过程的相关描述，在此不作赘述。

S802：为流程实例设置流程实例锁。

S803：在与N1个流程任务相关的流程数据处于锁定状态下，触发执行在第一驱动事件的驱动下，执行N1个流程任务的步骤。

步骤S802-S803中，本申请实施例涉及的流程实例锁是前述提及的悲观锁；在流程实例中增加的该流程实例锁可以用于在驱动过程中对与N1个流程任务相关的流程数据执行锁定操作，通过该锁定操作锁定与N1个流程任务相关的流程数据，使得被执行锁定操作的与N1个流程任务相关的流程数据处于锁定状态。也就是说，本申请实施例支持为流程实例增加流程实例级悲观锁，可以通过该悲观锁确保在流程实例中的一次任务驱动过程中，锁定流程实例当前的数据状态（即与该任务驱动过程相关的流程数据，如与第一驱动事件对应的驱动过程中的N1个流程任务相关的流程数据），使数据不因为其他操作（如其他用户针对该数据执行的操作，如更改数值等操作）发生变化，避免在一次任务驱动的驱动过程中因数据变化导致前后数据不一致。

在一种实现方式中，支持为流程实例表增加流程实例锁，从而实现为待处理的流程实例增加流程实例锁。其中，流程实例表是业务场景对应的数据库的数据库表（可以表示为act_inst），可以用于存储数据库中的流程实例信息；具体可以用于存储至少一个流程实例的实例标识（用于唯一标识一个流程实例），此处的至少一个流程实例中包括本申请实施例提及的待处理的流程实例。也就是说，本申请实施例支持为数据库的整个流程实例表增加流程实例锁，此实现方式下，为流程实例表增加流程实例锁后，整个流程实例表中的每个实例标识对应的流程实例均被添加流程实例锁；这样，流程实例锁对流程实例表中的每个实例标识对应的流程实例均具有锁定权限和解锁权限。这种对整个流程实例表设置流程实例锁的方式，可以达到为该流程实例表中多个实例标识对应的流程实例均设置流程实例锁的目的，从而实现批量流程实例锁的添加，提高流程实例锁的设置效率。

其他实现方式，支持从流程实例表中选择待处理的流程实例对应的实例标识，并针对该待处理的流程实例设置流程实例锁。也就是说，可以针对性地对流程实例表中需要增加悲观锁的流程实例进行悲观锁的增加，实现流程实例锁的自定义增加，丰富用户增加流程实例锁时针对流程实例的选择权限。具体实现中，获取业务场景对应的数据库的流程实例表，如前述该流程实例表用于存储至少一个流程实例的实例标识，该至少一个流程实例中包括待处理的流程实例。然后，从流程实例表中确定出待处理的流程实例的实例标识；这样，可以基于该待处理的流程实例的实例标识，为该待处理的流程实例增加流程实例锁，此时流程实例锁只能针对该待处理的流程实例进行锁定和释放。

更详细地，为流程实例增加悲观锁，是通过acquireInstanceOpLock()函数来实现的，本质上是数据库事务过程中的一个加速动作；其中，该acquireInstanceOpLock()函数是一个具有锁定数据的功能的函数。例如，流程实例的实例标识表示为instanceId，那么为该流程实例增加悲观锁的语句可以表示为：err:=acquireInstanceOpLock(0.db，instanceId)，表示采用acquireInstanceOpLock()函数对实例标识为instanceId的流程实例进行锁定，具体是在该流程实例的驱动过程中锁定相应的流程数据。

基于上述实现方式，为流程实例增加流程实例锁后，工作流引擎在检测到第一驱动事件时，可以先通过该流程实例锁将与N1个流程任务相关的流程数据进行锁定操作，被执行锁定操作后的与N1个流程任务相关的流程数据处于锁定状态；这样，在针对N1个流程任务的驱动过程中，其他操作不会对与N1个流程任务相关的流程数据进行更改。然后，在与N1个流程任务相关的流程数据处于锁定状态下，执行步骤S804。

S804：在第一驱动事件的驱动下，执行N1个流程任务。

S805：对第一驱动事件对应的驱动过程进行事务化处理，得到第一驱动事件对应的事务化处理结果。

S806：若第一驱动事件对应的事务化处理结果指示N1个流程任务的执行结果均为执行成功，则在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务提交。

需要说明的是，步骤S804-S806所示的具体实施例过程，可以参见前述图5所示实施例中步骤S502-S504所示的具体实施过程的相关描述，在此不作赘述。

另外，在为流程实例增加流程实例锁之后，在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务提交的同时，或者，在对业务场景对应的数据库进行与第一驱动事件相关的数据库事务回滚的同时，还需要释放流程实例锁，具体是释放流程实例锁针对与N1个流程任务相关的流程数据的锁定操作。其中，释放锁定操作后，与N1个流程任务相关的流程数据从锁定状态变换为可更新状态，即释放悲观锁后，与N1个流程任务相关的流程数据处于可更新状态，此可更新状态下其他操作可以对与N1个流程任务相关的流程数据进行操作（如更改数值等）。

基于上述步骤S801-S806的相关描述可知，本申请实施例可以通过如下两方面来确保一次任务驱动过程中的数据一致性：一方面，支持通过数据库事务的ACID特性来确保流程实例中的每次任务驱动过程（驱过过程本质上就是对数据库中的数据进行的一系列增、删、改和查操作）的原子性和数据一致性；任务驱动过程中的所有流程任务要么全部操作成功，要么全部操作失败(回滚)，只有任务驱动过程中的全部流程任务均操作成功后，才进行数据库事务的提交，保证与该任务驱动过程相关的所有流程数据（即与N1个流程日任务相关的流程数据）同时生效，以此来保证所有数据状态的一致性。另一方面，支持增加流程实例级的悲观锁，确保在一次任务驱动过程中，锁定流程实例当前的数据状态，使数据不再（因其它用户操作）发生变化，避免在驱动过程中因数据变化导致前后数据不一致。

S807：执行任务节点中绑定的任务执行器。

正如前述所描述的，在第一驱动事件的驱动下执行N1个流程任务时，具体是在驱动过程中N1个流程任务均创建有对应的任务节点，任务节点承载有相应流程任务所包含业务场景对应的业务逻辑。并且，N1个流程任务中存在有流程任务对应的任务节点绑定任务执行器，即在流程任务具有用户自定义的业务逻辑时，在该流程任务对应的任务节点上绑定任务执行器，该任务执行器承载相应流程任务所包含的参考业务逻辑，该参考业务逻辑是由用户自定义的业务逻辑。假设第一驱动事件下驱动执行的N1个流程任务中存在流程任务对应的任务节点绑定有任务执行器，本申请实施例支持设计执行器后置执行的设计模式（或机制）来后置执行任务节点绑定的任务执行器。所谓后置执行指的是：在第一驱动事件的驱动下，对N1个流程任务均执行成功（即第一驱动事件对应的数据库事务已经提交成功）时，才进入N1个流程任务的任务执行器的执行（即N1个流程任务对应的任务执行器的执行时机是第一驱动事件对应的驱动过程驱动成功，且已成功进行数据库事务提交）。

相比于现有流程流转的过程中，执行任务节点时同时执行该任务节点上绑定的任务执行器而言，本申请实施例提供的这种执行器后置执行的机制，考虑到第一驱动事件下的驱动过程中，N1个流程任务对应的任务节点上绑定的含有具体业务逻辑的任务执行器并未开始执行。因此，在第一驱动事件下的整个驱动过程中出现任何异常引发数据库事务回滚时，都不会对流程实例中的具体业务逻辑的执行（即任务执行器所承载的业务逻辑）产生任何负面影响，以此解决传统流程引擎中因驱动失败导致任务执行器被重复执行所带来的问题，如在网络运营场景中可以有效避免潜在的运行风险。

具体实现中，基于前述步骤S801-S806，在第一驱动事件的驱动下成功驱动N1个流程任务，且在业务场景对应的数据库中成功进行与第一驱动事件相关的数据库事务提交后，方可执行N1个流程任务对应的任务节点所绑定的任务执行器。其中，N1个流程任务中可能全部或部分的流程任务对应的任务节点上绑定有任务执行器，本申请实施例对N1个流程任务对应的任务节点中绑定有任务执行器的任务节点的数量和节点类型不作限定，特在此说明。

进一步的，为提高多个任务执行器的执行效率，本申请实施例还支持采用异步并行的方式后置执行多个任务执行器。其中，异步并行中的异步是指不同的任务执行器之间并不会相互等待，而是可以同时执行；如在执行任务执行器A时也可以同时运行任务执行器B；异步并行中的并行是指两个或者多个任务执行器可以同时执行；异步是多个任务执行器并行执行的前提条件，只有实现了异步，才能实现多个任务执行器真正的并行执行。在执行器执行阶段，采用异步并行机制对多个任务执行器进行执行，相对于传统的流程驱动过程中串行执行任务执行器的设计模式，极大地提高了任务执行器的执行效率，且能够确保任一任务执行器出现异常需退出时不会影响其他任务执行器的执行，保证整个流程实例的正常运行。

其中，异步并行多个任务执行器的过程可以描述为：假设N1个流程任务对应的多个任务节点（如一个流程任务对应一个任务节点，或者一个流程任务对应的多个任务节点）中存在M个任务节点绑定有任务执行器，M为正整数，且M≤N1；那么，在第一驱动事件对应的事务化处理结果指示N1个流程任务均执行成功，且已成功进行数据库事务提交后，可以对M个任务节点中绑定的任务执行器进行异步并行执行。示例性地异步并行执行任务执行器的大致过程可以参见前述图3所示的任务执行器执行阶段。

需要说明的是，流程任务对应的任务节点在节点创建过程中可能分阶段绑定任务执行器，如流程任务对应的任务节点在节点创建的开始阶段和结束阶段可能均绑定有任务执行器。考虑到第一驱动事件对应的驱动过程的结束条件是流转到属于对象属性的用户任务节点，而因为用户任务节点创建后，第一驱动事件对应的驱动过程就结束了，即驱动结束时该用户任务节点还是处于运行中状态（即未运行到结束阶段），因此用户任务节点在结束阶段绑定的任务执行器不会在第一驱动事件之后被执行，而是在下一次驱动事件的驱动过程结束后被执行。不同的是，N1个流程任务中除最后一个流程任务对应的用户任务节点外的其他任务节点，在驱动结束时均被执行，因此该其他任务节点在节点创建的开始阶段和结束阶段所绑定的任务执行器均被异步并行执行。也就是说，假设N1个流程任务对应的多个任务节点中存在M个任务节点绑定有任务执行器时，M个任务节点所绑定的任务执行器中，被异步并行执行的任务执行器包括：M个任务节点中除属于对象类型的任务节点外的每个任务节点在节点创建的开始阶段和结束阶段绑定的任务执行器，以及，M个任务节点中属于对象类型的任务节点在节点创建的开始阶段绑定的任务执行器；而M个任务节点中属于对象类型的任务节点在节点创建的结束阶段绑定的任务执行器，在第一驱动事件的下一个驱动事件（如前述提及的第二驱动事件）中被执行。

如图9所示，假设N1=3，分别为任务节点1→任务节点2→任务节点3，且各任务节点在节点创建的开始阶段和结束阶段均绑定有任务执行器，如任务节点1的节点创建的开始阶段和结束阶段分别绑定有任务执行器1和任务执行器2，任务节点2的节点创建的开始阶段和结束阶段分别绑定有任务执行器3和任务执行器4，任务节点3的节点创建的开始阶段和结束阶段分别绑定有任务执行器5和任务执行器6。那么在针对N1个流程任务的驱动过程结束且成功提交数据库事务后，可以进入任务执行器执行阶段，在该执行阶段中任务执行器1、任务执行器2、任务执行器3、任务执行器4和任务执行器5可以异步并行执行，而任务执行器6等待下一次驱动事件对应的驱动过程结束且事务提交后再执行。当然，如果流程实例中还包括执行顺序位于N1个流程任务之前的流程任务，那么第一驱动事件对应的驱动过程结束且事务提交成功后，在任务执行器执行阶段还会异步并行执行顺序早于N1个流程任务的多个流程任务中最后一个流程任务对应任务节点在结束阶段所绑定的任务执行器。

综上所述，一方面，本申请实施例在流程实例中引入事务化机制，将N1个流程任务的操作放置到同一事务中；相比于单个流程任务各自进行事务提交或事务回滚而言，有效利用数据库事务的ACID属性确保一次驱动事件对应的驱动过程（即任务驱动过程）能够确保事务的原子性；且一次驱动事件对应的所有流程任务均执行成功后才进行数据库事务提交，数据库事务提交后N1个流程任务的执行过程中的所有流程数据的更改同时生效，从而确保数据库中与该N1个流程任务相关的流程数据的数据状态具有一致性（即数据库中与N1个流程任务相关的流程数据均为流程任务被成功执行后的有效数据或正常数据），避免数据不可信等问题，提高业务流程的可靠性。另一方面，本申请实施例移除流程实例中原本的乐观锁，转而为流程实例增加悲观锁，相比于乐观锁机制会导致同一时刻对N1个流程任务中的至少两个流程任务的驱动所带来的冲突回滚问题，可以确保流程实例内部的串行化执行（如N1个流程任务的串行化执行），避免了潜在的运营风险。又一方面，本申请实施例支持设置任务执行器后置异步并行执行的机制，可以有效规避N1个流程任务中同一流程任务对应的任务节点上绑定的任务执行器被重复执行所带来的潜在风险，提高业务场景的安全和可靠，且通过异步并行的执行方式极大地提升任务执行器的执行效率，确保任一任务执行器出现异常时能够安全退出。

上述详细阐述了本申请实施例的方法，为了便于更好地实施本申请实施例的上述方案，相应地，下面提供了本申请实施例的装置。本申请实施例中，术语“模块”或“单元”是指有预定功能的计算机程序或计算机程序的一部分，并与其他相关部分一起工作以实现预定目标，并且可以通过使用软件、硬件（如处理电路或存储器）或其组合来全部或部分实现。同样的，一个处理器（或多个处理器或存储器）可以用来实现一个或多个模块或单元。此外，每个模块或单元都可以是包含该模块或单元功能的整体模块或单元的一部分。

图10示出了本申请一个示例性实施例提供的一种数据处理装置的结构示意图；该数据处理装置可以用于执行图5和图8所示的方法实施例中的部分或全部步骤。请参见图10，该装置包括如下单元：

获取单元1001，用于获取业务场景中待处理的流程实例；流程实例中包括N1个流程任务，且N1个流程任务均在第一驱动事件的驱动下执行；流程任务中包含业务场景对应的业务逻辑；N1为大于1的整数；

处理单元1002，用于在第一驱动事件的驱动下，执行N1个流程任务；

处理单元1002，还用于对第一驱动事件对应的驱动过程进行事务化处理，得到第一驱动事件对应的事务化处理结果，第一驱动事件对应的事务化处理结果用于指示N1个流程任务的执行结果；

处理单元1002，还用于若第一驱动事件对应的事务化处理结果指示N1个流程任务的执行结果均为执行成功，则在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务提交；与第一驱动事件相关的数据库事务提交用于指示在数据库中保存执行N1个流程任务所产生的操作。

在一种实现方式中，处理单元1002，还用于：

若第一驱动事件对应的事务化处理结果指示N1个流程任务中存在执行结果为执行失败的流程任务，则在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务回滚；与第一驱动事件相关的数据库事务回滚用于指示在数据库中撤销执行N1个流程任务所产生的操作；

其中，执行N1个流程任务所产生的操作被保存至数据库后，客户端能够从数据库中实时查询与N1个流程任务相关的流程数据；执行N1个流程任务所产生的操作包括以下至少一种：将与N1个流程任务相关的流程数据写入数据库的增加操作；将与N1个流程任务相关的流程数据从数据库中删除的删除操作；对与N1个流程任务相关的流程数据进行修改的修改操作；以及在数据库中针对与N1个流程任务相关的流程数据的查询操作。

在一种实现方式中，处理单元1002，还用于：

为流程实例设置流程实例锁；流程实例锁用于在驱动过程中对与N1个流程任务相关的流程数据执行锁定操作，被执行锁定操作的与N1个流程任务相关的流程数据处于锁定状态；

在与N1个流程任务相关的流程数据处于锁定状态下，触发执行在第一驱动事件的驱动下，执行N1个流程任务的步骤。

在一种实现方式中，处理单元1002，用于为流程实例设置流程实例锁时，具体用于：

获取业务场景对应的数据库的流程实例表；流程实例表用于存储至少一个流程实例的实例标识，至少一个流程实例中包括待处理的流程实例；

从流程实例表中确定出待处理的流程实例的实例标识；

基于待处理的流程实例的实例标识，为待处理的流程实例增加流程实例锁。

在一种实现方式中，处理单元1002，用于为流程实例设置流程实例锁时，具体用于：

获取业务场景对应的数据库的流程实例表；流程实例表用于存储至少一个流程实例的实例标识，至少一个流程实例中包括待处理的流程实例；

为流程实例表增加流程实例锁；其中，流程实例表中的每个实例标识对应的流程实例均被增加流程实例锁。

在一种实现方式中，在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务提交的同时，或者，在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务回滚的同时，处理单元1002，还用于：

释放流程实例锁针对与N1个流程任务相关的流程数据的锁定操作；释放锁定操作后，与N1个流程任务相关的流程数据处于可更新状态。

在一种实现方式中，流程实例中还包括N2个流程任务，N2个流程任务的执行顺序位于N1个流程任务之后，且N2个流程任务均在第二驱动事件的驱动下执行；N2为大于1的整数；处理单元1002，还用于：

在第二驱动事件的驱动下，执行N2个流程任务；

对第二驱动事件对应的驱动过程进行事务化处理，得到第二驱动事件对应的事务化处理结果；第二驱动事件对应的事务化处理结果用于指示N2个流程任务的执行结果；

若第二驱动事件对应的事务化处理结果指示N2个流程任务的执行结果均为执行成功，则在业务场景对应的数据库中进行与第二驱动事件相关的数据库事务提交；与第二驱动事件相关的数据库事务提交用于指示在数据库中保存执行N2个流程任务所产生的操作；

其中，流程实例停止驱动的结束条件为流程实例中的最后一个流程任务被执行。

在一种实现方式中，在驱动过程中N1个流程任务中的每个流程任务均创建有对应的任务节点，任务节点承载有相应流程任务所包含业务场景对应的业务逻辑；N1个流程任务中存在有流程任务对应的任务节点绑定任务执行器，任务执行器承载有相应流程任务所包含的参考业务逻辑，参考业务逻辑是由用户自定义的业务逻辑；处理单元1002，还用于：

执行任务节点中绑定的任务执行器。

在一种实现方式中，M个任务节点绑定有任务执行器，M为正整数，且M≤N1；处理单元1002，用于执行任务节点中绑定的任务执行器时，具体用于：

对M个任务节点中绑定的任务执行器进行异步并行执行。

在一种实现方式中，流程任务对应的任务节点在节点创建的开始阶段和结束阶段均绑定有任务执行器；

其中，M个任务节点中绑定的任务执行器中，被异步并行执行的任务执行器包括：M个任务节点中除属于对象类型的任务节点外的每个任务节点在节点创建的开始阶段和结束阶段绑定的任务执行器，以及，M个任务节点中属于对象类型的任务节点在节点创建的开始阶段绑定的任务执行器；

M个任务节点中属于对象类型的任务节点在节点创建的结束阶段绑定的任务执行器，在第一驱动事件的下一个驱动事件中被执行。

根据本申请的一个实施例，图10所示的数据处理装置中的各个单元可以分别或全部合并为一个或若干个另外的单元来构成，或者其中的某个（些）单元还可以再拆分为功能上更小的多个单元来构成，这可以实现同样的操作，而不影响本申请的实施例的技术效果的实现。上述单元是基于逻辑功能划分的，在实际应用中，一个单元的功能也可以由多个单元来实现，或者多个单元的功能由一个单元实现。在本申请的其它实施例中，该图像处理装置也可以包括其它单元，在实际应用中，这些功能也可以由其它单元协助实现，并且可以由多个单元协作实现。根据本申请的另一个实施例，可以通过在包括中央处理单元（CPU）、随机存取存储介质（RAM）、只读存储介质（ROM）等处理元件和存储元件的例如计算机的通用计算设备上运行能够执行如图5及图8所示的相应方法所涉及的各步骤的计算机程序（包括程序代码），来构造如图10中所示的图像数据处理装置，以及来实现本申请实施例的数据处理方法。计算机程序可以记载于例如计算机可读记录介质上，并通过计算机可读记录介质装载于上述计算设备中，并在其中运行。

本申请实施例中，获取的业务场景中待处理的流程实例中包括N1个流程任务，且在第一驱动事件的驱动下可以执行该N1个流程任务。然而，支持对第一驱动事件对应的驱动过程（即执行N1个流程事务的任务驱动过程）进行事务化处理，得到第一驱动事件对应的事务化处理结果，该第一驱动事件对应的事务化处理结果用于指示N1个流程任务的执行结果；通过在N1个流程任务的驱动过程中引入事务化机制，即将N1个流程任务的执行当作同一事务中的处理，可以确保流程实例中的驱动过程具有事务的原子性，即N1个流程任务要么全部驱动成功，要么全部驱动失败。进一步的，在第一驱动事件对应的事务化处理结果指示N1个流程任务均执行成功时，在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务提交；数据库事务提交后N1个流程任务的执行过程中的所有流程数据的更改同时生效，从而确保数据库中与该N1个流程任务相关的流程数据的数据状态具有一致性（即数据库中与N1个流程任务相关的流程数据均为流程任务被成功执行后的有效数据或正常数据）。综上所述，本申请实施例有效利用数据库事务的特性来确保流程实例中N1个流程任务的流转过程（或驱动过程）的原子性和数据一致性，以实现完成一次任务驱动（或称为流程驱动）所产生的流程数据立即生效，避免数据不可信等问题，提高业务流程的可靠性。

图11示出了本申请一个示例性实施例提供的一种计算机设备的结构示意图。请参见图11，该计算机设备包括处理器1101、通信接口1102以及计算机可读存储介质1103。其中，处理器1101、通信接口1102以及计算机可读存储介质1103可通过总线或者其它方式连接。其中，通信接口1102用于接收和发送数据。计算机可读存储介质1103可以存储在计算机设备的存储器中，计算机可读存储介质1103用于存储计算机程序，计算机程序包括程序指令，处理器1101用于执行计算机可读存储介质1103存储的程序指令。处理器1101（或称CPU（Central Processing Unit，中央处理器））是计算机设备的计算核心以及控制核心，其适于实现一条或多条指令，具体适于加载并执行一条或多条指令从而实现相应方法流程或相应功能。

本申请实施例还提供了一种计算机可读存储介质（Memory），计算机可读存储介质是计算机设备中的记忆设备，用于存放程序和数据。可以理解的是，此处的计算机可读存储介质既可以包括计算机设备中的内置存储介质，当然也可以包括计算机设备所支持的扩展存储介质。计算机可读存储介质提供存储空间，该存储空间存储了计算机设备的处理系统。并且，在该存储空间中还存放了适于被处理器1101加载并执行的一条或多条的指令，这些指令可以是一个或多个的计算机程序（包括程序代码）。需要说明的是，此处的计算机可读存储介质可以是高速RAM存储器，也可以是非不稳定的存储器（non-volatile memory），例如至少一个磁盘存储器；可选的，还可以是至少一个位于远离前述处理器的计算机可读存储介质。

在一个实施例中，该计算机可读存储介质中存储有一条或多条指令；由处理器1101加载并执行计算机可读存储介质中存放的一条或多条指令，以实现上述数据处理方法实施例中的相应步骤；具体实现中，计算机可读存储介质中的一条或多条指令由处理器1101加载并执行如下步骤：

获取业务场景中待处理的流程实例；流程实例中包括N1个流程任务，且N1个流程任务均在第一驱动事件的驱动下执行；流程任务中包含业务场景对应的业务逻辑；N1为大于1的整数；

在第一驱动事件的驱动下，执行N1个流程任务；

对第一驱动事件对应的驱动过程进行事务化处理，得到第一驱动事件对应的事务化处理结果，第一驱动事件对应的事务化处理结果用于指示N1个流程任务的执行结果；

若第一驱动事件对应的事务化处理结果指示N1个流程任务的执行结果均为执行成功，则在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务提交；与第一驱动事件相关的数据库事务提交用于指示在数据库中保存执行N1个流程任务所产生的操作。

在一种实现方式中，计算机可读存储介质中的一条或多条指令由处理器1101加载并还执行如下步骤：

若第一驱动事件对应的事务化处理结果指示N1个流程任务中存在执行结果为执行失败的流程任务，则在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务回滚；与第一驱动事件相关的数据库事务回滚用于指示在数据库中撤销执行N1个流程任务所产生的操作；

其中，执行N1个流程任务所产生的操作被保存至数据库后，客户端能够从数据库中实时查询与N1个流程任务相关的流程数据；执行N1个流程任务所产生的操作包括以下至少一种：将与N1个流程任务相关的流程数据写入数据库的增加操作；将与N1个流程任务相关的流程数据从数据库中删除的删除操作；对与N1个流程任务相关的流程数据进行修改的修改操作；以及在数据库中针对与N1个流程任务相关的流程数据的查询操作。

在一种实现方式中，计算机可读存储介质中的一条或多条指令由处理器1101加载并还执行如下步骤：

为流程实例设置流程实例锁；流程实例锁用于在驱动过程中对与N1个流程任务相关的流程数据执行锁定操作，被执行锁定操作的与N1个流程任务相关的流程数据处于锁定状态；

在与N1个流程任务相关的流程数据处于锁定状态下，触发执行在第一驱动事件的驱动下，执行N1个流程任务的步骤。

在一种实现方式中，计算机可读存储介质中的一条或多条指令由处理器1101加载并在执行为流程实例设置流程实例锁时，具体执行如下步骤：

获取业务场景对应的数据库的流程实例表；流程实例表用于存储至少一个流程实例的实例标识，至少一个流程实例中包括待处理的流程实例；

从流程实例表中确定出待处理的流程实例的实例标识；

基于待处理的流程实例的实例标识，为待处理的流程实例增加流程实例锁。

在一种实现方式中，计算机可读存储介质中的一条或多条指令由处理器1101加载并在执行为流程实例设置流程实例锁时，具体执行如下步骤：

获取业务场景对应的数据库的流程实例表；流程实例表用于存储至少一个流程实例的实例标识，至少一个流程实例中包括待处理的流程实例；

为流程实例表增加流程实例锁；其中，流程实例表中的每个实例标识对应的流程实例均被增加流程实例锁。

在一种实现方式中，在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务提交的同时，或者，在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务回滚的同时，计算机可读存储介质中的一条或多条指令由处理器1101加载并还执行如下步骤：

释放流程实例锁针对与N1个流程任务相关的流程数据的锁定操作；释放锁定操作后，与N1个流程任务相关的流程数据处于可更新状态。

在一种实现方式中，流程实例中还包括N2个流程任务，N2个流程任务的执行顺序位于N1个流程任务之后，且N2个流程任务均在第二驱动事件的驱动下执行；N2为大于1的整数；计算机可读存储介质中的一条或多条指令由处理器1101加载并还执行如下步骤：

在第二驱动事件的驱动下，执行N2个流程任务；

对第二驱动事件对应的驱动过程进行事务化处理，得到第二驱动事件对应的事务化处理结果；第二驱动事件对应的事务化处理结果用于指示N2个流程任务的执行结果；

若第二驱动事件对应的事务化处理结果指示N2个流程任务的执行结果均为执行成功，则在业务场景对应的数据库中进行与第二驱动事件相关的数据库事务提交；与第二驱动事件相关的数据库事务提交用于指示在数据库中保存执行N2个流程任务所产生的操作；

其中，流程实例停止驱动的结束条件为流程实例中的最后一个流程任务被执行。

在一种实现方式中，在驱动过程中N1个流程任务中的每个流程任务均创建有对应的任务节点，任务节点承载有相应流程任务所包含业务场景对应的业务逻辑；N1个流程任务中存在有流程任务对应的任务节点绑定任务执行器，任务执行器承载有相应流程任务所包含的参考业务逻辑，参考业务逻辑是由用户自定义的业务逻辑；计算机可读存储介质中的一条或多条指令由处理器1101加载并还执行如下步骤：

执行任务节点中绑定的任务执行器。

在一种实现方式中，M个任务节点绑定有任务执行器，M为正整数，且M≤N1；计算机可读存储介质中的一条或多条指令由处理器1101加载并在执行任务节点中绑定的任务执行器时，具体执行如下步骤：

对M个任务节点中绑定的任务执行器进行异步并行执行。

在一种实现方式中，流程任务对应的任务节点在节点创建的开始阶段和结束阶段均绑定有任务执行器；

其中，M个任务节点中绑定的任务执行器中，被异步并行执行的任务执行器包括：M个任务节点中除属于对象类型的任务节点外的每个任务节点在节点创建的开始阶段和结束阶段绑定的任务执行器，以及，M个任务节点中属于对象类型的任务节点在节点创建的开始阶段绑定的任务执行器；

M个任务节点中属于对象类型的任务节点在节点创建的结束阶段绑定的任务执行器，在第一驱动事件的下一个驱动事件中被执行。

本申请实施例中，获取的业务场景中待处理的流程实例中包括N1个流程任务，且在第一驱动事件的驱动下可以执行该N1个流程任务。然而，支持对第一驱动事件对应的驱动过程（即执行N1个流程事务的任务驱动过程）进行事务化处理，得到第一驱动事件对应的事务化处理结果，该第一驱动事件对应的事务化处理结果用于指示N1个流程任务的执行结果；通过在N1个流程任务的驱动过程中引入事务化机制，即将N1个流程任务的执行当作同一事务中的处理，可以确保流程实例中的驱动过程具有事务的原子性，即N1个流程任务要么全部驱动成功，要么全部驱动失败。进一步的，在第一驱动事件对应的事务化处理结果指示N1个流程任务均执行成功时，在业务场景对应的数据库中进行与第一驱动事件相关的数据库事务提交；数据库事务提交后N1个流程任务的执行过程中的所有流程数据的更改同时生效，从而确保数据库中与该N1个流程任务相关的流程数据的数据状态具有一致性（即数据库中与N1个流程任务相关的流程数据均为流程任务被成功执行后的有效数据或正常数据）。综上所述，本申请实施例有效利用数据库事务的特性来确保流程实例中N1个流程任务的流转过程（或驱动过程）的原子性和数据一致性，以实现完成一次任务驱动（或称为流程驱动）所产生的流程数据立即生效，避免数据不可信等问题，提高业务流程的可靠性。

本申请实施例还提供一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述数据处理方法。

本领域普通技术对象可以意识到，结合本申请中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术对象可以对每个特定的应用，使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

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

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术对象在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (14)

1.一种数据处理方法，其特征在于，包括：

获取业务场景中待处理的流程实例；所述流程实例中包括N1个流程任务，且所述N1个流程任务均在第一驱动事件的驱动下执行；所述流程任务中包含所述业务场景对应的业务逻辑；N1为大于1的整数；

在所述第一驱动事件的驱动下，执行所述N1个流程任务；以及，

对所述第一驱动事件对应的驱动过程进行事务化处理，得到所述第一驱动事件对应的事务化处理结果，所述第一驱动事件对应的事务化处理结果用于指示所述N1个流程任务的执行结果；

若所述第一驱动事件对应的事务化处理结果指示所述N1个流程任务的执行结果均为执行成功，则在所述业务场景对应的数据库中进行与所述第一驱动事件相关的数据库事务提交；与所述第一驱动事件相关的数据库事务提交用于指示在所述数据库中保存执行所述N1个流程任务所产生的操作。

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

若所述第一驱动事件对应的事务化处理结果指示所述N1个流程任务中存在执行结果为执行失败的流程任务，则在所述业务场景对应的数据库中进行与所述第一驱动事件相关的数据库事务回滚；与所述第一驱动事件相关的数据库事务回滚用于指示在所述数据库中撤销执行所述N1个流程任务所产生的操作；

其中，执行所述N1个流程任务所产生的操作被保存至所述数据库后，客户端能够从所述数据库中实时查询与所述N1个流程任务相关的流程数据；执行所述N1个流程任务所产生的操作包括以下至少一种：将与所述N1个流程任务相关的流程数据写入所述数据库的增加操作；将与所述N1个流程任务相关的流程数据从所述数据库中删除的删除操作；对与所述N1个流程任务相关的流程数据进行修改的修改操作；以及在所述数据库中针对与N1个流程任务相关的流程数据的查询操作。

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

为所述流程实例设置流程实例锁；所述流程实例锁用于在所述驱动过程中对与所述N1个流程任务相关的流程数据执行锁定操作，被执行锁定操作的与所述N1个流程任务相关的流程数据处于锁定状态；

在与所述N1个流程任务相关的流程数据处于锁定状态下，触发执行所述在所述第一驱动事件的驱动下，执行所述N1个流程任务的步骤。

4.如权利要求3所述的方法，其特征在于，所述为所述流程实例设置流程实例锁，包括：

获取所述业务场景对应的数据库的流程实例表；所述流程实例表用于存储至少一个流程实例的实例标识，所述至少一个流程实例中包括所述待处理的流程实例；

从所述流程实例表中确定出所述待处理的流程实例的实例标识；

基于所述待处理的流程实例的实例标识，为所述待处理的流程实例增加所述流程实例锁。

5.如权利要求3所述的方法，其特征在于，所述为所述流程实例设置流程实例锁，包括：

获取所述业务场景对应的数据库的流程实例表；所述流程实例表用于存储至少一个流程实例的实例标识，所述至少一个流程实例中包括所述待处理的流程实例；

为所述流程实例表增加所述流程实例锁；其中，所述流程实例表中的每个实例标识对应的流程实例均被增加所述流程实例锁。

6.如权利要求3所述的方法，其特征在于，在所述业务场景对应的数据库中进行与所述第一驱动事件相关的数据库事务提交的同时，或者，在所述业务场景对应的数据库中进行与所述第一驱动事件相关的数据库事务回滚的同时，所述方法还包括：

释放所述流程实例锁针对与所述N1个流程任务相关的流程数据的锁定操作；释放所述锁定操作后，与所述N1个流程任务相关的流程数据处于可更新状态。

7.如权利要求1所述的方法，其特征在于，所述流程实例中还包括N2个流程任务，所述N2个流程任务的执行顺序位于所述N1个流程任务之后，且所述N2个流程任务均在第二驱动事件的驱动下执行；N2为大于1的整数；所述方法还包括：

在所述第二驱动事件的驱动下，执行所述N2个流程任务；

对所述第二驱动事件对应的驱动过程进行事务化处理，得到所述第二驱动事件对应的事务化处理结果；所述第二驱动事件对应的事务化处理结果用于指示所述N2个流程任务的执行结果；

若所述第二驱动事件对应的事务化处理结果指示所述N2个流程任务的执行结果均为执行成功，则在所述业务场景对应的数据库中进行与所述第二驱动事件相关的数据库事务提交；与所述第二驱动事件相关的数据库事务提交用于指示在所述数据库中保存执行所述N2个流程任务所产生的操作；

其中，所述流程实例停止驱动的结束条件为所述流程实例中的最后一个流程任务被执行。

8.如权利要求1或3所述的方法，其特征在于，在所述驱动过程中所述N1个流程任务中的每个流程任务均创建有对应的任务节点，所述任务节点承载有相应流程任务所包含业务场景对应的业务逻辑；所述N1个流程任务中存在有流程任务对应的任务节点绑定任务执行器，所述任务执行器承载有相应流程任务所包含的参考业务逻辑，所述参考业务逻辑是由用户自定义的业务逻辑；所述在所述业务场景对应的数据库中进行与所述第一驱动事件相关的数据库事务提交之后，还包括：

执行任务节点中绑定的任务执行器。

9.如权利要求8所述的方法，其特征在于，M个任务节点绑定有任务执行器，M为正整数，且M≤N1；所述执行任务节点中绑定的任务执行器，包括：

对所述M个任务节点中绑定的任务执行器进行异步并行执行。

10.如权利要求9所述的方法，其特征在于，流程任务对应的任务节点在节点创建的开始阶段和结束阶段均绑定有任务执行器；

其中，所述M个任务节点中绑定的任务执行器中，被异步并行执行的任务执行器包括：所述M个任务节点中除属于对象类型的任务节点外的每个任务节点在节点创建的开始阶段和结束阶段绑定的任务执行器，以及，所述M个任务节点中属于对象类型的任务节点在节点创建的开始阶段绑定的任务执行器；

所述M个任务节点中属于对象类型的任务节点在节点创建的结束阶段绑定的任务执行器，在所述第一驱动事件的下一个驱动事件中被执行。

11.一种数据处理装置，其特征在于，包括：

获取装置，用于获取业务场景中待处理的流程实例；所述流程实例中包括N1个流程任务，且所述N1个流程任务均在第一驱动事件的驱动下执行；所述流程任务中包含所述业务场景对应的业务逻辑；N1为大于1的整数；

处理单元，用于在所述第一驱动事件的驱动下，执行所述N1个流程任务；以及，

所述处理单元，还用于对所述第一驱动事件对应的驱动过程进行事务化处理，得到所述第一驱动事件对应的事务化处理结果，所述第一驱动事件对应的事务化处理结果用于指示所述N1个流程任务的执行结果；

所述处理单元，还用于若所述第一驱动事件对应的事务化处理结果指示所述N1个流程任务的执行结果均为执行成功，则在所述业务场景对应的数据库中进行与所述第一驱动事件相关的数据库事务提交；与所述第一驱动事件相关的数据库事务提交用于指示在所述数据库中保存执行所述N1个流程任务所产生的操作。

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

处理器，适于执行计算机程序；

计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序被所述处理器执行时，实现如权利要求1-10任一项所述的数据处理方法。

13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序适于由处理器加载并执行如权利要求1-10任一项所述的数据处理方法。

14.一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机指令，所述计算机指令被处理器执行时实现如权利要求1-10任一项所述的数据处理方法。