摘要：但是在后面的使用過程中發(fā)現(xiàn)完全可以在沒有用戶信息的情況下運(yùn)行，我們可以指派表中根本不存在的用戶或組給一個(gè)，然后使用查詢這個(gè)。經(jīng)過觀察后發(fā)現(xiàn)，的，，信息只是以字符串形式保存在和表中，更進(jìn)一步證實(shí)了我的想法。

在剛接觸流程引擎Activiti的時(shí)候誤以為必須得使用它所提供的用戶管理，而一般來說在業(yè)務(wù)系統(tǒng)里本身就自帶了一套用戶管理，于是就去尋找同步用戶數(shù)據(jù)到Activiti的ACT_ID_*表中方法，找到了這篇文章。

但是在后面的使用過程中發(fā)現(xiàn)Activiti完全可以在沒有用戶信息的情況下運(yùn)行，我們可以指派ACT_ID_*表中根本不存在的用戶或組給一個(gè)Task，然后使用TaskService查詢這個(gè)Task。可以看Activiti論壇的這個(gè)回答。

經(jīng)過觀察后發(fā)現(xiàn)，Task的Assignee，Candidate Users，Candidate Groups信息只是以字符串形式保存在act_ru_tak和ACT_RU_IDENTITYLINK表中，更進(jìn)一步證實(shí)了我的想法。

不過事情有一些例外，Activiti實(shí)際上在查詢Task的時(shí)候，在某些情況下還是使用了ACT_ID_*表中的數(shù)據(jù)，下面總結(jié)了出來。

taskService.createTaskQuery().taskCandidateOrAssigned(userId);

當(dāng)使用taskCandidateOrAssigned做查詢條件時(shí)，Activiti會(huì)按照以下規(guī)則查找Task：

Assignee匹配

或者*.bpmn中定義的Candidate Users 匹配

或者Candidate Group 匹配（用戶所屬用戶組的信息從Activiti的ACT_ID_*表獲?。?/p>

可以從以下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_ = ?
      )
    )
  )
)

taskService.createTaskQuery().taskAssignee(userId);

當(dāng)使用taskAssignee做查詢條件時(shí)，Activiti會(huì)按照以下規(guī)則查找Task：

Assignee匹配?？梢詮囊韵耂QL看出它查找的邏輯：

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

taskService.createTaskQuery().taskCandidateGroup(userId);

當(dāng)使用taskCandidateGroup做查詢條件時(shí)，Activiti會(huì)按照以下規(guī)則查找Task：

*.bpmn中定義的Candidate Groups匹配?？梢詮囊韵耂QL看出它查找的邏輯：

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 ( ? ) )

taskService.createTaskQuery().taskCandidateUser(userId);

當(dāng)使用taskCandidateUser做查詢條件時(shí)，Activiti會(huì)按照以下規(guī)則查找Task：

先查找用戶所屬的組（用戶所屬用戶組的信息從Activiti的ACT_ID_*表獲?。?/p>

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

如果找到了用戶組信息，那么

*.bpmn中定義的Candidate Users 匹配

或者Candidate Group 匹配（用戶所屬用戶組的信息從Activiti的ACT_ID_*表獲?。?/p>

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_ = ? )

taskService.createTaskQuery().taskCandidateGroupIn(groups);

當(dāng)使用taskOwner做查詢條件時(shí)，Activiti會(huì)按照以下規(guī)則查找Task：

*.bpmn中定義的Candidate Groups匹配（匹配一個(gè)就行）。可以從以下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 ( ? , ? ) )

taskService.createTaskQuery().taskOwner(userId);

當(dāng)使用taskOwner做查詢條件時(shí)，Activiti會(huì)按照以下規(guī)則查找Task：

*.bpmn中定義的owner匹配?？梢詮囊韵耂QL看出它查找的邏輯：

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