处理审批业务流程的方法、计算设备和计算机存储介质

技术领域

本发明概括而言涉及计算机软件领域，更具体地，涉及一种处理审批业务流程的方法、计算设备和计算机可读存储介质。

背景技术

针对审批流系统主要包含两点需求，一是流程控制，二是表单展示。目前市面上针对这类系统主要有两种解决方案：一是完全定制开发，比如根据业务逻辑编码实现流程控制或使用诸如Workflow、K2BlackPearl等流程引擎进行二次开发后实现流程控制，这种解决方案在每次需求变更时都要重新进行开发、测试及发版，需求上线的周期漫长；二是需求作出让步，将原本线下复杂的审批流程转变为线性的依次审批，但这样容易使得审批流程在业务场景下不合理。

而针对表单往往要么是定制表单，将表单内容存储为横表，要么是针对单个表单配置页面元素，使表单与表单之间的逻辑关系很难在系统级别得到关联。例如，假设有两个表单，A表单的标识字段为“a_code”，编号字段为“BD202010120010”；B表单的标识字段为“b_code”，编号字段为“BD202010120011”。从实际的表单产生过程来看，容易理解这两个表单编号针对两个连续的申请，有很强的关联性，但是从系统的角度来说，由于二者的标识字段完全不同，且毫无关联，因此需要额外的处理逻辑来连续处理这两个表单，这增加了表单处理的复杂度。

发明内容

针对上述问题中的至少一个，本发明提供了一种处理审批业务流程的方案，其通过设置全配置化的审批流程模板，使得能够针对各种审批模式容易地配置、实例化和处理相应的业务流程实例。

根据本发明的一个方面，提供了一种处理审批业务流程的方法。该方法包括由流程引擎：基于一个审批业务需求对流程模板实例化以产生一个审批业务实例，所述审批业务实例包括开始节点、结束节点和所述开始节点与所述结束节点之间的至少一个中间节点，每个中间节点包括至少一个任务事件和至少一个连线元素，每个连线元素用于指示从所述中间节点到所述中间节点的下一节点的约束条件；基于所述审批业务实例的一个中间节点的上一节点的至少一个连线元素确定所述审批业务实例是否可以进入所述中间节点；如果确定所述审批业务实例可以进入所述中间节点，使所述审批业务实例进入所述中间节点，处理所述中间节点所包括的至少一个任务事件并且基于所述至少一个任务事件的处理结果产生所述中间节点的节点结论；基于所述中间节点的节点结论确定所述审批业务实例是否能够向所述中间节点的下一节点转移；以及如果确定所述审批业务实例能够向所述中间节点的下一节点转移，为所述中间节点的连线元素记录激活日志，所述激活日志至少包括所述中间节点作为源节点，所述中间节点的下一节点作为目标节点。

根据本发明的另一个方面，提供了一种计算设备。该计算设备包括：至少一个处理器；以及至少一个存储器，该至少一个存储器被耦合到该至少一个处理器并且存储用于由该至少一个处理器执行的指令，该指令当由该至少一个处理器执行时，使得该计算设备执行根据上述方法的步骤。

根据本发明的再一个方面，提供了一种计算机可读存储介质，其上存储有计算机程序代码，该计算机程序代码在被运行时执行如上所述的方法。

在一种实施例中，基于一个审批业务需求对流程模板实例化以产生一个审批业务实例包括：基于所述审批业务需求所指示的审批业务的类型从多个流程模板中选择所述流程模板，其中所述多个流程模板分别用于多种审批业务类型。

在一种实施例中，确定所述审批业务实例是否可以进入所述中间节点包括：确定所述中间节点的类型是单一节点还是合并节点，其中指向所述单一节点的任一连线元素被激活，则所述单一节点被激活，指向所述合并节点的所有连线元素被激活，所述合并节点才被激活；如果确定所述中间节点的类型是合并节点，确定指向所述合并节点的所有连线元素是否都被激活；以及如果确定指向所述合并节点的所有连线元素都被激活或者确定指向所述单一节点的任一连线元素被激活，确定所述审批业务实例可以进入所述中间节点。

