二、创建模式

创建模式在系统创建工作项时生效，如下图所示，其位于工作项生命周期的创建阶段。

图 5-2

正如上面提到的，工作流系统在执行任务节点时会为其创建相应的工作项，根据情况工作项可以是一个也可以是多个。

创建模式作为流程模型的构成部分在流程设计期指定，通常在任务节点的定义里进行定义，与一个任务关联，其用来限定可执行该任务的资源范围。系统根据创建模式限定的资源范围生成工作项，工作项可以直接分配给人，也可以分配给角色、部门、岗位等。

 

1、直接分配（WRP_01: Direct Distribution）

描述

在设计期直接为任务指定特定的资源，该任务的工作项能够在运行期分配给它。注意，指定的资源可以为多个，如果是多个的话就会生成多个工作项，为每个资源生成一个单独的工作项。该模式实际限制执行该任务的资源范围。

图 5-3

如图5-3所示，任务A在定义时直接指定给员工甲，任务B在定义时直接指定给员工乙，当实际执行任务A和任务B时，将由员工甲和员工乙分别执行。

 

应用

该模式一般应用于流程里的关键路径。同时， 在中小企业里，该模式是应用最多的分配模式，因为人员少，管理扁平，所以每个人的职责都非常清晰。该模式也是执行效率较高的资源模式，因为人和任务直接绑 定，所以不会产生推诿等情况，便于管理也便于追究责任，因为运行情况完全在设计期确定。而随着企业规模的扩大，管理层次的复杂，一个任务往往需要交由特定 的部门、岗位或角色来执行，这样无形中会影响任务执行的效率。

该模式的缺点在于一旦关键人物因为各种原因不能及时处理任务，那么将造成整个流程的挂起等待。

 

实现

最简单的资源模式，设计期确定资源，运行期工作流引擎不需要做额外的工作。

 

2、基于角色的分配（WRP_02: Role-Based Distribution）

描述

在设计期为任务指定一个或多个角色，该任务的工作项能够在运行期分配给这些角色。实际执行该任务时，资源将从属于这些角色的资源中产生。该模式实际限制执行该任务的资源范围。

图 5-4

如图5-4所示，任务A在定义时指定给“开发人员”这一角色，该角色包括了两名员工甲和乙。实际执行任务A时，将由员工甲或乙来执行。

 

应用

企业达到一定规模，就会产生人员的分组，角色是典型的分组方式，将具有相似属性的人员定义为一个特定的角色，这些属性通常与工作的内容相关，例如开发人员、项目经理、总经理等，而角色通常又会与权限产生关联。

将任务分配给角色意味着将会有多个员工可以执行该任务，执行效率相比直接分配会有下降，这也是企业扩大后管理成本增大的一种表现形式。

 

实现

工作流系统内置的组织机构模型需要对角色进行支持。引擎运行期通过角色访问属于该角色的人员。

 

3、延迟分配（WRP_03: Deferred Distribution）

描述

在设计期为任务指定资源的标识，典型的，在工作流系统里，该标识对应于一个数据字段变量，例如userid。即在设计期并不确定资源，资源的确定被延迟至运行期，系统运行期从该数据字段里获取该任务分配的资源。

图 5-5

如图5-5所示，任务B在定义时资源的标识指定为userid，实际执行时，任务A由员工甲执行，其指定了下一任务的执行者为员工乙即设置了userid这一变量为员工乙的id，在任务B实例创建时，它访问userid，发现该变量里是员工乙的id，于是将该任务分配给员工乙。

需要注意的是，根据具体的分配策略，运行期该数据字段不仅可以指定人员，也可以指定角色、部门等。

 

应用

该模式给资源的分配引入了灵活性。资源的确定延迟至运行期，即任务可以根据具体的实际情况再确定执行人。具体实施时，这个指定的数据字段可以通过一系列的规则运算得出。

在国内应用中，该模式被大量应用在人工干预流程中，例如下一任务的执行由上一任务的办理者指定。

 

实现

一般通过工作流变量来包含资源的id。为了区别该id是人员id还是角色id，一般内置特殊变量，例如userid、roleid、groupid等。

 

4、按权限分配（WRP_04: Authorization）

描述

能够指定资源的范围，只有该范围内的资源才具有执行该任务的权限。

图 5-6

如图5-6所示，只有项目经理才有权限对开发人员申请软件的要求进行批准。

 

