[发明专利]工作流计时方法、装置及系统

说明书

技术领域

本发明涉及工作流(workflow)技术领域，尤其涉及一种工作流计时方法、装置及系统。

背景技术

目前工作流应用中存在的时限要求的情况主要包括三种：1、业务流程的时限要求、2、单个环节的实现要求、3、多个连续环节的实现要求。现有工作流系统中对时限的配置方式主要有以下两种：1)配置流程的超时和提醒属性、2)配置流程中单个节点超时和提醒属性。以上两种配置方式可以分别支持上述业务时限要求的前两种情况，对于第三种情况，需要对多个连续节点统一计时的情况，以上现有工作流系统中都没有直接提供支持。

一种规避方案使用子流程满足时限要求，即将需要作为一个整体来计时的节点提取出来作为一个子流程嵌套进来，对于子流程，因为其本身就为可独立运行流程，在其上可以配置流程的时限属性和流程中各节点的时限属性，因此对于一些单向的，单一分支的简单流程，可以采用子流程的方式来满足多个连续节点统一计时的情况。下面以一个具体工作流系统为例说明，参见图1，为投诉流程示意图，如果要求计费部门受理、计费部门审核及计费部门处理三个环节作为整体统一计时，在规定时间内需要处理完成并提交到客户中心反馈环节，则可以将这三个环节提取出来作为一个支撑部门处理的子流程潜入到投诉处理流程中，并对该子流程配置实现属性，参见图2。

对于多个连续节点统一计时的情况，采用子流程虽能满足一些简单的、单向的流程计时需求，然而，发明人在实践过程中发现，它仍存在一些不足，子流程只能从开始节点进入，而无法从父流程的某个节点直接跳入到子流程中的某个节点，反之亦然，以图3为例，父流程中的节点1无法直接跳入到子流程中的节点3，子流程中的节点3也无法直接跳出到父流程中的节点5，因此，对于多分支的流程以及流程执行中存在回退的情况时，就不能简单地使用子流程进行连续节点计时。另外，作为整体计时的多个节点通常都不要求只能从第一个节点被执行时才开始计时、最后一个节点完成时计时才结束，而通常都是要求进入到该整体的任意一个节点时便开始计时，而只要流程转出该整体时计时就结束，这种情况下采用子流程也无法实现。

下面以软件开发中的问题单处理流程为例对子流程方案存在的问题进行说明。

软件在开发完成之后都要经过详细的测试才能提供给用户使用，在这个过程中为了更好地跟踪和管理，对测试过程中发现的问题都需要提交问题单，参见图4，整个流程可以分为三大部分：

一、问题提交

①问题发现者A提交问题单给项目经理B(或测试经理)--＞②项目经理B确认问题；

二、问题修改

③项目经理B指定开发人员C分析问题--＞④开发人员C分析问题--＞⑤项目经理B确认问题分析结果--＞⑥开发人员C修改问题--＞⑦项目经理B安排其他开发人员D验证问题修改结果；

三、问题验证

⑧测试经理B指定测试人员E测试问题修改结果--＞⑨测试人员E验证测试--＞⑩问题发现者A验证测试。

其中：

1.问题提交部分，问题发现者可以是专门的测试人员也可以是开发人员，如果问题为测试人员发现，提交给测试经理，测试经理确认问题后提交给项目经理，由项目经理指定开发人员来分析问题；如果问题为开发人员发现，则提交给项目经理，项目经理确认问题后，不需再次提交给自己来指定开发人员分析问题，而是可以直接指定并提交给开发人员进行分析，如果问题发现者就是相关功能的开发者或者问题在提交时已进行分析，则可直接提交给开发人员进行修改；

2.问题验证部分，不管是在测试人员验证还是提交人验证环节，如果发现问题没有修改正确，都需退回到开发人员重新修改，即退回环节⑥；

3.问题修改部分，如果问题发现者为问题修改人，则问题修改完成后可直接提交测试经理安排测试人员进行验证测试，不需再提交经理指定其他开发人员进行验证。这一部分全部由开发部门人员处理，要求3天内要修改完成，即这一部分需要作为整体统一计时，并且当流程进入到这一部分中的任何一个环节时计时开始，流程流转出该部分则计时结束；

则对于此类流程，如果将问题修改部分提取出来作为子流程嵌入到问题单处理流程中，就无法满足流程的要求，因为子流程只能从开始节点进入，在上述提到的开发人员发现并提交问题的情况和问题验证失败的情况下，都需要从主流程直接进入到子流程的某个特定节点，但子流程不能支持这种运行方式，因此对于此类流程，就无法使用子流程来实现连续节点的整体计时了。

发明内容