在一种实施例中，确定指向所述合并节点的所有连线元素是否都被激活还包括：对于指向所述合并节点的所有连线元素中的每个连线元素，确定所述连线元素的激活日志；确定所述连线元素的激活日志的源节点是否是所述合并节点；以及如果确定所述连线元素的激活日志的源节点是所述合并节点，将所述连线元素设置为失效，并且确定所述连线元素未被激活。

在一种实施例中，确定所述审批业务实例是否可以进入所述中间节点包括：确定所述中间节点的准入条件的变量值，所述准入条件的变量值由流程引擎基于指向所述中间节点的连线元素的逻辑值计算得到；确定所述中间节点的准入条件的变量值是否符合所述中间节点的准入条件；以及如果确定所述中间节点的准入条件的变量值符合所述中间节点的准入条件，确定所述审批业务实例可以进入所述中间节点。

在一种实施例中，产生所述中间节点的节点结论包括：确定所述中间节点所包括的每个任务事件的标识；将所述任务事件的标识传送至任务引擎；从所述任务引擎接收所述任务事件的处理结果；以及基于所述中间节点所包括的至少一个任务事件的处理结果产生所述中间节点的节点结论。

在一种实施例中，所述中间节点的任务事件包括所述任务事件所对应的任务的标识和角色参数，所述角色参数指示执行所述任务事件的中间节点在所述审批业务实例中的角色，其中如果所述流程模板是针对分发审批模式的流程模板，则所述角色参数指示主节点或者从节点，其中所述从节点由所述主节点指定。

附图说明

通过参考下列附图所给出的本发明的具体实施方式的描述，将更好地理解本发明，并且本发明的其他目的、细节、特点和优点将变得更加显而易见。

图1示出了用于实现根据本发明的实施例的处理审批业务流程的方法的系统的示意图。

图2示出了根据本发明实施例的流程引擎中的一个流程模板的概念元素的示意图。

图3示出了根据本发明实施例的一种节点结构图。

图4示出了根据本发明的实施例的处理审批业务流程的方法的流程图。

图5示出了根据本发明的用于确定审批业务实例是否可以进入一个中间节点的步骤的一种实施例的流程图。

图6示出了根据本发明的用于确定审批业务实例是否可以进入一个中间节点的步骤的另一种实施例的流程图。

图7示出了根据本发明的产生中间节点的节点结论的步骤的一种实施例的流程图。

图8示出了适合实现本发明的实施例的计算设备的结构方框图。

具体实施方式

下面将参照附图更详细地描述本发明的优选实施方式。虽然附图中显示了本发明的优选实施方式，然而应该理解，可以以各种形式实现本发明而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本发明更加透彻和完整，并且能够将本发明的范围完整的传达给本领域的技术人员。

在下文的描述中，出于说明各种发明的实施例的目的阐述了某些具体细节以提供对各种发明实施例的透彻理解。但是，相关领域技术人员将认识到可在无这些具体细节中的一个或多个细节的情况来实践实施例。在其它情形下，与本申请相关联的熟知的装置、结构和技术可能并未详细地示出或描述从而避免不必要地混淆实施例的描述。

除非语境有其它需要，在整个说明书和权利要求中，词语“包括”和其变型，诸如“包含”和“具有”应被理解为开放的、包含的含义，即应解释为“包括，但不限于”。

在整个说明书中对“一个实施例”或“一些实施例”的提及表示结合实施例所描述的特定特点、结构或特征包括于至少一个实施例中。因此，在整个说明书的各个位置“在一个实施例中”或“在一些实施例”中的出现不一定全都指相同实施例。另外，特定特点、结构或特征可在一个或多个实施例中以任何方式组合。

此外，说明书和权利要求中所用的第一、第二等术语，仅仅出于描述清楚起见来区分各个对象，而并不限定其所描述的对象的大小或其他顺序等。

图1示出了用于实现根据本发明的实施例的处理审批业务流程的方法的系统1的示意图。如图1中所示，系统1包括业务终端10、流程引擎20和任务引擎30。业务终端10、流程引擎20和任务引擎30可以通过各种有线或无线网络进行数据交互。这里，业务终端10、流程引擎20和任务引擎30可以是各种能够执行计算功能的移动或固定终端，它们可以具有如下面结合图所述的计算设备的结构或类似的结构。业务终端10将审批业务需求发送给流程引擎20，流程引擎20基于该审批业务需求对相应的审批流程模板进行实例化以处理该审批业务需求，处理结果被发送回业务终端10或另一业务终端10进行展示。

