CN101393620A - 描述人工活动的模型 - Google Patents

Abstract

一种描述人工活动的模型，涉及业务流程管理类领域，也包括各种办公自动化系统、绩效管理系统等。这种描述人工活动的模型包括如下三个方面：谁来做：即通过参与者表达式确定活动的参与者；做什么：即确定活动的参与者要执行的业务单元；对流程的控制操作：即完成所述业务单元的处理后，参与者对流程状态的控制要求。该描述人工活动的模型定义了清晰的人工活动的模型，解决了业务流程管理系统中对人工活动进行建模的多个问题。

Description

描述人工活动的模型

技术领域

本发明涉及业务流程管理类领域，也包括各种办公自动化系统、绩效管理系统等，具体是一种描述人工活动的模型。

背景技术

在业务流程管理领域中，如何描述人工活动没有统一的标准。而在应用开发过程中，有些应用采用独立的工作流管理工具，有的应用则完成是自己实现流程管理的功能。对于自己开发实现流程管理功能的应用来说，往往将对人工活动的描述直接写在程序中，而不通过建模实现，从而为以后的调整带来麻烦。对于采用工作流管理工具的应用，由于大部分工作流管理工具对人工活动的描述也是不完备的，导致很多情况下，应用开发时需要自己扩展对人工活动的描述，甚至直接写到程序中。

在涉及流程管理的相关规范中，对人工活动的模型描述也是不完备的，如在WfMC的XPDL模型中，只描述了一项活动的参与者、对应的应用程序；在BPEL规范中，没有针对人工活动的描述。

当前大部分系统开发时描述人工活动的另外一个问题是，对人要处理的工作没有描述规范，只是简单的以应用来表示。而人要处理的工作，一方面是属于流程中本节点的工作，另一方面是对整个流程的处理。另外，在定义活动由哪人来处理方面，也没有相应的清晰的模型来处理。

发明内容

本发明的目的就是针对上述的不足，提供了一种完整的、可扩展的描述人工活动的模型，以满足居于独立的工作流管理工具开发应用系统实现人工活动的需要。

本方案是通过如下技术措施来实现的：这种描述人工活动的模型，包括如下三个方面：

谁来做：即通过参与者表达式确定活动的参与者；

做什么：即确定活动的参与者要执行的业务单元；

对流程的控制操作：即完成所述业务单元的处理后，参与者对流程状态的控制要求。

参与者可以有三种：人的标识、角色的标识、部门的标识。更复杂一点的情况是由以上三者的逻辑运算后得到，如角色A或者角色B等等。根据情况，可以通过一下集中方式确定谁来做：

指定某个执行人；

指定某个角色；

指定某些执行人；

指定某些角色；

根据参与者表达式计算所有符合的执行人；

根据参与者表达式计算所有符合的执行人并于指定执行人或者角色取交集；

根据参与者表达式计算所有符合的执行人并于指定执行人或者角色取合集。

上面所述参与者表达式包括如下基本元素：流程变量、系统变量、参与者属性以及逻辑运算符。

流程变量，既流程定义中的相关数据，与业务过程流相关的数据，引擎对外提供了流程运行时的相关数据，并保存应用对流程相关数据的修改；例如：参与者表达式中users相关数据表示为$R{users}。

系统变量，工作流系统自身的一些属性，提供给应用使用；例如：参与者表达式中系统属性“流程ID”表示为$S{Process.Id}。

参与者属性，参与者自身定义的一些属性；例如：参与者表达式中参与者属性“用户ID”表示为$P{id}。

逻辑运算符，引擎提供用户参与者表达式计算的逻辑运算符；例如：＝，>，<，>＝，<＝，！＝，include，and，or等。

参与者表达式主要是由参与者的属性与流程变量、系统变量的逻辑运算组成，例如“$R{users}include $P{id}”的含义就是，只要参与者的属性id被包含在users中，此参与者就为此活动的执行人；其中users相关数据值为应用赋的值，由应用动态决定参与者的范围。

所述业务单元是对业务逻辑分解的最小的执行单元，业务单元分为必做和不必做。任务分配不只是选择执行人，还包括任务分配策略，分配策略分为(1)会签，(2)抢任务。如果分配策略为抢任务，则从多个参与者之间选择一个人来完成所有的业务单元；如果分配策略为会签，则参与者共同完成所有的业务单元。

