CN110991983A - 一种任务处理方法、装置、介质和设备 - Google Patents

Abstract

本发明涉及一种任务处理方法、装置、介质和设备。预先定义可以接收新的处理人ID集合信息的节点，从而可以在需要对基于Flowable流程引擎的多实例任务节点内部任务进行覆盖重建时，无需重新生成流程实例，对流程实例中的多实例任务节点重新发起多实例任务，而是可以直接在当前流程实例中，在预先定义的节点接收新的处理人ID集合信息，确定新的处理人ID集合中对应的任务为已完成任务的处理人ID，对该处理人ID对应的已完成任务进行删除，重建该处理人ID对应的任务，从而实现对任务的覆盖重建。由于无需整体重现发起，可以大大提高系统运行效率，且不会遗失本该保留的任务的流程数据，进一步保证了系统运行效率。

Description

一种任务处理方法、装置、介质和设备

技术领域

本发明涉及通信技术领域，特别涉及一种任务处理方法、装置、介质和设备。

背景技术

流程引擎现已广泛应用于各种需要支持复杂业务流程的软件系统。流程引擎可根据一定的原则和过程来实施任务并加以监控，从而达到提高效率、控制过程、提升客户服务、增强有效管理业务流程等目的。

在基于Flowable流程引擎的业务流程实现过程中，需要生成流程实例，流程实例中的每个节点对应具体的内部任务。一个节点对应的内部任务可能为多实例任务，此时该节点可以称为多实例任务节点。然而基于Flowable流程引擎的多实例任务节点内部任务的覆盖重建，一直是Flowable流程引擎的难点功能。

现有解决方案主要是重新生成流程实例，进而对流程实例中的多实例任务节点重新发起多实例任务，从而实现对该多实例任务节点内部任务的覆盖重建。

上述解决方案虽然流程状态正确，但由于需要重新生成流程实例，并重新发起多实例任务，导致系统运行效率低，且遗失了本该保留的部分任务的流程数据，进一步降低了系统运行效率。

发明内容

本发明实施例提供一种任务处理方法、装置、介质和设备，用于解决无法高效地对基于Flowable流程引擎的多实例任务节点内部任务进行覆盖重建的问题。

一种任务处理方法，应用于基于Flowable流程引擎的业务流程中，所述方法包括：

在预先定义的节点接收第一多实例任务处理人标识ID集合信息new_pers；

确定接收到的所述new_pers中对应的任务为已完成任务的处理人ID；

删除所述处理人ID对应的已完成任务，并针对该处理人ID进行加签，重建该处理人ID对应的任务。

一种任务处理装置，应用于基于Flowable流程引擎的业务流程中，所述装置包括：

接收模块，用于在预先定义的节点接收第一多实例任务处理人标识ID集合信息new_pers；

确定模块，用于确定接收到的所述new_pers中对应的任务为已完成任务的处理人ID；

处理模块，用于删除所述处理人ID对应的已完成任务，并针对该处理人ID进行加签，重建该处理人ID对应的任务。

本发明还提供了一种非易失性计算机存储介质，所述计算机存储介质存储有可执行程序，该可执行程序被处理器执行实现如上所述的方法。

本发明还提供了一种任务处理设备，包括至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上所述方法的步骤。

根据本发明实施例提供的方案，预先定义可以接收新的处理人ID集合信息的节点，从而可以在需要对基于Flowable流程引擎的多实例任务节点内部任务进行覆盖重建时，无需重新生成流程实例，对流程实例中的多实例任务节点重新发起多实例任务，而是可以直接在当前流程实例中，在预先定义的节点接收新的处理人ID集合信息，确定新的处理人ID集合中对应的任务为已完成任务的处理人ID，对该处理人ID对应的已完成任务进行删除，重建该处理人ID对应的任务，从而实现对任务的覆盖重建。由于无需整体重现发起，可以大大提高系统运行效率，且不会遗失本该保留的任务的流程数据，进一步保证了系统运行效率。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

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

图1为本发明实施例一提供的任务处理方法的流程示意图；

图2为本发明实施例二提供的任务处理方法的流程示意图；

图3为本发明实施例四提供的业务需求工单的流程示意图；