流程引擎20可以实现为硬件的计算设备，或者可以实现为逻辑软件。在后者的情况下，流程引擎20可以包括一个或多个计算设备210，其中每个计算设备210可以包括至少一个处理器212和与该至少一个处理器212耦合的至少一个存储器214，该存储器214中存储有可由该至少一个处理器212执行的指令216，该指令216在被该至少一个处理器212执行时执行如下所述的方法100的至少一部分。例如，每个计算设备210的存储器214中可以存储有如下所述的流程模板220，同一计算设备210的多个不同处理器212和/或多个不同计算设备210的处理器212可以实例化该流程模板220并运行相应的流程实例。

审批业务从逻辑上可以分为顺序审批、并行审批、循环审批、分发审批这四种模式，这四种模式可以单独或混合使用。

顺序审批模式是指审批流程中的各个节点依次进行审批，当前节点的执行依赖于前一节点的结果，这是一种基本的审批方式；

并行审批模式是指审批流程中的各个节点同时进行审批，并且节点的不同结果对流程流转会有不同影响，例如两个节点并行执行各自的审批，二者都通过时流程才能进入下一节点，有任何一个节点驳回，则流程直接被驳回；

循环审批模式是指审批流程中的各个节点依次进行审批并独立作出决断，全部节点循环完毕后，如果决断达成共识则结束流程；如果没有达成共识，则重新开始循环；

分发审批模式是指审批流程中有一个主节点作为流程的主持人，主持人可以选择一个从节点作为执行下一步审批的节点，并且还决定流程何时完结。

因此，流程引擎20应当设计为能够方便地支持这些不同的审批模式。

图2示出了根据本发明实施例的流程引擎20中的一个流程模板220的概念元素的示意图。一个流程引擎20中可以预先设置多个不同的流程模板220，每个流程模板220对应于不同的审批业务类型。

为了实现上述不同的审批模式，流程引擎20的设计引入以下概念：流程模板、流程实例、节点、任务事件、连线元素、任务事件的标识、角色参数、操作结果、变量、条件等。其中第一层级的概念是流程模板和流程实例，流程模板是指业务流程流转的规则集合，流程实例是指在业务需求发起后基于该业务需求对相应的流程模板进行实例化所得到的用例，流程实例基于流程模板设置的规则集合进行流转。

如图2所示，一个流程模板220可以包括多个节点221，节点221是流程引擎20最基础的处理单元，节点间的流转逻辑就是流程引擎20的设计核心。一个流程模板220或者基于该流程模板220的流程实例的多个节点221可以分为作为流程实例入口的开始节点，作为流程实例出口的结束节点，以及位于开始节点和结束节点之间的至少一个中间节点。以下主要以中间节点为例对节点221进行描述，因此有时也将节点221称为中间节点221。开始节点用于标识发起实例时的入口，结束节点用于标识结束实例的出口。开始节点与中间节点的区别主要对于开始节点没有上一节点，从而也就没有从上一节点连接至开始节点的连线元素或者准入条件，结束节点与中间节点的区别主要在于结束节点没有下一节点，从而也就没有通往下一节点的连线元素。从硬件角度来说，一个节点221可以是一个计算设备210或者一个计算设备210的多个处理器212中的一个处理器，从软件角度来说，一个节点221可以是流程引擎20中的一段程序代码。

每个节点221可以包括至少一个任务事件222。当节点221激活后会依次处理其中的事件222。一个任务事件222至少包括指示该任务事件222所对应的任务的标识2222。一个任务事件222的标识2222用于指示该任务事件222所要执行的任务，在该任务事件222被执行时，流程引擎20可以将该标识2222传送给任务引擎30，以由任务引擎30执行该标识2222所指示的任务，并且可以从任务引擎30接收该任务事件222的处理结果。此外，一个任务事件222还可以包括角色参数2224，其用于指示执行该任务事件222的节点221在基于流程模板220所产生的审批业务实例中的角色。角色可以是由外部系统分配的。此外，一个任务事件222还可以包括操作结果2226，用于指示处理任务事件222得到的处理结果。一个节点221中的所有任务事件222的处理结果可以用于确定该节点221的节点结论。这里，由于标识2222和角色参数2224都指向外部系统的逻辑，所以可以将这二者设置为变量，变量的概念在下面进行说明。注意，变量的值是业务流程实例发起及运行时由外部系统传入的，所以当标识2222和角色参数2224被设置为变量时，实际可以实现流程实例动态扩展的功能。

