原文链接:https://blog.csdn.net/zhongzk69/article/details/91489038
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或者用户账号,例如:
<userTask id="usertask1" name="审批" flowable:assignee="userId2"></userTask>
也可以配置成候选人或者候选组方式。
(2)任务节点上设置流程变量,这个流程变量的值由上一个节点来设置,例如:
<userTask id="usertask1" name="审批" flowable:assignee="#{userId}"></userTask>
(3)自定义一个监听类,实现TaskListener接口,细节查看如何定义监听器类及配置到流程模型xml中相关章节。
四、候选人和候选组的配置:
有一张数据库表和它有关:
act_ru_identitylink,这个表里有几个字段要理解一下:group_id(候选组时有值),User_id(候选人模式有值 ),Type(指明是候选人还是候选组),如下:
版权声明:本文为CSDN博主「热水钟」的原创文章,遵循CC 4.0 by-sa版权协议
原文链接:https://blog.csdn.net/zhongzk69/article/details/91489038