图4为本发明实施例四提供的增量重发评估任务前后的示意图；

图5为本发明实施例四提供的思维导图示意图；

图6为本发明实施例五提供的任务处理装置的结构示意图；

图7为本发明实施例六提供的任务处理设备的结构示意图。

具体实施方式

目前Flowable流程引擎自身应用程序编程接口(API)不支持多实例任务创建之后对节点内部的实例任务无论激活与否做增、删、改操作。

本发明提供的方案基于Flowable流程引擎提供的自定义命令模式，该模式提供编写自定义命令的渠道，对Flowable流程引擎功能进行拓展开发。本方案属于可为任何属性的多实例任务进行动态覆盖重建的通用方案。

为了便于后续理解，下面简单介绍一下本发明方案涉及的Flowable流程引擎中的流程实例、执行流和多实例任务的关系：

一个业务流程对应一个业务需求工单；

一个业务需求工单启动后对应一个流程实例；

一个流程实例最外层对应一个父执行流，一个流程实例中的一个多实例任务整体属于一个根执行流，一个多实例任务内部的每个实例任务对应一个子执行流。

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

需要说明的是，在本文中提及的“多个或者若干个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。

此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例一

本发明实施例一提供一种任务处理方法，应用于基于Flowable流程引擎的业务流程中，该方法的步骤流程可以如图1所示，包括：

步骤001、接收第一多实例任务处理人标识(ID)集合信息。

由于每个节点内部任务与处理人之间存在一一对应关系，因此，在本实施例中，可以通过接收到的第一多实例任务处理人ID集合信息(new_pers)，来确定对应的需要处理的任务。

在本步骤中，可以在预先定义的节点接收new_pers，new_pers可以是一个集合(set)类型变量。new_pers中可以理解为包括至少一个多实例任务处理人ID。

步骤002、确定对应已完成任务的处理人ID。

在本发明各实施例中，每个任务的任务执行结果可以为已完成或未完成。在本步骤中，可以确定接收到的所述new_pers中对应的任务为已完成任务的处理人ID。

在一种可能的实现方式中，确定接收到的所述new_pers中对应的任务为已完成任务的处理人ID，可以包括：

查找所述节点对应的活跃任务ID，并确定所述活跃任务ID所对应的多实例任务根执行流；

通过所述多实例任务根执行流获取对应的子执行流集合；

针对所述子执行流集合，确定所述子执行流集合中每个子执行流对应的任务是否为已完成任务：

若所述子执行流集合中一个子执行流对应的任务为已完成任务，且所述new_pers中包括该已完成任务对应的处理人ID，则将该处理人ID确定为接收到的所述new_pers中对应的任务为已完成任务的处理人ID。

在另一种可能的实现方式中，本步骤可以包括：

确定所述new_pers与第二多实例任务处理人ID集合信息(old_pers，old_pers中也可以理解为包括至少一个多实例任务处理人ID)中是否包括相同的处理人ID，所述old_pers是接收到所述new_pers之前，所述多实例任务根执行流对应的多实例任务处理人ID集合信息；

若包括相同的处理人ID，则确定接收到的所述new_pers中对应的任务为已完成任务的处理人ID。

可以理解为，只有new_pers和old_pers包括相同的处理人ID时，才需要进行任务的处理。

因此，在本步骤中，可以判断new_pers和old_pers是否包括相同的处理人ID，如果包括，才继续确定接收到的所述new_pers中对应的任务为已完成任务的处理人ID。

步骤003、任务处理。

在本步骤中，可以针对步骤002确定出的处理人ID，删除所述处理人ID对应的已完成任务，并针对该处理人ID进行加签，重建该处理人ID对应的任务，从而实现任务的覆盖重建。

此外需要说明的是，本实施例除了可以进行任务的覆盖重建之外，还可以进行任务的新增。

在一种可能的实现方式中：

在步骤001之后，在步骤003中，还可以确定old_pers在new_pers中的相对补集。进而可以针对该相对集合中的每个处理人ID进行加签，新建该相对集合中的每个处理人ID对应的任务，从而实现任务的新增。

根据实施例一提供的方案，无需重新生成流程实例，可以有效提高系统运行效率。且无需退回至上一节点，进行操作后再流转到需要进行覆盖重建任务(和新增任务)的多实例任务节点，仅在多实例任务节点内部进行操作，也不会造成已完成任务清单的混乱。

