工作流activiti用户信息相关

阅读文本大概需要3分钟。

在刚接触流程引擎Activiti的时候误以为必须得使用它所提供的用户管理，而一般来说在业务系统里本身就自带了一套用户管理，于是就去寻找同步用户数据到Activiti的ACT_ID_*表中方法，找到

http://www.kafeitu.me/activiti/2012/04/23/synchronize-or-redesign-user-and-role-for-activiti.html

但是在后面的使用过程中发现Activiti完全可以在没有用户信息的情况下运行，我们可以指派ACT_ID_*表中根本不存在的用户或组给一个Task，然后使用TaskService查询这个Task。可以看Activiti论坛

https://community.alfresco.com/thread/217729-separating-out-user-management#comment-8702

经过观察后发现，Task的Assignee，Candidate Users，Candidate Groups信息只是以字符串形式保存在act_ru_tak和ACT_RU_IDENTITYLINK表中，更进一步证实了我的想法。

不过事情有一些例外，Activiti实际上在查询Task的时候，在某些情况下还是使用了ACT_ID_*表中的数据，下面总结了出来。

taskCandidateOrAssigned

taskService.createTaskQuery().taskCandidateOrAssigned(userId);

当使用taskCandidateOrAssigned做查询条件时，Activiti会按照以下规则查找Task：

0x01、Assignee匹配

0x02、或者*.bpmn中定义的Candidate Users 匹配

0x03、或者Candidate Group 匹配（用户所属用户组的信息从Activiti的ACT_ID_*表获取）

可以从以下SQL看出它查找的逻辑：

select distinct RES.* from ACT_RU_TASK RES
left join ACT_RU_IDENTITYLINK I on I.TASK_ID_ = RES.ID_
WHERE (
  RES.ASSIGNEE_ = ?
  or (
    RES.ASSIGNEE_ is null
    and (
      I.USER_ID_ = ?
      or
      I.GROUP_ID_ IN (
        select g.GROUP_ID_ from ACT_ID_MEMBERSHIP g where g.USER_ID_ = ?
      )
    )
  )
)

taskAssignee

taskService.createTaskQuery().taskAssignee(userId);

当使用taskAssignee做查询条件时，Activiti会按照以下规则查找Task：

0x01、Assignee匹配。可以从以下SQL看出它查找的逻辑：

select distinct RES.* from ACT_RU_TASK RES WHERE RES.ASSIGNEE_ = ?

taskCandidateGroup

taskService.createTaskQuery().taskCandidateGroup(userId);

当使用taskCandidateGroup做查询条件时，Activiti会按照以下规则查找Task：

*.bpmn中定义的Candidate Groups匹配。可以从以下SQL看出它查找的逻辑：

select distinct RES.* from ACT_RU_TASK RES
inner join ACT_RU_IDENTITYLINK I on I.TASK_ID_ = RES.ID_
WHERE RES.ASSIGNEE_ is null
and I.TYPE_ = 'candidate'
and ( I.GROUP_ID_ IN ( ? ) )

taskCandidateUser

taskService.createTaskQuery().taskCandidateUser(userId);

当使用taskCandidateUser做查询条件时，Activiti会按照以下规则查找Task：

0x01、先查找用户所属的组（用户所属用户组的信息从Activiti的ACT_ID_*表获取）

select g.* from ACT_ID_GROUP g, ACT_ID_MEMBERSHIP membership
where g.ID_ = membership.GROUP_ID_
and membership.USER_ID_ = ?

如果找到了用户组信息，那么

（1）*.bpmn中定义的Candidate Users 匹配

（2）或者Candidate Group 匹配（用户所属用户组的信息从Activiti的ACT_ID_*表获取）

select distinct RES.* from ACT_RU_TASK RES
inner join ACT_RU_IDENTITYLINK I on I.TASK_ID_ = RES.ID_
WHERE RES.ASSIGNEE_ is null
and I.TYPE_ = 'candidate'
and ( I.USER_ID_ = ? or I.GROUP_ID_ IN ( ? , ? ) )

如果找不到用户所属的组，那么和*.bpmn中定义的Candidate Users 匹配

select distinct RES.* from ACT_RU_TASK RES
inner join ACT_RU_IDENTITYLINK I on I.TASK_ID_ = RES.ID_
WHERE RES.ASSIGNEE_ is null
and I.TYPE_ = 'candidate'
and ( I.USER_ID_ = ? )

taskCandidateGroupIn

taskService.createTaskQuery().taskCandidateGroupIn(groups);

当使用taskOwner做查询条件时，Activiti会按照以下规则查找Task：

*.bpmn中定义的Candidate Groups匹配（匹配一个就行）。可以从以下SQL看出它查找的逻辑：

select distinct RES.* from ACT_RU_TASK RES
inner join ACT_RU_IDENTITYLINK I on I.TASK_ID_ = RES.ID_
WHERE RES.ASSIGNEE_ is null
and I.TYPE_ = 'candidate'
and ( I.GROUP_ID_ IN ( ? , ? ) )

taskOwner

taskService.createTaskQuery().taskOwner(userId);

当使用taskOwner做查询条件时，Activiti会按照以下规则查找Task：

*.bpmn中定义的owner匹配。可以从以下SQL看出它查找的逻辑：

select distinct RES.* from ACT_RU_TASK RES
WHERE RES.OWNER_ = ?

☆

往期精彩

☆

01 漫谈发版哪些事，好课程推荐

02 Linux的常用最危险的命令

03 精讲Spring Boot—入门+进阶+实例

04 优秀的Java程序员必须了解的GC哪些

05 互联网支付系统整体架构详解

关注我

每天进步一点点

很干！在看吗？☟