应用

随着分工的细化，每个人工作内容的不同，必然会产生权限的概念。权限实际代表着对同一件事情，每个人执行工作内容的差别。权限越大能执行的操作越多意味着需要负责的方面越多。

该模式强调通过权限对执行任务的资源加以限定。

 

实现

在大多数的软件系统中，角色不仅仅代表具有相似属性的一组人员，同时其也是最重要的权限概念，人员往往不与权限直接关联，角色将人员与权限两者进行关联。所以，对任务设定权限可以通过指定角色来完成。

 

5、职责分离（WRP_05: Separation of Duties）

描述

在一个流程实例里，能够指定两个任务必须由不同的资源执行。

图 5-7

如图5-7所示，任务A和任务B在设计期被指定不能由相同的资源执行，同时它们都指定分配给经理这个角色。那么在运行期，在一个流程实例里，任务A被分配给了员工甲执行，那么在进行任务B的分配时，尽管员工甲也属于经理，但是将不能由其执行。

 

应用

职责分离，不能既当运动员又当裁判员，不能又当跳水队领队又当全运会裁判长。

典型的报销流程里，一般员工的差旅报销由财务人员核实，但如果某名财务人员需要报销差旅费显然不能由自己审批，需要另外一名具有同样权限的财务人员审核。此时就可以对申请任务和审核任务两个任务节点应用该模式。如下图所示：

图 5-8

 

实现

后续节点进行任务分配时，需要获取与之关联前续节点的分配执行信息。流程定义期，在定义任务节点属性时建立两者的关系。

 

6、流程实例整个处理（WRP_06: Case Handing）

描述

在一个流程实例里，所有的任务都能够分配给同一个资源执行。

图 5-9

如图5-9所示，流程实例中的所有任务都由同一个人执行：任务A、B、C都由员工甲执行。

 

应用

在应用该模式的流程里，通常流程里的任务都 是紧密关联的。流程里的任务往往执行在一个紧密相关的上下文里，如果所有的工作都由一个人执行，那么在其了解该上下文的情况下连贯执行这些任务会具有更高 的效率；而如果执行任务的过程中换人，那么新换的人无疑还需要时间对该流程实例相关的上下文进行熟悉，这样无疑会多付出执行成本。

同一个软件的开发最好由同一拨开发人员完成，如果中途更换开发人员，那么新来的开发人员需要一段时间熟悉该软件，会对开发进度产生影响。同样的道理，在软件上线前增加开发人员不一定会提高开发效率，很多时候甚至作用相反。

 

实现

可以在实现延迟分配模式的情况下实现该模式，即在第一个任务节点初始化设置参与者变量，后续任务全部使用该变量。如下图所示：

图 5-10

 

7、经验获取（WRP_07: Retain Familiar）

描述

在同一个流程实例里，当存在多个资源都能执行某一工作项时，能够将该工作项分配给执行了前某一工作项的同一资源。

图 5-11

如图5-11所示，任务A和任务B在设计期被指定由相同的资源执行，同时它们都指定分配给经理这个角色。那么在运行期，在一个流程实例里，任务A被分配给了员工甲执行，那么在进行任务B的分配时，任务B依旧由员工甲执行。

 

应用

该模式刚好与职责分离模式相反，正如它的名字所暗示的，这些任务之间存在着紧密关联，如果执行了其中一个，那么就会熟悉这些相关联任务的背景上下文，积累一定经验，那么后续任务的执行相对其他人来说会变得容易。提高任务执行的效率。

图 5-12

如图5-12所示，在软件销售的过程中，售前和编写标书是重要的两步，这两个任务最好由同一个人进行处理，因为参与软件售前的人更熟悉客户的实际情况和需求，如果分开由不同的人员执行，那么必然会存在前者与后者的交流成本。

 

实现

后续节点进行任务分配时，需要获取与之关联前续节点的分配执行信息。流程定义期，在定义任务节点属性时建立两者的关系。运行期可以通过参与者变量（工作流变量）建立起运行期关系。

 

8、基于能力的分配（WRP_08: Capability-Based Distribution）

描述

能够基于资源的能力进行工作项的分配，能力作为组织模型的一部分建模为资源的属性。

图 5-13

如图5-13所示，任务A需要交与开发人员执行，同时其对办理该任务的人员能力提出了要求，要求只有熟悉JAVA且工作经验大于2年的开发人员才能执行该任务。这样就缩小了选取资源的范围。

 