下面通过实施例二，针对实施例一提及的可能的确定接收到的new_pers中对应的任务为已完成任务的处理人ID的方式，对本发明实施例一提供的方案进行说明。

实施例二

本发明实施例二提供一种任务处理方法，应用于基于Flowable流程引擎的业务流程中，该方法的步骤流程可以如图2所示，包括：

步骤101、接收第一多实例任务处理人ID集合信息。

可以理解为，在本步骤中，可以在预先定义的可以接收new_pers的节点，接收new_pers。在一种可能的实现方式中，new_pers可以理解为针对该节点，需要覆盖重建的任务所对应的处理人标识集合。

若在预先定义的节点接收到new_pers，则继续执行步骤102。

步骤102、查找活跃任务ID。

在本步骤中，若在预先定义的节点接收到new_pers，则可以继续查找该节点对应的活跃任务ID。

查找活跃任务ID的一种可能的实现方式是，根据接收到new_pers的节点对应的当前流程实例ID及多实例任务静态定义ID，查找该节点对应的活跃任务ID。

其中，多实例任务静态定义ID可以理解为多实例任务节点所对应的多实例任务静态标识。

活跃任务ID可以理解为每个流转到多实例任务节点的实例任务对应的标识。

步骤103、确定对应的多实例任务根执行流。

通过步骤102查找到活跃任务ID之后，在本步骤中，可以继续确定活跃任务ID所对应的多实例任务根执行流。

步骤104、获取对应的子执行流集合。

在本步骤中，可以通过确定出的多实例任务根执行流获取对应的子执行流集合。

在本步骤中，可以针对获取到的子执行流集合，确定该子执行流集合中每个子执行流对应的任务是否为已完成任务。

若子执行流集合中一个子执行流对应的任务为已完成任务，且所述new_pers中包括该已完成任务对应的处理人ID，则将该处理人ID确定为所述new_pers中对应的任务为已完成任务的处理人ID。

在一种可能的实现方式中，如果一个子执行流对应的任务数为1，则可以认为该子执行流对应的任务是未完成任务。如果一个子执行流对应的任务数为0，则可以认为该子执行流对应的任务是已完成任务。

步骤105、覆盖重建任务。

若获取到的子执行流集合中一个子执行流对应的任务为已完成任务，且所述new_pers中包括该已完成任务对应的处理人ID，则在本步骤中，可以删除该已完成任务，并针对该已完成任务对应的处理人ID进行加签，重建该处理人ID对应的任务。

即可以理解为，如果new_pers中包括的处理人ID对应的任务已完成，则可以删除该已完成任务，并针对该处理人ID重建任务，从而实现该处理人ID对应任务的覆盖重建。

需要说明的是，删除已完成任务可以通过以下方式实现：

步骤101之后，在本步骤105之前，根据接收到new_pers的节点对应的当前流程实例ID获取最上层父执行流；

根据所述父执行流获取任务处理结论变量(assess_result_map)。

所述assess_result_map是在当前流程实例创建时生成的多实例任务处理人ID与任务处理结论对应关系的变量。assess_result_map可以是地图(map)类型变量。

在本发明各实施例中，任务处理结论可以是每个已完成任务对应的具体结论，例如，同意、拒绝、与我无关等等。

那么在本步骤中，删除已完成任务，可以包括：

删除该任务对应的执行流、该执行流级联子执行流及其关联的所有执行流变量；以及，

获取多实例任务根执行流自有变量中的实例任务总数，并将所述实例任务总数减1；以及，

获取多实例任务根执行流自有变量中的已完成实例任务总数，并将所述已完成实例任务总数减1；以及，

将所述assess_result_map中该任务对应的多实例任务处理人ID与任务处理结论对应关系移除。

进一步的，针对所述子执行流集合，确定所述子执行流集合中每个子执行流对应的任务是否为已完成任务之后，还可以将所述assess_result_map重新存回当前流程实例变量。

可以理解为，在本实施例中，由于需要对任务进行删除重建，因此对应的任务的处理结论也会发生变化，因此，在本实施例中引入了assess_result_map，来实现多实例任务处理人ID与任务处理结论对应关系的更新。