一个节点221还包括至少一个连线元素223，其中连线元素223用于指示当前节点221所指向的下一节点2231（下一中间节点或结束节点）。在当前节点221包含的所有任务事件222都处理完成后，当前节点221会尝试根据连线元素223进行流程流转。连线元素223可以关联特定的节点结论，即，业务流程实例在当前节点221得到该节点结论时才尝试激活该连线元素223。连线元素223也可以不关联节点结论，即，业务流程实例在当前节点221后就尝试激活该连线元素223，而不考虑当前节点221的节点结论是什么。另外，连线元素223还可以包括条件2232。当尝试激活连线元素223时可以根据条件2232判断该连线元素223是否最终起效。除了连线元素223会根据条件2232决定是否最终被激活，尝试激活一个节点221时也可以有相应的设计，以使得流程引擎20更加灵活，适合于各种流程模式。

为了实现条件这个功能，流程引擎20引入了变量这个概念，上面针对任务事件222的说明中提到的变量也是这个概念。变量定义为：外部系统（如任务引擎30或其他外部系统）为了与流程引擎20交互进行的约定。当业务流程实例发起及运行时，外部系统可以向流程引擎20传递变量的值，以达到动态影响该业务流程实例流转的目的。例如，在分发审批模式下，可以只设置两个中间节点221-1和221-2，第一中间节点221-1的角色参数2224设置为主节点，即主持人节点，第二中间节点221-2的角色参数2224设置为从节点，即嘉宾节点，这两个节点分别只有一个任务事件2222，主持人节点的任务事件222的角色参数2224设置为“主持人”变量，嘉宾节点的任务事件222的角色参数2224设置为“嘉宾”变量。当一个审批业务实例发起时，如果“主持人”变量设置成第一中间节点221-1，则第一中间节点221-1可以在自己的处理界面选择下一步的角色参数2224为第二中间节点221-2，并在第一中间节点221-1流转前将角色参数2224传入“嘉宾”变量，这样进入第二中间节点221-2角色参数2224就会变成第一中间节点221-1选择的第二中间节点221-2，第二中间节点221-2处理后节点流转回第一中间节点221-1，第一中间节点221-1再次选择下一步的嘉宾节点来进行处理，直到第一中间节点221-1决定流程结束。

流程模板220中的条件2232是指变量计算及结果的预定义。例如，流程模板220中可以定义三个变量，分别叫做年龄、年收入、房产价值。条件1设置为年龄小于30；条件2设置为年龄大于25且（年收入+房产价值X 0.1）小于等于300000；条件3设置为年龄大于25且（年收入+房产价值X 0.1）大于300000；条件4设置为年龄大于等于30。当业务流程实例的变量里年龄是28岁，年收入是200000，房产价值是0时，条件1、2为真。

为了增加系统的灵活性，变量根据应用范围不同分为流程变量（如图2中所示的流程变量225）、节点变量和任务事件变量。例如，一个任务事件的“主持人”变量和另一个任务事件的“主持人”变量会互不影响，如果这两个任务事件都属于同一中间节点221，则这两个任务事件都可以访问该中间节点221的变量，但是访问不了另一中间节点的变量。

此外，节点221还可以包括准入条件224。准入条件224是一个独立的计算量，用于激活当前节点221的连线元素，这可以视为一个特殊的变量，这个变量可以由流程引擎20自动赋值。这个计算量可以极大的扩展条件可以表达的范围，比如实现节点并行的功能。