确定活动的参与者要执行的业务单元可以如下，业务单元分为必做和不必做。若业务单元为必做，则设置最大执行次数，默认为0，如果次数为0，则完成业务单元的次数不受限制；当大于0时，若执行完成业务单元的方法的次数等于必做次数时，该业务单元的状态自动更换为挂起，即不可再执行；若为不必做时，该业务单元可以不执行完成业务单元的方法。

所述对流程的控制操作为：通过流程定义配置人工活动节点允许执行的流程的控制操作，其反映此人工活动节点对流程的控制权限。工作流引擎的作用就在于分离业务逻辑与流程逻辑，业务单元的处理属于业务逻辑，是应用开发人员在进行实际的应用开发时根据某一特定的业务要求实现的。业务单元随项目需求的不用而不同。如在银行信贷管理系统中会有以下业务单元：业务申请录入、担保信息录入、查询退档意见、评级结果查询等。

在流程定义过程中，可配置人工活动节点允许执行的流程的控制操作，其反映了此人工活动节点对流程有什么样的控制权限，例如“批准”、“否决”、“打回”等等。

该描述人工活动的模型定义了清晰的人工活动的模型，解决了业务流程管理系统中对人工活动进行建模的多个问题。

●通过“参与者”“业务单元”“流程控制操作”来清晰人工活动的三个方面“谁来做”“做什么”“对流程的处理”；

●面向业务实现了流程逻辑与业务逻辑的分离。实现的方法简单有效，即为活动分别定义业务单元与流程控制操作；

●解决了业务单元之间解耦的问题。支持一个活动定义多个业务单元，业务单元面向工作流引擎交互，业务单元之间可通过模型来进行关系定义；

●实现了复杂的任务分配，即根据流程运行状态动态确定活动的执行人的功能。解决的办法是基于流程变量(流程相关数据)、系统变量、参与者属性进行逻辑表达示定义。

附图说明

图1为本发明实施例的体系结构图；

图2为本发明实施例的运行流程图。

具体实施方式

下面将对本发明的实施方式进行详细说明。

一种描述人工活动的模型，如图1，包括如下三个方面：

谁来做：即通过参与者表达式确定活动的参与者；

做什么：即确定活动的参与者要执行的业务单元；

对流程的控制操作：即完成所述业务单元的处理后，参与者对流程状态的控制要求。

参与者可以有三种：人的标识、角色的标识、部门的标识。更复杂一点的情况是由以上三者的逻辑运算后得到，如角色A或者角色B等等。根据情况，可以通过一下集中方式确定谁来做：

指定某个执行人；

指定某个角色；

指定某些执行人；

指定某些角色；

根据参与者表达式计算所有符合的执行人；

根据参与者表达式计算所有符合的执行人并于指定执行人或者角色取交集；

根据参与者表达式计算所有符合的执行人并于指定执行人或者角色取合集。

上面所述参与者表达式包括如下基本元素：流程变量、系统变量、参与者属性以及逻辑运算符。

流程变量，既流程定义中的相关数据，与业务过程流相关的数据，引擎对外提供了流程运行时的相关数据，并保存应用对流程相关数据的修改；例如：参与者表达式中users相关数据表示为$R{users}。

系统变量，工作流系统自身的一些属性，提供给应用使用；例如：参与者表达式中系统属性“流程ID”表示为$S{Process.Id}。

参与者属性，参与者自身定义的一些属性；例如：参与者表达式中参与者属性“用户ID”表示为$P{id}。

逻辑运算符，引擎提供用户参与者表达式计算的逻辑运算符；例如：＝，>，<，>＝，<＝，！＝，include，and，or等。

参与者表达式主要是由参与者的属性与流程变量、系统变量的逻辑运算组成，例如“$R{users}include $P{id}”的含义就是，只要参与者的属性id被包含在users中，此参与者就为此活动的执行人；其中users相关数据值为应用赋的值，由应用动态决定参与者的范围。

所述业务单元是对业务逻辑分解的最小的执行单元，业务单元分为必做和不必做。任务分配不只是选择执行人，还包括任务分配策略，分配策略分为(1)会签，(2)抢任务。如果分配策略为抢任务，则从多个参与者之间选择一个人来完成所有的业务单元；如果分配策略为会签，则参与者共同完成所有的业务单元。

确定活动的参与者要执行的业务单元可以如下，业务单元分为必做和不必做。若业务单元为必做，则设置最大执行次数，默认为0，如果次数为0，则完成业务单元的次数不受限制；当大于0时，若执行完成业务单元的方法的次数等于必做次数时，该业务单元的状态自动更换为挂起，即不可再执行；若为不必做时，该业务单元可以不执行完成业务单元的方法。