在本实施例中，如果new_pers中包括的处理人ID对应的任务未完成，则无需针对该任务进行处理，可以保留该任务，使得该处理人ID对应的处理人可以继续处理该任务，如此亦可以认为实现了对该任务的覆盖重建。

在本步骤中，若获取到的子执行流集合中一个子执行流对应的任务为未完成任务，且所述new_pers中包括该未完成任务对应的处理人ID，则可以不处理所述处理人ID对应的未完成任务。并可以从所述new_pers中删除该未完成任务对应的处理人ID，使得new_pers中不包括对应的任务为未完成任务的处理人ID，便于后续对new_pers的使用。例如，直接或间接用于确定old_pers在new_pers中的相对补集。

需要说明的是，在一种可能的实现方式中，在步骤101之后，步骤102之前，还可以进一步增加判断步骤102’：

步骤102’、确定接收到的new_pers与old_pers中是否包括相同的处理人ID。

可以理解为，所述old_pers是步骤103中确定出的多实例任务根执行流对应的子执行流集合中，每个子执行流对应的任务所对应的处理人ID集合。

在本步骤中，可以判断new_pers和old_pers是否包括相同的处理人ID，如果包括，则可以继续执行步骤102，否则，可以结束本流程。

需要进一步说明的是，本实施例提供的方案中，除了可以对多实例任务节点内部任务进行覆盖重建之外，还可以对多实例任务节点内部任务进行新增。此时，new_pers还可以理解为是需要覆盖重建和新增的任务所对应的处理人标识集合。

即在步骤101之后，还可以包括步骤101’，如果不包括步骤102’，本实施例对步骤101’与步骤102的执行顺序不做限定，如果包括步骤102’，本实施例对步骤101’与步骤102’的执行顺序也不做限定。：

步骤101’、新增任务。

若在预先定义的节点接收到new_pers，在本步骤中，还可以确定old_pers在new_pers中的相对补集，针对该相对集合中的每个处理人ID进行加签，新建该相对集合中的每个处理人ID对应的任务，从而实现节点内部任务的新增。

实施例一和二提供的方案可支持所有需要对多实例任务内部已完成或未完成的任务增量替换与新建操作的场景，具有极大的通用性、灵活性、广泛性、健壮性，可以支持各种不同多实例任务增量替换和添加的应用场景，是对原有流程引擎功能的一种极大拓展。

下面通过实施例三进一步对本发明实施例二提供的方案进行具体说明。在本实施例中，以基于Flowable流程引擎的多实例任务节点内部任务需要覆盖重建和新增，且先对内部任务进行覆盖重建，然后进行新增为例进行说明。当然，如果多实例任务节点内部任务需要覆盖重建和新增，不限于先对内部任务进行覆盖重建，然后进行新增，例如，也可以先对内部任务进行新增，然后进行覆盖重建。

实施例三

本发明实施例三提供一种任务处理方法，应用于基于Flowable流程引擎的业务流程中，该方法的步骤流程可以包括如下步骤：

1、流程实例初始创建时，设置保存多实例任务处理人ID与任务处理结论对应关系的Map类型变量(assess_result_map)。并可以在多实例任务开始前的执行流中设置监听器，针对每种需要计数的任务处理结论，分别设置计数(count)整数型变量，以便于后续使用，例如用于判断是否满足节点内部任务结束条件。

count变量可以针对需要计数的任务处理结论(例如，同意)的数量，进行计数。

2、当需要进行节点内部任务覆盖重建和新增时，在该节点接收新的多实例任务处理人ID的Set集合类型变量(new_pers),并确定该节点对应的多实例任务静态定义ID，当前流程实例ID。

3、根据当前流程实例ID及多实例任务静态定义ID，查找活跃任务ID，并确定活跃任务ID所对应的多实例任务根执行流。

在确定多实例任务根执行流时，可以首先获取当前流程实例对应的第一层所有子执行流集合，若其中某一子执行流中包含有活跃任务ID，同时该子执行流对应的执行流对应多实例任务，则认为该子执行流对应的执行流为所找的多实例任务根执行流。