图3示出了根据本发明实施例的一种节点结构图。图3的业务流程可以描述为：第一节点221-1之后由第二节点221-2和第三节点221-3并行执行各自的处理，第二节点221-2和第三节点221-3都处理完了之后，进入第四节点221-4。这时只要设置第四节点221-4的准入条件224为第二节点221-2指向第四节点221-4的连线元素223-1和第三节点221-3指向第四节点221-4的连线元素223-2都起效，就可以实现这个并行逻辑了。当然，激活当前节点221的连线也可以和其他变量组合使用。

由于使用准入条件224实现并行逻辑相对比较复杂，所以流程引擎20还设计了另一种方案让并行逻辑相对简单的实现。即，除了上述开始节点和结束节点之外，将中间节点分为单一节点和合并节点两种类型。对于单一节点来说，只要有任何指向自己的连线元素223被激活，就尝试激活自己，对于合并节点来说，只有所有指向自己的连线元素223都被激活，才尝试激活自己。如图3中所示，第四节点221-4可被设置为合并节点，以实现并行逻辑。

合并节点的另一个特点是：当一个合并节点的多个上一节点都具有驳回权限时，无论哪一个上一节点驳回，其他上一节点如果还未处理，则应该中止处理；如果已经处理，则应该同样作废当前节点的节点结论。例如，如图3中所示，节点221-4是一个合并节点，其具有两个上一节点，即第二节点221-2和第三节点221-3，如果第二节点221-2和第三节点221-3都具有驳回权限，则只要第二节点221-2和第三节点221-3中的一个驳回其处理（即该节点的节点结论为否定的），其他上一节点如果还未处理，则应该中止处理；如果已经处理，则应该同样作废当前节点的节点结论。这可以通过遍历激活日志来确定。一个连线元素223被激活时，流程引擎20都要记录相应的连线元素的一条激活日志，该激活日志至少包括被激活的连线元素的源节点和目标节点，目标节点又是下一条激活日志的连线元素的源节点。因此完整的激活日志可以被看做整个审批路径的记录。当业务流程实例进入一个节点时，流程引擎20会遍历该业务流程实例关联的所有起效的激活日志，查看每条激活日志中的连线元素223的源节点是否就是当前节点。如果是，则表示该业务流程实例被转回了。在这种情况下，将这条激活日志及其后续激活日志都置为失效。同时，流程引擎20还可以记录节点处理状态，一条激活日志失效时会同时检查该节点的处理状态，如果节点尚未处理，则终止该节点的处理。在这种情况下，第一节点221-1可以重新提交其处理请求，使得第二节点221-2和第三节点221-3再次获得处理权限。

在表单方面，本发明设计了一个数据集，集合里可以新建单元，单元之间可以建立对应关系，比如新建一个单元叫个人信息，一个单元叫车产信息，一个单元叫房产信息，个人信息和车产信息之间是一对多关系，个人信息和房产信息之间是多对多关系。

单元里可以新建字段，字段可以理解为单元的属性，字段可以配置对应的索引Key、名称、类型、录入方式、显示样式等，其中录入方式和显示样式实质是一个标签，由各种终端分别定义渲染样式，每种终端还可以定义不同的皮肤。

创建表单的时候实质是从已有的数据集中选择需要的单元，再从单元里选择需要的字段，并存储这些数据集、单元、字段在该表单中的特殊性质，比如定义不同的别名，或定义不同的录入方式和显示样式。但因为表单用的是统一的存储逻辑，所以不同表单之间的相同字段，就可以在系统层面作出关联，极大的方便后续的数据处理。

在本发明中，可以针对每个流程模板220建立一个单独的表单。在流程引擎20中，任务事件222的标识2222指向外部系统（如任务引擎30）的一个任务处理逻辑。对于每个不同的标识2222，可以基于整个系统的完整表单设置各个数据集、单元甚至属性的可读和可写性质，从而实现不同节点看到或录入表单的不同部分。

因此，对于每个流程模板220来说，其都对应于一个表单模板，对于流程模板220中的每个任务事件222的标识2222，表单模板的全部或部分可见或可编辑，业务流程实例发起后会根据流程模板220进行节点流转，进入节点实质就是依次处理节点里的任务事件，于是该业务流程实例在某个时间点会得到某个任务事件222的标识2222，可以基于该标识2222得到此刻的表单模板，再通过实例对应业务数据，渲染出一个可用的表单。

