CN101017545A - 一种业务处理方法及装置 - Google Patents

Abstract

本发明公开了一种业务处理方法，包括步骤：运行第一流程实例，并在能够提供第二流程实例运行过程中需要满足的特定条件时，发出该特定条件已满足的通知；继续运行所述第一流程实例；运行第二流程实例；在运行所述第二流程实例到特定环节时，检测是否接收到在第一流程实例运行过程中发出的该第二流程实例运行过程中需要满足的特定条件已满足的通知；在已接收到所述通知时，从所述特定环节开始继续运行所述第二流程实例，并在所述特定环节或所述特定环节后续环节中利用该已满足的特定条件。此外本发明还提供了一种业务处理装置。本发明可以处理在工作流运行期间对其它流程实例产生动态依赖关系的依赖流程实例。

Description

一种业务处理方法及装置

技术领域

本发明涉及工作流领域，特别涉及一种业务处理方法及装置。

背景技术

在计算机支持的自动处理业务过程中，工作流指全部或者部分业务处理流程，工作流的节点指业务处理流程中的一个业务环节。工作流管理系统是定义、创建、执行工作流的系统，具备流程建模、运行控制和运行交互等功能，当然该系统需要装载在硬件设备上。工作流管理系统在处理上层业务时，先对实际业务静态建模并完成流程定义，再根据流程定义在运行期间从上层业务接收业务数据，自动对工作流过程中的活动进行调度，驱动上层业务流程的流转，其核心意义就是自动对流程中活动进行调度并驱动上层业务的流转。

一个具体的业务处理过程可以称为一个流程实例，不同流程实例间可能存在不同的依赖关系，这些关系有可能在建模时就能确定，也有可能在运行期间动态的产生。现有工作流管理系统几乎都支持子流程的功能，子流程体现了流程的一种静态的依赖或从属关系，在建模期间就能确定，是整个流程的组成部分，并且可以包含自己的活动定义、内部转换、资源和应用程序的分配。

现有技术在提供子流程的功能时较普遍的解决方案是，提供一种子流程节点类型，在该节点上配置将要运行的子流程，用户在定义流程的时候可以在某个流程中添加一个子流程节点，并编辑此子流程节点，指定该节点对应的具体的子流程的名称，以及该子流程的执行方式(同步/异步)，添加子流程节点的流程相应地为该子流程的父流程；在运行过程中，当父流程实例执行到子流程节点时，父流程实例根据指定的子流程名字，创建并启动一个子流程实例，然后根据定义的子流程的执行方式(同步/异步)决定是否等待子流程的执行。

例如某公司的电子文档评审过程，文档可能分为很多类型，如A类文档、B类文档和C类文档等，工作流管理系统建立的模型中定义有一个文档评审受理流程和多个评审流程，用于评审不同类型的文档，并为不同类型的文档指定了不同权限的评审人和评审步骤；

用户发出评审请求并提交文档至服务器后，工作流管理系统实施的处理流程如下：

在步骤10中，受理用户提交的文档，并判断该文档类型；

在步骤20中，根据文档的类型启动一个针对该文档的评审流程；

在步骤30中，将包含该文档的链接发送给相应的初审人员；

在步骤40中，接收初审人员提交的初审意见和签名；

在步骤50中，将包含该文档、初审意见及初审人员签名的链接发送给复审人员；

在步骤60中，接收复审人员提交的复审意见和签名；

在步骤70中，将包含该文档评审记录(即初审意见、初审人员签名和复审意见、复审人员签名)的链接发送给文档提交者；

在步骤80中，接收文档提交者的指示进行归档，结束处理。

在上述的流程中，受理流程在收到评审请求后根据文档类型启动一个评审流程，受理流程与评审流程的关系即为父子关系，受理流程为父流程，评审流程为子流程。

子流程反映的是流程间的一种静态的依赖或从属关系，在用户定义流程时就可以确定，而对于在定义流程时无法确定，在流程运行期间才会动态产生依赖或从属关系却无法支持。