若根据第一层所有子执行流集合未找到多实例任务根执行流，则递归查找每个第一层子执行流所对应的下一层子执行流，以此类推，直至找到多实例任务根执行流。

在一种可能的实现方式中，在找到多实例任务根执行流之后，可以仍然继续遍历完流程实例所对应的所有子执行流，以便在也有其他符合条件的子执行流存在的时候抛出异常，提示错误可能。

4、根据当前流程实例ID获取最上层父执行流，并从中获取assess_result_map，及各count变量，以便于后续使用。

当然本步骤不限于在3之后执行。

5、以数组形式转换备份原有的多实例任务处理人ID的Set集合类型变量(old_pers)。

在本实施例中，可以根据assess_result_map来确定多实例任务处理人ID集合。那么，当操作更新assess_result_map时，也会导致多实例任务处理人ID集合发生变化，因此，在本实施例中，可以在未操作更新assess_result_map时，对对应的多实例任务处理人ID集合进行备份，得到old_pers。

6、通过多实例任务根执行流获取多实例任务内部所有未完成和已完成任务对应的子执行流集合，并开始遍历。

7、若当前遍历的子执行流对应的任务数为1，则该子执行流对应的任务为未完成的任务,不做额外处理，若new_pers中含有此任务的处理人ID，则可以暂时去除，以便于后续使用。

8、若当前遍历的子执行流对应的任务数为0，则该子执行流对应的任务为已完成的任务。若new_pers中含有此任务的处理人ID，则可以对已完成的任务做删除处理，包括：

删除该任务对应的执行流本身、其级联子执行流及其关联的所有执行流变量；

获取多实例任务根执行流自有变量中的实例任务总数，并减1；

获取多实例任务根执行流自有变量中的已完成实例任务总数，并减1；

根据assess_result_map，通过处理人ID获取对应的任务处理结论，若该任务处理结论需要计数，对其对应的count整数减1，并可以将assess_result_map中保存的对应关系记录移除；

对已完成的任务做删除处理之后，可以重发加签，从而实现任务的覆盖重建。

9、所有子执行流遍历处理完之后，将assess_result_map，各计数count整数变量的最终结果重新存入回流程实例变量。

10、确定old_pers在new_pers中的相对补集。

11、根据10确定出的集合，针对该集合中的每个处理人ID做加签处理，实现任务的新建。

下面再额外说明一下步骤8以及步骤11中涉及的加签操作的具体实现：

(1)接收加签操作对应的处理人ID以及加签操作所需的其他变量。

(2)通过上述步骤3确定出的多实例任务根执行流，创建其子执行流，设置其子执行流对应任务为当前任务。

从而实现加签功能对应的新的子执行流与新的实例任务。

(3)确定多实例任务的循环特征。

在本步骤中，可以获取多实例任务根执行流，获取其对应的流程定义实体，从而获取其对应的多实例任务节点的静态定义实体，再而获取到其对应的多实例任务的循环特征。

(4)获取多实例任务自有变量中的实例任务总数，并加1。

由于是加签，其总数必然多1个。

(5)设置步骤(1)中接收到的处理人ID及其他变量到新的子执行流中。

若从步骤3的循环特征中判断出多实例任务为并行任务，则设置加签功能对应的新的任务为激活状态，并将多实例任务自有变量中的激活的实例任务总数加1。

最后通过流程引擎的代理，进行流程引擎设定，将此类对多实例任务本身进行修改，且修改后继续待完成的操作类型，定义为本命令结束后期望仍继续操作多实例任务(区别于执行命令后多实例任务完成结束等其他类型的命令)的操作类型，完成加签操作。

对多实例任务内部部分实例任务及其执行流进行增量覆盖操作一直是Flowable流程引擎的一大难题，需要综合考虑流程引擎各个方面的处理，稍有不当便会产生诸多垃圾冗余数据残留，或各种变量未处理妥当的情况。

根据本发明实施例一～实施例三提供的方案，解决了上述问题，可以直接更改多实例任务本身，直接对节点内部任务进行增量增改，且任何时候都可以根据需求对多实例任务进行处理，尤其适用于需要不完全对多实例任务内部每个实例任务进行替换重发或新增的增量处理的应用场景。相较于现有的整体重现发起的实现方式，提升了系统运行效率，避免了多实例任务流程变量丢失问题。优雅地仅对需要更改的部分进行处理，可很好地与多实例任务节点里的其他任务一起，进行串行并行，结束条件，多实例变量等各方面的共同管理。