图4示出了根据本发明的实施例的处理审批业务流程的方法100的流程图。方法100例如可以由图1中所示的系统1中的流程引擎20的多个计算设备210执行。在一个审批业务流程的不同阶段，可以由流程引擎20的不同节点221（可以位于同一计算设备210或不同计算设备210）执行相应的处理。以下以流程引擎20在其中一个中间节点221处的处理为例，结合图1至图8对方法100进行描述。

如图4中所示，在步骤110，流程引擎20（如流程引擎20所对应的计算设备210）基于一个审批业务需求对流程模板220实例化以产生一个审批业务实例。

如图1中所示，该审批业务需求可以是流程引擎20从业务终端10接收的。如前所述，流程引擎20中可能包括多个流程模板220，分别用于多种不同的审批业务类型。因此，在步骤110中，在接收到审批业务需求之后，流程引擎20可以基于该审批业务需求所指示的审批业务的类型从多个流程模板220中选择该流程模板。

如图2中所示，对流程模板220实例化所产生的审批业务实例可以包括至少三个节点221，这些节点221可以包括开始节点、结束节点和至少一个中间节点。以下仅以中间节点221为例来对方法100进行描述。中间节点221可以包括至少一个任务事件222和至少一个连线元素223，每个连线元素223用于指示从中间节点221到该中间节点221的下一节点的约束条件。

在业务流程实例进入一个中间节点221之前，需要确定该业务流程实例是否满足进入该中间节点的条件。为此，在步骤120，流程引擎20基于该审批业务实例的一个中间节点221的上一节点的至少一个连线元素223确定该审批业务实例是否可以进入该中间节点221。

图5示出了根据本发明的用于确定审批业务实例是否可以进入一个中间节点221的步骤120的一种实施例的流程图。

如图5中所示，在子步骤122，流程引擎20确定该中间节点221的类型是单一节点还是合并节点。如前所述，对于单一节点来说，如果指向该单一节点的任一连线元素被激活，则该单一节点被激活，而对于合并节点来说，只有指向该合并节点的所有连线元素都被激活，该合并节点才被激活。

因此，如果确定该中间节点221的类型是合并节点，则在子步骤124，流程引擎20确定指向该合并节点的所有连线元素是否都被激活。这里，流程引擎20例如可以通过查看这些连线元素的激活日志来确定这些连线元素是否都被激活。例如，如图3中所示，第四节点221-4是合并节点，因此流程引擎20可以通过查看指向第四节点221-4的连线元素223-1和223-2的激活日志来确定这些连线元素223-1和223-2是否都已被激活。在业务流程实例从一个节点流转至另一节点时，流程引擎20会记录这两个节点之间的连线元素的激活日志，该激活日志中包含有该连线元素的源节点和目标节点。例如，对于图3所示的连线元素223-1来说，流程引擎20为其记录一条激活日志，该连线元素223-1的源节点为第二节点221-2，目标节点为第四节点221-4。类似地，对于图3所示的连线元素223-2来说，流程引擎20为其记录一条激活日志，该连线元素223-2的源节点为第三节点221-3，目标节点为第四节点221-4。

更具体地，子步骤124可以包括：对于指向该合并节点的所有连线元素中的每个连线元素223，确定该连线元素223的激活日志；确定该连线元素223的激活日志的源节点是否是该合并节点；以及

如果确定该连线元素223的激活日志的源节点是该合并节点，将该连线元素223设置为失效，并且确定该连线元素223未被激活。

例如，如图3中所示，第四节点221-4是合并节点。在子步骤124，确定指向第四节点221-4的连线元素223-1和223-2的激活日志。分别确定连线元素223-1和223-2的激活日志的源节点是否是第四节点221-4。如果确定连线元素223-1（或223-2）的激活日志的源节点是第四节点221-4，将该连线元素223-1（或223-2）设置为失效，并且确定该连线元素223-1（或223-2）未被激活。这是因为，对于每次节点间的流转，都会记录一个连线元素的激活日志，如果日志记录中已经有一条以当前节点为源节点的激活日志，则表示该业务流程实例被转回了（也就是说流程之前某个时刻是从当前节点出发的）。在这种情况下，可以将当前的激活日志和后续的激活日志都设置为失效，以使得整个业务流程实例能够重新开始。