例如不同的两个流程实例开始运行后，这里流程实例指一个具体的业务处理流程，这两个流程实例可以由同一个流程定义，也可以由不同的流程分别定义。假定其中一个流程实例执行到某个环节后需要等待另一个流程实例满足特定条件后才可以继续往下执行，这时候流程间就存在依赖关系了，而这种依赖关系由于在运行期间动态产生，因此无法在建模时通过创建子流程来处理。

发明内容

本发明实施例提供一种业务处理方法及装置，可以处理在工作流运行期间产生动态依赖关系的依赖流程和被依赖流程。

本发明实施例提供的技术方案如下，

一种业务处理方法，包括：

运行第一流程实例，并在能够提供第二流程实例运行过程中需要满足的特定条件时，发出该特定条件已满足的通知；

继续运行所述第一流程实例；

运行第二流程实例；

在运行所述第二流程实例到特定环节时，检测是否接收到在第一流程实例运行过程中发出的该第二流程实例运行过程中需要满足的特定条件已满足的通知；

在已接收到所述通知时，从所述特定环节开始继续运行所述第二流程实例，并在所述特定环节或所述特定环节之后的后续环节中利用该已满足的特定条件。

一种业务处理装置，包括：

第一运行单元，用于运行第一流程实例，并在能够提供第二流程实例运行过程中需要满足的特定条件时，发出第二流程实例运行过程中需要满足的特定条件已满足的通知；

第二运行单元，用于运行第二流程实例，并在运行所述第二流程实例至特定环节时检测是否接收到所述第一运行单元发出的通知，以及在接收到所述通知后从所述特定环节开始继续运行所述第二流程实例，并在所述特定环节或所述特定环节后续环节中利用到所述第一运行单元提供的特定条件。

本发明实施例在工作流运行期间产生动态依赖关系时，通过确定流程实例间的相互关系，运行被依赖流程实例并在能够提供依赖流程实例所需要满足的特定条件后，通知依赖流程实例，所述依赖流程实例利用被依赖流程实例提供的条件完成依赖流程实例的运行，克服了现有技术中不能处理依赖流程的缺陷。

附图说明

图1为现有技术中父流程和子流程的运行示意图；

图2为本发明第一实施例提供的方法流程示意图；

图3a为本发明实施例应用情形之一；

图3b为本发明实施例应用情形之二；

图4为本发明第一实施例提供的装置结构示意图之一；

图5为本发明第一实施例提供的装置结构示意图之二；

图6为本发明第二实施例提供的方法中设置主、从流程实例的示意图；

图7为本发明第二实施例提供的方法流程示意图；

图8为本发明第二实施例提供的装置结构示意图。

具体实施方式

为了解决现有技术不能处理在运行期间动态产生依赖关系的流程实例，本发明实施例可以理解为，运行第一流程实例和依赖于所述第一流程实例的第二流程实例，在第一流程实例能够提供第二流程实例运行过程中需要满足的特定条件后，通知第二流程实例该特定条件已满足，并继续运行第一流程实例的后续环节；在第二流程实例运行到特定环节时，若没有收到该通知，在该特定环节等待直至收到该通知，若接收到该通知后，从需要等待通知的特定环节处开始继续运行，并在特定环节或特定环节之后的后续环节中利用所述第一流程实例能够提供的特定条件。

第一实施例中，第一流程实例和第二流程实例之间是否存在依赖关系由业务层自行判断，请参阅图2所示，图2揭示了本发明第一实施例的工作流程：

步骤210，创建一个流程实例a并运行；

步骤220，判断流程实例a在运行过程中是否依赖于另一个已处于运行中的流程实例，若是执行步骤221，若否执行步骤225；

步骤221，运行流程实例a至特定环节后停止；

这里将流程实例a所依赖的流程实例称为x，流程实例a需要利用到流程实例为x运行过程中提供的特定条件，所述特定条件及特定环节跟工作流管理系统建立的模型和具体的实例相关。

步骤222，在流程实例a的属性中设置流程实例x的ID；

对每一个流程实例，工作流管理系统都为其分配了一个唯一的ID。

