flowable实战（十二）flowable 任务办理方式与办理人设置探讨

flowable的办理方式，分为两种：签收模式办理和直接办理。

术语：

Assignee: 任务的受理人，即执行人。它有两种情况（有值,NULL)

Owner: 任务的委托人。

CandidateGroup: 候选用户组

CandidateUser: 候选人

delegateTask: 委派任务/签收的任务

resolveTask:  委派任务的代办，任务的拥有者把任务委派他人来办理，他人办完后，又重新回到任务拥有者，会产生流转记录。

turnTask： 转办任务，只是改变当前任务的办理人而已，不会产生流转记录。

CompleteTask: 完成任务，或叫办结提交下一步。

claimTask：任务签收

一、签收后办理模式

  任务创建后，流程进入一个等待状态，需要用户去签收任务，即接收任务的一个过程。原理就是它的执行实例表act_ru_execution创建了一条记录，但act_ru_task表中是没有创建这个记录，只有签收后act_ru_task才会生成一条任务记录。签收办理人，可以分为：候选人（一人或者多人，之间逗号分开）和候选用户组（一个或者多个组，之间逗号分开）。

   这种模式就是任务的抢占模式，谁先签收，这个任务就归谁。真实的任务其实只有一条，只是还没有在act_ru_task生成。

二、直接办理模式

   任务创建后，直接给了提交到下一个节点，给下一个节点创建任务时，就指定了这个任务的受理人（Assignee_)

三、直接办理任务三种指派人方式：

 (1)xml流程模型中直接设置固定死的用户id或者用户账号，例如：

      

      也可以配置成候选人或者候选组方式。

 (2)任务节点上设置流程变量，这个流程变量的值由上一个节点来设置，例如：

      

 (3)自定义一个监听类，实现TaskListener接口，细节查看如何定义监听器类及配置到流程模型xml中相关章节。

四、候选人和候选组的配置：

有一张数据库表和它有关：

act_ru_identitylink,这个表里有几个字段要理解一下：group_id（候选组时有值），User_id（候选人模式有值 ）,Type(指明是候选人还是候选组），如下：