类似地，如果确定该中间节点221的类型是单一节点，则在子步骤126，流程引擎20确定指向该单一节点的任一连线元素223是否被激活。

如果确定指向该合并节点的所有连线元素223都被激活或者指向该单一节点的任一连线元素223被激活，在子步骤128，流程引擎20确定该审批业务实例可以进入该中间节点221。

另一方面，如果确定指向该合并节点的任一连线元素223未被激活或者指向该单一节点的所有连线元素223都未被激活，流程引擎20可以确定该审批业务实例不能进入该中间节点221（图中未示出）。

图6示出了根据本发明的用于确定审批业务实例是否可以进入一个中间节点221的步骤120的另一种实施例的流程图。

如图6中所示，在子步骤122'，流程引擎20确定该中间节点221的准入条件的变量值。如前所述，该准入条件的变量值由流程引擎20自动赋值，其可以基于指向该中间节点221的连线元素223的逻辑值计算得到。

接下来，在子步骤124'，确定该中间节点221的准入条件的变量值是否符合该中间节点221的准入条件，并且如果确定该中间节点221的准入条件的变量值符合该中间节点221的准入条件，在子步骤126'，确定该审批业务实例可以进入该中间节点221。

另一方面，如果确定该中间节点221的准入条件的变量值不符合该中间节点221的准入条件，流程引擎20可以确定该审批业务实例不能进入该中间节点221（图中未示出）。

继续图4，如果确定该审批业务实例可以进入该中间节点221（步骤120的判断为是），在步骤130，流程引擎20使该审批业务实例进入该中间节点221，处理该中间节点221所包括的至少一个任务事件222并且基于该至少一个任务事件222的处理结果产生该中间节点221的节点结论。

图7示出了根据本发明的产生中间节点221的节点结论的步骤130的一种实施例的流程图。

如图7中所示，步骤130可以包括子步骤132，其中流程引擎20确定该中间节点221所包括的每个任务事件222的标识2222。

在子步骤134，流程引擎20将该任务事件222的标识2222传送至任务引擎30，并且在子步骤136，从任务引擎30接收该任务事件222的处理结果。如前所述，任务引擎30可以基于为流程模板220建立的表单模板确定标识2222对应的任务事件222，得到该任务事件222的相应的数据集、单元甚至属性的性质等，从而执行相应的任务。

在该中间节点221所包括的所有任务事件222的任务都处理之后，在子步骤138，流程引擎20可以基于这些任务事件222的处理结果产生该中间节点221的节点结论。取决于流程模板220的配置方案的不同，节点结论与各个任务事件222的处理结果之间的关系也不相同。例如，在多个任务事件222具有依赖关系的情况下，中间节点221的节点结论可以是最后一个执行的任务事件222的处理结果，而在多个任务事件222没有依赖关系的情况下，中间节点221的节点结论可以是所有任务事件222的逻辑运算结果。

接下来，在步骤140，流程引擎20基于该中间节点221的节点结论确定该审批业务实例是否能够向该中间节点221的下一节点转移。更具体地，对于从该中间节点221到其每个下一节点的连线元素223，流程引擎20可以确定该连线元素223是否与限定节点结论相关联。如果该连线元素223与限定节点结论相关联，确定步骤130得到的节点结论与该限定节点结论是否一致，并且在步骤130得到的节点结论与该限定节点结论一致时，才确定该审批业务实例能够向该中间节点221的下一节点转移。或者，如果该连线元素223不与限定节点结论相关联，可以直接确定该审批业务实例能够向该中间节点221的下一节点转移。反之，如果确定某个连线元素223与限定节点结论相关联但是在步骤130得到的节点结论与该限定节点结论不一致，确定该审批业务实例不能向该中间节点221的下一节点转移。

在步骤150，如果确定该审批业务实例能够向该中间节点221的下一节点转移，流程引擎20为该中间节点221的连线元素223记录激活日志，该激活日志至少包括该中间节点221作为源节点，该中间节点221的下一节点作为目标节点。

另一方面，如果在步骤120确定该审批业务实例不能进入该中间节点221，在步骤160，流程引擎20使得该审批业务实例不进入该中间节点221。