步骤223，接收到流程实例a在运行过程中需要满足的特定条件已满足的通知；

步骤224，从特定环节开始继续运行流程实例a直至运行结束；

其中步骤222可以省略；而在设置了步骤222后，若流程实例a在该特定环节没有接收到该特定条件已满足的通知，可以根据自身属性中设有的流程实例x的ID查询流程实例x的运行情况，确认是否已能够提供流程实例a运行过程中需要满足的特定条件，并在所述特定条件满足后，从该特定环节开始继续运行流程实例a。

在运行过程中，有可能在流程实例a的特定环节就利用到流程实例x提供的特定条件，也有可能在在流程实例a的特定环节之后的后续环节才利用到流程实例x提供的特定条件。

步骤225，流程实例a在运行过程中没有依赖另一个已处于运行中的流程实例时，判断是否有依赖于流程实例a的其它流程实例在运行，若否，运行流程实例a至结束，若是执行步骤226；

步骤226，依赖于流程实例a的其它流程实例可以是一个，也可以是多个，这里假定为一个，称之为流程实例y，在流程实例a的属性中设置映射表，并在映射表中添加流程实例y的ID；

步骤227，运行流程实例a直至能够提供流程实例y运行过程中需要满足的特定条件；

步骤228，从流程实例a的映射表中获取流程实例y的ID，并发出通知，该通知中包含有流程实例y运行过程中需要满足的特定条件已满足这一消息；

在实际执行时，因为已经得知流程实例y依赖于流程实例a，可以省略步骤226，并在步骤228中直接发送通知给流程实例y；

步骤229，继续运行流程实例a直至结束。

在依赖于流程实例a的其它流程实例为多个的情况下，比如还存在依赖于流程实例a的流程实例z时，可以按照对流程实例y的处理依次类推，不难实现。

本实施例中具体地判断出一个流程实例依赖于另一个处于运行中流程实例主要有两种情形，为便于表达，假定该依赖的流程实例是a，被依赖的流程实例为x。

第一种情形，流程实例a和流程实例x由同一流程定义，此时只需要将流程实例x完整的执行下来，没有必要将流程实例a的整个流程也完整执行下来，可以省略其中一些环节，直接利用在流程实例x运行过程中得到的特定结果，所述特定结果跟工作流管理系统建立的模型和具体的实例相关。

例如，在电信领域中，如果通信出现故障，会收到很多用户投诉，由于导致投诉的原因可能是同一个触发事件，在这种情况下，对这些投诉不能简单的以重复投诉拒绝，但也没必要将每个投诉都一步不少地执行完；可以完整地处理一个投诉，处理完后其它投诉都可直接跳转到用户反馈环节。如图3a所示，工作流管理系统在受理环节A接收到多个针对同一触发事件引起投诉后，确定其中一个为需要完整处理的投诉(即流程实例x)，其它的为需要部分处理的重复投诉(其中包含流程实例a)。流程实例a受理后被系统挂起，也就是在受理环节A处于停止运行状态，运行流程实例x，在执行完具体处理环节B和C，进入D环节即用户反馈环节之前，并发出包括流程实例a在内的其它重复投诉需要的特定条件已满足的通知，工作流管理系统根据该通知将其它重复投诉例如流程实例a从受理环节A直接跳转至用户反馈环节D进行处理，并在反馈环节D利用到运行流程实例x到C环节之后、D环节之前产生的处理结果。这里的特定条件是已运行完流程实例x的环节C，并且输出相应的处理结果。

第二种情形，流程实例a和流程实例x分别由流程一、流程二定义，流程一和流程二是两个不同的流程，而流程一需要依赖于在流程二运行过程中提供的特定条件。

如图3b所示，在运行流程实例a至C2环节后，需要利用到运行流程实例x产生的特定结果后才能继续往下运行，这时停止流程实例a的运行，进行等待。运行流程实例x到C1环节，并在产生特定结果后通知工作流管理系统：流程实例a需要满足的特定条件已满足。系统继续运行流程实例x，并在接收到该通知后利用该特定结果从C2环节开始继续运行流程实例a直至结束。所述特定结果、特定状态跟工作流管理系统建立的模型和具体的实例相关。