下面结合具体的使用场景，对本发明实施例一～实施例三提供的方案进行说明。

实施例四在本实施例中，以基于Flowable流程引擎的业务流程中，需要在评估中或评估之后重新发起评估，对上次评估未覆盖的处理人做新增，已覆盖的处理人重新发起评估任务的场景为例进行说明，业务流程对应的业务需求工单的流程图可以如图3所示，其中：

在业务流程开始后，在新建节点发起评估后，进入评估中节点，如果评估不通过，则进入对应的评估不通过节点，否则，进入对应的评估通过节点。

下面通过一个具体的例子对图3进行说明。

创建新的业务需求工单后，流程跳转至名为新建的任务节点，新建节点处理人发任务给A、B、C、D四个人，A、B、C、D四个人对应的任务分别用任务1、任务2、任务3和任务4表示，此时流程由新建节点跳转至名为评估中的多实例任务节点，该节点对应的评估任务可以记为多实例任务1。

假设B、C将任务完成，并将任务处理结论分别置为与我无关、拒绝。此时与我无关结论对应的count变量加一，拒绝结论对应的count变量加一，assess_result_map可以记录处理人与任务处理结论的对应关系。

假设需要增量重发评估任务，选择给C、D、E三人发送评估任务，期望重发后评估任务对应A、B、C、D、E五人。

则给C、D、E三人发送评估任务后：

A、B对应的任务不需处理，其中，B仍是已完成任务的状态，且对应的与我无关的任务处理结论保留。

由于C对应的任务已完成，需要对C对应的任务进行覆盖重建，删除C对应的已完成的任务，并重建C对应的任务。即，需进行删掉对应执行流、多实例任务自有变量处理、临时结果对应关系删除(对assess_result_map中C与任务处理结论的对应关系移除)、count变量减1(由于C的任务处理结论为拒绝，对拒绝结论对应的count变量减1)、以及C为处理人的加签操作。

由于D对应的任务未完成，则D对应的任务无需处理，即实现对D对应的任务的覆盖重建。

由于E为新增的处理人，可以对新增的E直接进行加签处理，新建E对应的任务。

增量重发评估任务前后，评估任务对应的处理人，以及各处理人对应的任务、任务执行结果和任务处理结论可以如图4所示。

实施例三提供的具体场景对应的思维导图可以如图5所示，其中：

增量重发评估任务不涉及的原有的A、B处理人，不论其是否已完成任务，即不论其未进行评估还是已经进行评估，均不处理(不动)。

增量重发评估任务涉及的原有的C、D处理人，需要进行任务的覆盖。针对未完成任务的D，可以不处理。针对已完成任务的C，则需要删掉对应的执行流，进行变量处理(包括对评估任务对应的自有变量中的实例任务总数(nrOfInstances)减1，已完成实例任务总数(nrOfCompleteInstances)减1，已激活实例任务总数(nrOfActiveInstances)加1)，临时结果对应关系删除(对assess_result_map中C与任务处理结论的对应关系移除)、count变量减1(由于C的任务处理结论为拒绝，对拒绝结论对应的count变量减1)，以及进行加签操作(此时，需要对评估任务对应的自有变量中的实例任务总数加1)。

增量重发评估任务涉及的原来没有的E处理人，则直接进行加签操作，此时评估任务对应的自有变量中的实例任务总数要加1。

与实施例一～四提供的方法对应的，提供以下的装置。

实施例五

本发明实施例五提供一种任务处理装置，应用于基于Flowable流程引擎的业务流程中，该装置的结构可以如图6所示，包括：

接收模块11用于在预先定义的节点接收第一多实例任务处理人标识ID集合信息new_pers；确定模块12用于确定接收到的所述new_pers中对应的任务为已完成任务的处理人ID；处理模块13用于删除所述处理人ID对应的已完成任务，并针对该处理人ID进行加签，重建该处理人ID对应的任务。