应用

人力资源管理中很重要的一点就是要做到人尽 其用，每个人的能力都能得到最大的发挥，其实也就是根据能力将人放置到最合适的工作中去。从这一点看，该模式是对人尽其能的实现。但是如何定义各个人员的 能力，这本身就比较的主观，执行各项工作需要具备的能力也具有主观因素，更何况很多时候能力并不能与表现划上等号，模型是固定的但人是变化的受环境影响 的，所以工具本身就是工具，工具的应用最后还是依赖于人。

 

实现

实现需要两部分：一部分是组织机构对人进行建模时需要包括能力模型；另一部分是流程建模时需要给任务定义执行该任务所需的能力约束，这些约束是一系列的领域特定条件，需要有特定的解析器进行条件的解析。

很多工作流引擎提供有参与者接口，接口返回人员ID列表供给任务分配，从而将这部分工作委派到工作流实施时实现。

 

9、基于历史的分配（WRP_09: History-Based Distribution）

描述

能够基于先前的工作历史决定当前任务的分配。

图 5-14

如图5-14所示，当需要在员工甲和员工乙之间做出选择时，会选择此前执行类似任务时完成最好的员工。需要注意的是，这里的历史不再是限定在同一流程实例的任务执行里，可能是同一流程模型的执行历史，也可能是不同流程模型的执行历史。

考虑历史时，有很多的考虑因素，例如完成类似任务最好的员工、完成类似任务最快的员工、完成类似任务出差错最少的员工等等。这些考虑因素依赖于具体的任务内容和背景。

 

应用

国家篮球队比赛前，主教练会考察各个位置里各个球员的联赛比赛历史情况，其中不仅会考虑出场时间也会考虑各项数据，从而做出选择。

 

实现

同基于能力的分配模式一样，该模式的实现依赖于工作流具体应用的场景，也就是需要到实施阶段结合实际实现。从某一种角度也说明，应用工作流产品时，产品实施阶段也是最重要的步骤，选择工作流产品不仅仅是选择产品也需要考察其背后的实施团队。同时也可见，这些模式在诸如政府OA这些应用中是根本应用不上的。

实现需要两部分：一部分是对用户任务执行历史进行统计分析找出关键的评定因素；另一部分是流程建模时需要给任务定义执行该任务所需的历史因素约束，这些约束同样是一系列的领域特定条件，需要特定的解析器进行解析。

 

10、按组织分配（WRP_10: Organizational Distribution）

描述

能够基于人员在组织机构中的位置以及与其他人员的关系分配工作项。

图 5-15

如图5-15所示，审批任务需要由申请人的部门经理执行，即需要员工甲的部门经理执行。这种情况即基于人员之间的关系分配工作。

基于人员在组织机构中的位置分配即需要在工作流模型里建立起与用户相匹配的组织机构模型，可以将任务分配给部门、角色、临时组、岗位等。

 

应用

应用最为广泛的模式，实际工作中几乎所有的工作都必然和组织机构具有联系。其他模式，如基于历史的分配、基于能力的分配等都是基于该模式之上的扩展，直接分配、基于角色的分配则直接是该模式的简单情况。

 

实现

对该模式的支持实际上是对用户组织机构模型的支持。正如前面所提到的，很难存在一种工作流产品能够支持所有的组织机构模型，但是大部分的产品都会提供一套元模型或扩展机制，需要在实施过程中最大限度的契合客户业务。

 

11、自动执行（WRP_11: Automatic Execution）

描述

任务的执行能够自动完成，不需要人员参与。

图 5-16

如图5-16所示，请假审批后需要将情况通知给申请人，该任务由计算机完成，不需要人的参与，也不会产生工作项。

 

应用

随着自动化水平的提高，越来越多的工作可以交由计算机或相应的机器设备完成。流程中的自动执行节点也会逐渐增加。

 

实现

实际上工作流产品对该模式的支持即是支持各种的企业集成方式，不管是通过Web服务还是消息，工作流需要驱动相应的设备机器或应用系统进行工作并传递给必须的数据。所以也可以看出，随着信息化程度的提高，目前工作流应用越来越趋向于企业集成领域。这也是为什么基于Web服务编排的BPEL会逐渐取代XPDL成为工作流流行标准的原因之一。

http://www.blogjava.net/ronghao 荣浩原创，转载请注明出处：）