请参阅图4所示，图4揭示了第一实施例提供的一个装置结构示意图。

所述装置包括第一运行单元11和第二运行单元12，

第一运行单元11用于运行第一流程实例，并在能够提供第二流程实例运行过程中需要满足的特定条件时，发出第二流程实例运行过程中需要满足的特定条件已满足的通知；

第二运行单元12用于运行第二流程实例，并在运行所述第二流程实例至特定环节时检测是否接收到所述第一运行单元发出的通知，以及在接收到所述通知后从所述特定环节开始继续运行所述第二流程实例，并在所述特定环节或所述特定环节之后的后续环节中利用到所述第一运行单元11提供的特定条件。

第二运行单元12在没有接收到第一运行单元11发出的通知后，停止运行所述第二流程实例，直至接收到第一运行单元11发出的通知。

请参阅图5所示，图5揭示了第一实施例提供的又一装置结构示意图，与图4相比，增加了判断单元13以及查询单元14，其中判断单元13用于判断所述第二流程实例是否对所述第一流程实例存在依赖关系，并在判断结果为肯定时，通知第一运行单元11和第二运行单元12。

查询单元14，用于在第二运行单元12运行所述第二流程实例至特定环节、且所述第二运行单元12未接收到第一运行单元11发出的通知时，查询第一运行单元11是否已能够提供所述第二流程实例运行过程中需要满足的特定条件，并将查询结果发送给第二运行单元12。

第二运行单元12在查询结果为肯定时，即第一运行单元11已能提供所述第二流程实例运行过程中需要满足的特定条件时，从所述特定环节开始继续运行所述第二流程实例，并在所述特定环节或所述特定环节后续环节中利用到第一运行单元11提供的特定条件。

当然在图4的基础上也可以只增加判断单元13或者只增加查询单元14。

本实施例与现有技术相比，通过判断流程间的相互关系，可以处理在工作流运行期间产生动态依赖关系的依赖流程和被依赖流程，然而由于工作流管理系统中没有记录流程是依赖流程、被依赖流程还是普通流程，也没有记录流程相互之间的关系，因此需要在业务层编写额外的代码来进行控制和维护。

进一步地，在第二实施例中，在工作流管理系统建立模型时就已经能够预见到这种将会在运行期间动态产生的依赖关系，将那些依赖其它流程实例的流程实例即依赖流程实例称为从流程实例，而被依赖的那个流程实例称为主流程实例，显然从流程实例在运行过程中依赖于主流程实例所提供的特定条件，其中特定条件及特定环节跟工作流管理系统建立的模型和具体的实例相关。

本实施例中，添加如下属性到流程实例中：

{

流程实例类型：整数类型；//用于表示流程实例是从流程实例、主流程实例或普通流程实例；

主流程实例ID：字符串类型；//如果本流程实例为从流程实例，该属性保存了本从流程实例对应的主流程实例ID，否则为空；

从流程实例ID列表：列表类型；//如果本流程实例为主流程实例，该属性保存了对应的从流程实例ID，否则为空；

}

请参阅图6，图6揭示了本发明第二实施例提供的方法中设置主、从流程实例的过程。

步骤601，创建一个流程实例；

步骤602，确定出该流程实例依赖于另一个流程实例；

在工作流管理系统中，创建一个流程实例时，根据工作流管理系统建立的模型，就可以得知该流程实例是否依赖于另一个流程实例。

步骤603，在依赖流程实例属性中设置依赖流程实例是从流程实例，并在该从流程实例中设置依赖流程实例和被依赖流程实例的对应关系；

设置依赖流程和被依赖流程实例的对应关系时，可以在依赖流程实例中设置被依赖流程实例的ID。

步骤604和605，在被依赖流程实例属性中设置被依赖流程实例是主流程实例，并在该主流程实例中设置依赖流程实例和被依赖流程实例的对应关系；