所述确定模块12具体用于查找所述节点对应的活跃任务ID，并确定所述活跃任务ID所对应的多实例任务根执行流；通过所述多实例任务根执行流获取对应的子执行流集合；针对所述子执行流集合，确定所述子执行流集合中每个子执行流对应的任务是否为已完成任务：若所述子执行流集合中一个子执行流对应的任务为已完成任务，且所述new_pers中包括该已完成任务对应的处理人ID，则将该处理人ID确定为接收到的所述new_pers中对应的任务为已完成任务的处理人ID。

所述确定模块12查找所述节点对应的活跃任务ID，包括：根据所述节点对应的当前流程实例ID及多实例任务静态定义ID，查找所述节点对应的活跃任务ID。

所述确定模块12还用于针对所述子执行流集合，确定所述子执行流集合中每个子执行流对应的任务是否为已完成任务之前，根据所述节点对应的当前流程实例ID获取最上层父执行流；根据所述父执行流获取任务处理结论变量assess_result_map；

所述assess_result_map是在当前流程实例创建时生成的多实例任务处理人ID与任务处理结论对应关系的变量；

所述处理模块13删除所述处理人ID对应的已完成任务，包括：删除该任务对应的执行流、该执行流级联子执行流及其关联的所有执行流变量；以及，获取多实例任务根执行流自有变量中的实例任务总数，并将所述实例任务总数减1；以及，获取多实例任务根执行流自有变量中的已完成实例任务总数，并将所述已完成实例任务总数减1；以及，将所述assess_result_map中该任务对应的多实例任务处理人ID与任务处理结论对应关系移除。

所述确定模块12还用于针对所述子执行流集合，确定所述子执行流集合中每个子执行流对应的任务是否为已完成任务之后，将所述assess_result_map重新存回当前流程实例变量。

所述确定模块12具体用于确定所述new_pers与第二多实例任务处理人ID集合信息old_pers中是否包括相同的处理人ID，所述old_pers是接收到所述new_pers之前，所述多实例任务根执行流对应的多实例任务处理人ID集合信息；若包括相同的处理人ID，则确定接收到的所述new_pers中对应的任务为已完成任务的处理人ID。

所述处理模块13还用于确定第二多实例任务处理人ID集合信息old_pers在所述new_pers中的相对补集，所述old_pers是接收到所述new_pers之前，所述多实例任务根执行流对应的多实例任务处理人ID集合信息；针对该相对集合中的每个处理人ID进行加签，新建该相对集合中的每个处理人ID对应的任务。

基于同一发明构思，本发明实施例提供以下的设备和介质。

实施例六

本发明实施例六提供一种任务处理设备，该设备的结构可以如图7所示，包括至少一个处理器21；以及与所述至少一个处理器通信连接的存储器22；其中，所述存储器22存储有可被所述至少一个处理器21执行的指令，所述指令被所述至少一个处理器21执行，以使所述至少一个处理器21能够执行本发明实施例一所述方法的步骤。

可选的，所述处理器21具体可以包括中央处理器(CPU)、特定应用集成电路(ASIC，application specific integrated circuit)，可以是一个或多个用于控制程序执行的集成电路，可以是使用现场可编程门阵列(FPGA，field programmable gate array)开发的硬件电路，可以是基带处理器。

可选的，所述处理器21可以包括至少一个处理核心。

可选的，所述存储器22可以包括只读存储器(ROM，read only memory)、随机存取存储器(RAM，random access memory)和磁盘存储器。存储器22用于存储至少一个处理器21运行时所需的数据。存储器22的数量可以为一个或多个。

本发明实施例七提供一种非易失性计算机存储介质，所述计算机存储介质存储有可执行程序，当可执行程序被处理器执行时，实现本发明实施例一提供的方法。

在具体的实施过程中，计算机存储介质可以包括：通用串行总线闪存盘(USB，Universal Serial Bus flash drive)、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的存储介质。

在本发明实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述单元或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性或其它的形式。

在本发明实施例中的各功能单元可以集成在一个处理单元中，或者各个单元也可以均是独立的物理模块。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备，例如可以是个人计算机，服务器，或者网络设备等，或处理器(processor)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：通用串行总线闪存盘(universal serial bus flash drive)、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种任务处理方法，其特征在于，应用于基于Flowable流程引擎的业务流程中，所述方法包括：