所述对流程的控制操作为：通过流程定义配置人工活动节点允许执行的流程的控制操作，其反映此人工活动节点对流程的控制权限。工作流引擎的作用就在于分离业务逻辑与流程逻辑，业务单元的处理属于业务逻辑，是应用开发人员在进行实际的应用开发时根据某一特定的业务要求实现的。业务单元随项目需求的不用而不同。如在银行信贷管理系统中会有以下业务单元：业务申请录入、担保信息录入、查询退档意见、评级结果查询等。

在流程定义过程中，可配置人工活动节点允许执行的流程的控制操作，其反映了此人工活动节点对流程有什么样的控制权限，例如“批准”、“否决”、“打回”等等。

如图2，该模型运行流程如下：

通过流程定义工具定义人工活动过程，以请假流程为例：

步骤2011，定义当前活动基本信息，活动ID、名称等。

然后步骤2012，定义当前活动参与者。例如一个请假申请流程，第一个工具活动节点定义参与者表达式为$S{Process.Creator}＝$P{id}(谁创建流程谁来处理这个节点)。

然后步骤2013，定义当前活动参与者需要处理的业务单元，例如：请假申请流程，第一个工具活动节点定义一个“填写请假申请单”业务单元，并且为必做。

步骤2014，定义当前活动参与者的流程控制操作。例如：请假申请流程，第一个工具活动节点执行人能够有的流程控制操作为“提交申请单”，供下个节点进行审批。

流程运行过程：

首先，步骤2021，业务人员选择指定的流程定义，创建并启动。例如：选择“请假申请流程”，创建并启动。

步骤2022，业务应用为流程赋相关数据的值。例如：为相关数据users赋个初始值”User_1，User_2”。

然后步骤2023，引擎自动创建人工活动节点。例如：自动创建“请假申请流程”，第一个工具活动节点。

再进行步骤2024，引擎解析当前活动参与者定义，自动将任务分配给当前业务人员。根据定义，如果User_1创建的流程，则由User_1来处理此工具活动节点。

然后进行步骤2025，业务应用根据活动定义获取当前岗位需要处理的业务单元。根据定义，查出必做的“填写请假申请单”业务单元，进行处理。

步骤2026，业务应用根据活动定义获取当前岗位的流程控制操作。根据定义，查出可对流程控制德操作为“提交申请单”，在完成所有的必做业务单元后，执行＂提交申请单＂的操作。

业务人员处理完所有必做业务单元后，进入步骤2027，执行流程控制操作；进入步骤2027，结束人工活动。

然后引擎解析流程定义，如果下个活动节点部位结束节点，引擎自动创建下个活动节点，继续进行步骤2023。

如果下个活动节点为结束节点，流程执行结束。

Claims (6)

1.一种描述人工活动的模型，其特征在于，包括如下三个方面：

谁来做：即通过参与者表达式确定活动的参与者；

做什么：即确定活动的参与者要执行的业务单元；

对流程的控制操作：即完成所述业务单元的处理后，参与者对流程状态的控制要求。

2.根据权利要求1所述的描述人工活动的模型，其特征在于：所述参与者表达式包括如下基本元素：流程变量、系统变量、参与者属性以及逻辑运算符。

3.根据权利要求1所述的描述人工活动的模型，其特征在于：所述业务单元是对业务逻辑分解的最小的执行单元，业务单元分为必做和不必做。

4.根据权利要求1所述的描述人工活动的模型，其特征在于：确定活动参与者还可以通过分配策略来实现，分配策略分为(1)会签，(2)抢任务；

如果分配策略为抢任务，则从多个参与者之间选择一个人来完成所有的业务单元；如果分配策略为会签，则参与者共同完成所有的业务单元。

5.根据权利要求3所述的描述人工活动的模型，其特征在于：所述确定活动的参与者要执行的业务单元是通过如下实现的：

若业务单元为必做，则设置最大执行次数，默认为0，如果次数为0，则完成业务单元的次数不受限制；当大于0时，若执行完成业务单元的方法的次数等于必做次数时，该业务单元的状态自动更换为挂起，即不可再执行；

若为不必做时，该业务单元可以不执行完成业务单元的方法。

6.根据权利要求1所述的描述人工活动的模型，其特征在于：所述对流程的控制操作为：通过流程定义配置人工活动节点允许执行的流程的控制操作，其反映此人工活动节点对流程的控制权限。

Images