设置被依赖流程和依赖流程实例的对应关系时，可以在被依赖流程实例中设置从流程实例ID列表，并在该从流程实例ID列表中添加对应的依赖流程实例ID。

此外，对既不是主流程实例又不是从流程实例的流程实例，可以直接在属性中设置为普通流程实例，且主流程实例ID和从流程实例ID列表为空，在设置主流程实例和从流程实例之间的对应关系时，也可以是其他业界知悉的方式。

通过上述步骤，即可以把相应的属性添加到流程实例中。此外如果从流程实例依赖的主流程实例为多个时，可以在其属性中将主流程实例ID改为主流程实例ID列表(列表类型)，并将所依赖的主流程实例ID添加到流程实例ID列表中。

请参阅图7所示，图7揭示了本发明第二实施例提供的方法流程示意图。

工作流管理系统在创建一个流程实例时，如果确定出该流程实例依赖于另一个流程实例，就可以设置该依赖流程实例为从流程实例，被依赖流程实例为主流程实例。执行流程实例的具体步骤如下：

步骤711，运行主流程实例；

步骤712，运行主流程实例直至能够提供从流程实例运行过程中需要满足的特定条件；

步骤713，从主流程实例的从流程实例ID列表中找到对应从流程实例的ID，发出这些对应的从流程实例运行过程中需要满足的特定条件已满足的通知；

步骤714，继续运行主流程实例至结束；

步骤731，运行从流程实例；

步骤732，运行从流程实例至特定环节后停止；

步骤733，根据从流程实例属性中设置的主流程实例ID查询对应的主流程实例的运行情况，确认是否已能够提供从流程实例运行过程中需要满足的特定条件；

步骤734，接收到从流程实例运行过程中需要满足的特定条件已满足的通知；

步骤735，在属性中将从流程实例设置普通流程实例；

步骤736，利用在运行主流程实例过程中提供的特定条件继续运行该流程实例至结束。

运行从流程实例至特定环节后，也可以不进行查询，直接等待系统运行对应主流程实例过程中发送的通知，在接收到通知后，也可以不修改属性，直接向下运行。

对普通技术人员来说，不难理解，运行主流程实例和运行从流程实例是可以并行的。

请参阅图8所示，图8揭示了第二实施例提供的一个装置结构示意图。

所述装置包括第一运行单元21、第二运行单元22、设置单元23以及查询单元24，其中

第一运行单元21用于运行主流程实例，并在能够提供从流程实例运行过程中需要满足的特定条件时，发出所述从流程实例运行过程中需要满足的特定条件已满足的通知；

第二运行单元22用于运行从流程实例，并在运行从流程实例至特定环节后，检测是否接收到所述第一运行单元21发出的从流程实例运行过程中需要满足的特定条件已满足的通知，以及在接收到该通知时，从所述特定环节开始继续运行所述从流程实例，并在所述特定环节或所述特定环节后续环节中利用第一运行单元21提供的特定条件。

第二运行单元22在没有接收到所述第一运行单元21发出的通知时，停止运行所述至从流程实例，直至接收到所述通知。

设置单元23用于在确定出一个流程实例依赖于另一个流程实例时，将被依赖流程实例的属性设置为主流程实例，将依赖流程实例的属性设置为从流程实例，以及在所述主流程实例的属性中设置所述主流程实例和从流程实例的对应关系。

进一步地，设置单元23还可以在从流程实例中设置该从流程实例和主流程实例的对应关系。

查询单元24，用于在第二运行单元22运行从流程实例至特定环节、且第二运行单元22未接收到第一运行单元21发出的通知时，查询第一运行单元21是否已能够提供所述从流程实例运行过程中需要满足的特定条件，并将查询结果发送给第二运行单元22。

第二运行单元22在查询结果为肯定时，即第一运行单元21已能够提供所述特定条件时，从所述特定环节开始继续运行所述从流程实例，并在所述特定环节或所述特定环节后续环节中利用到第一运行单元21提供的特定条件。

