在剛接觸流程引擎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_ = ?