摘要:但是在后面的使用過程中發(fā)現(xiàn)完全可以在沒有用戶信息的情況下運行,我們可以指派表中根本不存在的用戶或組給一個,然后使用查詢這個。經(jīng)過觀察后發(fā)現(xiàn),的,,信息只是以字符串形式保存在和表中,更進一步證實了我的想法。
在剛接觸流程引擎Activiti的時候誤以為必須得使用它所提供的用戶管理,而一般來說在業(yè)務系統(tǒng)里本身就自帶了一套用戶管理,于是就去尋找同步用戶數(shù)據(jù)到Activiti的ACT_ID_*表中方法,找到了這篇文章。
但是在后面的使用過程中發(fā)現(xiàn)Activiti完全可以在沒有用戶信息的情況下運行,我們可以指派ACT_ID_*表中根本不存在的用戶或組給一個Task,然后使用TaskService查詢這個Task。可以看Activiti論壇的這個回答。
經(jīng)過觀察后發(fā)現(xiàn),Task的Assignee,Candidate Users,Candidate Groups信息只是以字符串形式保存在act_ru_tak和ACT_RU_IDENTITYLINK表中,更進一步證實了我的想法。
不過事情有一些例外,Activiti實際上在查詢Task的時候,在某些情況下還是使用了ACT_ID_*表中的數(shù)據(jù),下面總結(jié)了出來。
taskCandidateOrAssignedtaskService.createTaskQuery().taskCandidateOrAssigned(userId);
當使用taskCandidateOrAssigned做查詢條件時,Activiti會按照以下規(guī)則查找Task:
Assignee匹配
或者*.bpmn中定義的Candidate Users 匹配
或者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會按照以下規(guī)則查找Task:
Assignee匹配。可以從以下SQL看出它查找的邏輯:
select distinct RES.* from ACT_RU_TASK RES WHERE RES.ASSIGNEE_ = ?taskCandidateGroup
taskService.createTaskQuery().taskCandidateGroup(userId);
當使用taskCandidateGroup做查詢條件時,Activiti會按照以下規(guī)則查找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會按照以下規(guī)則查找Task:
先查找用戶所屬的組(用戶所屬用戶組的信息從Activiti的ACT_ID_*表獲取)
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_*表獲取)
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會按照以下規(guī)則查找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會按照以下規(guī)則查找Task:
*.bpmn中定義的owner匹配。可以從以下SQL看出它查找的邏輯:
select distinct RES.* from ACT_RU_TASK RES WHERE RES.OWNER_ = ?
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/64918.html
摘要:此時再次旋轉(zhuǎn)屏幕時,該不會被系統(tǒng)殺死和重建,只會調(diào)用。因此可通過和來判斷是否被重建,并取出數(shù)據(jù)進行恢復。但需要注意的是,在取出數(shù)據(jù)時一定要先判斷是否為空。只有在進程不被掉,正常情況下才會執(zhí)行方法。 目錄介紹 1.0.0.1 說下Activity的生命周期?屏幕旋轉(zhuǎn)時生命周期?異常條件會調(diào)用什么方法? 1.0.0.2 后臺的Activity被系統(tǒng)回收怎么辦?說一下onSaveInsta...
摘要:安裝與測試的流程也是用了的機制而不會受到影響。其他提供自定義類加載器的公有,是不是意味著對于熱修復或者插件化將有官方的支持我們按照開發(fā)者的反饋,將部分合理的常用非接口以新的取代。而熱修復或者插件化皆違反政策,是不容許的。showImg(https://user-gold-cdn.xitu.io/2019/5/17/16ac450a4b6e13b5); Device ID Q: 預裝應用可以獲...
閱讀 2523·2023-04-25 17:27
閱讀 1833·2019-08-30 15:54
閱讀 2376·2019-08-30 13:06
閱讀 2987·2019-08-30 11:04
閱讀 754·2019-08-29 15:30
閱讀 736·2019-08-29 15:16
閱讀 1737·2019-08-26 10:10
閱讀 3609·2019-08-23 17:02