在本实例中，由于创建流程实例时可以得知该流程实例是否依赖于另一个流程实例，而设置单元主要作用是将依赖流程实例和被依赖流程实例的关系更加明确化，因此也可以不包括设置单元23；此外本实施例也可以不包括查询单元24。

本实施例由于工作流管理系统建立模型时就已经能够预见到这种将会在运行期间动态产生的依赖关系，不用在业务层编写额外的业务代码，就能得知流程实例间的相互关系，并能处理运行期间产生的动态依赖关系的依赖流程和被依赖流程。通过设置流程实例的属性，能够更加明确流程实例的类别以及不同类别流程实例间的相互关系，进一步增强工作流系统驱动业务流程的功能。

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

Claims (10)

1、一种业务处理方法，其特征在于，包括步骤：

运行第一流程实例，并在能够提供第二流程实例运行过程中需要满足的特定条件时，发出该特定条件已满足的通知；

继续运行所述第一流程实例；

运行第二流程实例；

在运行所述第二流程实例到特定环节时，检测是否接收到在第一流程实例运行过程中发出的该第二流程实例运行过程中需要满足的特定条件已满足的通知；

在已接收到所述通知时，从所述特定环节开始继续运行所述第二流程实例，并在所述特定环节或所述特定环节之后的后续环节中利用该已满足的特定条件。

2、如权利要求1所述的方法，其特征在于，所述检测是否接收到在第一流程实例运行过程中发出的该第二流程实例运行过程中需要满足的特定条件已满足的通知之后还包括：

在没有接收到所述通知时，停止运行所述第二流程实例，直至接收到所述通知。

3、如权利要求2所述的方法，其特征在于，所述停止运行所述第二流程实例之后还包括：

查询第一流程实例的运行状况，所述查询内容包含是否已能够提供第二流程实例运行过程中需要满足的特定条件。

4、如权利要求1或2或3所述的方法，其特征在于，运行第二流程实例时还包括：

确定出第二流程实例对第一流程实例存在依赖关系。

5、如权利要求4所述的方法，其特征在于，所述确定出第二流程实例对第一流程实例存在依赖关系具体为：

判断出所述第一流程实例和所述第二流程实例由同一流程定义。

6、如权利要求4所述的方法，其特征在于，所述确定出第二流程实例对第一流程实例存在依赖关系具体为：

判断出所述第一流程实例由第一流程定义，所述第二流程实例由第二流程定义，且所述第二流程的运行过程中需要利用到在所述第一流程运行过程中提供的特定条件。

7、一种业务处理装置，其特征在于，包括：

第一运行单元，用于运行第一流程实例，并在能够提供第二流程实例运行过程中需要满足的特定条件时，发出第二流程实例运行过程中需要满足的特定条件已满足的通知；

第二运行单元，用于运行第二流程实例，并在运行所述第二流程实例至特定环节时检测是否接收到所述第一运行单元发出的通知，以及在接收到所述通知后从所述特定环节开始继续运行所述第二流程实例，并在所述特定环节或所述特定环节之后的后续环节中利用到所述第一运行单元提供的特定条件。

8、如权利要求7所述的装置，其特征在于，所述第二运行单元在没有接收到所述第一运行单元发出的通知后，停止运行所述第二流程实例，直至接收到所述第一运行单元发出的通知。

9、如权利要求7或8所述的装置，其特征在于，还包括：

判断单元，用于判断所述第二流程实例是否对所述第一流程实例存在依赖关系，并在判断结果为肯定时，通知所述第一运行单元和所述第二运行单元。

10、如权利要求7或8所述的装置，其特征在于，还包括：

查询单元，用于在所述第二运行单元运行所述第二流程实例至特定环节、且所述第二运行单元未接收到所述第一运行单元发出的通知时，查询所述第一运行单元是否已能够提供所述第二流程实例运行过程中需要满足的特定条件，并将查询结果发送给所述第二运行单元；

所述第二运行单元在所述查询单元结果为肯定时，从所述特定环节开始继续运行所述第二流程实例，并在所述特定环节或所述特定环节之后的后续环节中利用到所述第一运行单元提供的特定条件。

Images