如果在步骤140确定该审批业务实例不能向下一节点转移，在步骤170，流程引擎20使得该审批业务实例不向下一节点转移。

图8示出了适合实现本发明的实施例的计算设备800的结构方框图。计算设备800例如可以是如上所述的流程引擎20或者流程引擎20中的一个计算设备210。

如图8中所示，计算设备800可以包括一个或多个中央处理单元（CPU）810（图中仅示意性地示出了一个），其可以根据存储在只读存储器（ROM）820中的计算机程序指令或者从存储单元880加载到随机访问存储器（RAM）830中的计算机程序指令，来执行各种适当的动作和处理。在RAM 830中，还可存储计算设备800操作所需的各种程序和数据。CPU 810、ROM 820以及RAM 830通过总线840彼此相连。输入/输出（I/O）接口850也连接至总线840。

计算设备800中的多个部件连接至I/O接口850，包括：输入单元860，例如键盘、鼠标等；输出单元870，例如各种类型的显示器、扬声器等；存储单元880，例如磁盘、光盘等；以及通信单元890，例如网卡、调制解调器、无线通信收发机等。通信单元890允许计算设备800通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

上文所描述的方法100例如可由计算设备800的CPU 810执行。例如，在一些实施例中，方法100可被实现为计算机软件程序，其被有形地包括于机器可读介质，例如存储单元880。在一些实施例中，计算机程序的部分或者全部可以经由ROM 820和/或通信单元890而被载入和/或安装到计算设备800上。当计算机程序被加载到RAM 830并由CPU 810执行时，可以执行上文描述的方法100的一个或多个操作。此外，通信单元890可以支持有线或无线通信功能。

本领域技术人员可以理解，图8所示的计算设备800仅是示意性的。在一些实施例中，流程引擎20可以包含比计算设备800更多或更少的部件。例如，在用户终端20是便携式移动终端的情况下，其可以包含比计算设备800所示更少的部件。

利用本发明的方案，通过设置全配置化的审批流程模板，使得能够针对各种审批模式容易地配置、实例化和处理相应的业务流程实例，并且通过将流程模板与表单模板相对应，能够更容易地得到每个流程实例的可用的表单。

以上结合附图对根据本发明的处理审批业务流程的方法100及可用作流程引擎20的计算设备800进行了描述。然而本领域技术人员可以理解，方法100的步骤的执行并不局限于图中所示和以上所述的顺序，而是可以以任何其他合理的顺序来执行。此外，计算设备800也不必须包括图8中所示的所有组件，其可以仅仅包括执行本发明中所述的功能所必须的其中一些组件，并且这些组件的连接方式也不局限于图中所示的形式。

本发明可以是方法、装置、系统和/或计算机程序产品。计算机程序产品可以包括计算机可读存储介质，其上载有用于执行本发明的各个方面的计算机可读程序指令。

在一个或多个示例性设计中，可以用硬件、软件、固件或它们的任意组合来实现本发明所述的功能。例如，如果用软件来实现，则可以将所述功能作为一个或多个指令或代码存储在计算机可读介质上，或者作为计算机可读介质上的一个或多个指令或代码来传输。

本文公开的装置的各个单元可以使用分立硬件组件来实现，也可以集成地实现在一个硬件组件，如处理器上。例如，可以用通用处理器、数字信号处理器（DSP）、专用集成电路（ASIC）、现场可编程门阵列（FPGA）或其它可编程逻辑器件、分立门或者晶体管逻辑、分立硬件组件或用于执行本文所述的功能的任意组合来实现或执行结合本发明所描述的各种示例性的逻辑块、模块和电路。

本领域普通技术人员还应当理解，结合本发明的实施例描述的各种示例性的逻辑块、模块、电路和算法步骤可以实现成电子硬件、计算机软件或二者的组合。

本发明的以上描述用于使本领域的任何普通技术人员能够实现或使用本发明。对于本领域普通技术人员来说，本发明的各种修改都是显而易见的，并且本文定义的一般性原理也可以在不脱离本发明的精神和保护范围的情况下应用于其它变形。因此，本发明并不限于本文所述的实例和设计，而是与本文公开的原理和新颖性特性的最广范围相一致。