在预先定义的节点接收第一多实例任务处理人标识ID集合信息new_pers；

确定接收到的所述new_pers中对应的任务为已完成任务的处理人ID；

删除所述处理人ID对应的已完成任务，并针对该处理人ID进行加签，重建该处理人ID对应的任务。

2.如权利要求1所述的方法，其特征在于，确定接收到的所述new_pers中对应的任务为已完成任务的处理人ID，包括：

查找所述节点对应的活跃任务ID，并确定所述活跃任务ID所对应的多实例任务根执行流；

通过所述多实例任务根执行流获取对应的子执行流集合；

针对所述子执行流集合，确定所述子执行流集合中每个子执行流对应的任务是否为已完成任务：

若所述子执行流集合中一个子执行流对应的任务为已完成任务，且所述new_pers中包括该已完成任务对应的处理人ID，则将该处理人ID确定为接收到的所述new_pers中对应的任务为已完成任务的处理人ID。

3.如权利要求2所述的方法，其特征在于，查找所述节点对应的活跃任务ID，包括：

根据所述节点对应的当前流程实例ID及多实例任务静态定义ID，查找所述节点对应的活跃任务ID。

4.如权利要求2所述的方法，其特征在于，在预先定义的节点接收到第一多实例任务处理人标识ID集合信息new_pers之后，针对所述子执行流集合，确定所述子执行流集合中每个子执行流对应的任务是否为已完成任务之前，所述方法还包括：

根据所述节点对应的当前流程实例ID获取最上层父执行流；

根据所述父执行流获取任务处理结论变量assess_result_map；

所述assess_result_map是在当前流程实例创建时生成的多实例任务处理人ID与任务处理结论对应关系的变量；

删除所述处理人ID对应的已完成任务，包括：

删除该任务对应的执行流、该执行流级联子执行流及其关联的所有执行流变量；以及，

获取多实例任务根执行流自有变量中的实例任务总数，并将所述实例任务总数减1；以及，

获取多实例任务根执行流自有变量中的已完成实例任务总数，并将所述已完成实例任务总数减1；以及，

将所述assess_result_map中该任务对应的多实例任务处理人ID与任务处理结论对应关系移除。

5.如权利要求4所述的方法，其特征在于，针对所述子执行流集合，确定所述子执行流集合中每个子执行流对应的任务是否为已完成任务之后，所述方法还包括：

将所述assess_result_map重新存回当前流程实例变量。

6.如权利要求1所述的方法，其特征在于，确定接收到的所述new_pers中对应的任务为已完成任务的处理人ID，包括：

确定所述new_pers与第二多实例任务处理人ID集合信息old_pers中是否包括相同的处理人ID，所述old_pers是接收到所述new_pers之前，所述多实例任务根执行流对应的多实例任务处理人ID集合信息；

若包括相同的处理人ID，则确定接收到的所述new_pers中对应的任务为已完成任务的处理人ID。

7.如权利要求1～6任一所述的方法，其特征在于，若在预先定义的节点接收到第一多实例任务处理人标识ID集合信息new_pers，所述方法还包括：

确定第二多实例任务处理人ID集合信息old_pers在所述new_pers中的相对补集，所述old_pers是接收到所述new_pers之前，所述多实例任务根执行流对应的多实例任务处理人ID集合信息；

针对该相对集合中的每个处理人ID进行加签，新建该相对集合中的每个处理人ID对应的任务。

8.一种任务处理装置，其特征在于，应用于基于Flowable流程引擎的业务流程中，所述装置包括：

接收模块，用于在预先定义的节点接收第一多实例任务处理人标识ID集合信息new_pers；

确定模块，用于确定接收到的所述new_pers中对应的任务为已完成任务的处理人ID；

处理模块，用于删除所述处理人ID对应的已完成任务，并针对该处理人ID进行加签，重建该处理人ID对应的任务。

9.一种非易失性计算机存储介质，其特征在于，所述计算机存储介质存储有可执行程序，该可执行程序被处理器执行实现如权利要求1～7任一所述的方法。

10.一种任务处理设备，其特征在于，所述设备包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1～7任一所述方法的步骤。

Images