標簽：

我們使用工作流引擎，一個非常重要的功能就是獲取待辦事項列表，在Activiti中，我們可以通過TaskService的相關API進行查詢，這些API設計優雅，但是實際使用中往往不夠方便，也缺乏靈活性，達不到技術解決方案的要求，主要有如下幾個問題：

1.多數情況無法通過調用一個API滿足需求，這時一個現實問題就是需要對結果集進行合并然后排序，這樣就顯得比較麻煩；

2.和項目業務表關聯困難；

3.Activiti中相關查詢返回的是Activiti定義的實體，這些實體包含的信息可能不夠；

4.Activiti中的實體，可能和項目中的對象關系映射(ORM)沖突；

鑒于上述原因，在一些大規模的項目中，Activiti提供的查詢API，實際使用價值不大，我們需要另外尋找解決方案。在Activiti的查詢API中，也提供原始SQL的查詢接口，但是大量使用后，會發現代碼不夠優雅，維護困難。這個問題其實從開發者角度，查詢時用用戶的id，用最簡單的SQL查詢出來所有想要的信息是最理想的。

分析上述缺點和需求后，我們認為通過API方式進行查詢的話，總是有各種缺陷，因此把目標放在數據庫上，如果能通過定義視圖的方式解決問題，那么將徹底解決查詢的方便性、靈活性、通用性問題。

經過分析Activiti的數據庫表，我們發現并不復雜，和待辦事項有關系的表，包括ACT_RU_TASK、ACT_RU_IDENTITYLINK，ACT_RU_TASK中存儲了任務相關信息，ACT_RU_IDENTITYLINK中存儲了候選組和候選人信息，這里面一個比較重要的問題就是，Activiti中的候選組、候選人如何跟系統中的用戶、組織、角色對應的問題，本文提供的解決方案，假定系統中有一張名為SYS_ROLE_USER的表，該表中存儲了角色和用戶的對應關系，并且Activiti中的候選組和角色是同一個概念，開發者的系統中具體是什么情況，需要開發者舉一反三，本文僅提供一個設計思路。

在Activiti中，對于一個節點，可分為受托人，候選人和候選組三種情況，后兩種可以設置多個，用逗號分隔，對應到數據庫中，會被拆分為ACT_RU_IDENTITYLINK的多條記錄，這些我們都需要考慮，細節上可以通過UNION實現，下面是樣例代碼，該代碼基于Oracle數據庫，其他數據庫的版本，稍后會說明。

CREATE?VIEW?V_TASKLIST?AS

SELECT?A.ID_?AS?TASK_ID,

A.PROC_INST_ID_?PROC_INST_ID,

A.TASK_DEF_KEY_?AS?ACT_ID,

A.NAME_?AS?ACT_NAME,

A.ASSIGNEE_?AS?ASSIGNEE,

A.DELEGATION_?AS?DELEGATION_ID,

A.DESCRIPTION_?AS?DESCRIPTION,

TO_CHAR(A.CREATE_TIME_,?‘YYYY-MM-DD?HH24:MI:SS‘)?AS?CREATE_TIME,

TO_CHAR(A.DUE_DATE_,‘YYYY-MM-DD?HH24:MI:SS‘)?AS?DUE_DATE,

I.USER_ID?CANDIDATE

FROM?ACT_RU_TASK?A

LEFT?JOIN?(SELECT?DISTINCT?*?FROM?(SELECT?TASK_ID_,?TO_CHAR(USER_ID_)?USER_ID

FROM?ACT_RU_IDENTITYLINK?I,?ACT_RU_TASK?T

WHERE?TASK_ID_?IS?NOT?NULL

AND?USER_ID_?IS?NOT?NULL

AND?I.TASK_ID_?=?T.ID_

AND?T.ASSIGNEE_?IS?NULL

AND?TYPE_?=?‘candidate‘

UNION

SELECT?TASK_ID_,?R.USER_ID

FROM?ACT_RU_IDENTITYLINK?I,SYS_ROLE_USER?R,ACT_RU_TASK?T

WHERE?I.TASK_ID_?IS?NOT?NULL

AND?I.GROUP_ID_?IS?NOT?NULL

AND?I.TASK_ID_?=?T.ID_

AND?T.ASSIGNEE_?IS?NULL

AND?TYPE_?=?‘candidate‘

AND?I.GROUP_ID_?=?R.ROLE_ID)U)?I--候選組和業務上的角色用戶表關聯

ON?A.ID_?=?I.TASK_ID_

這個視圖比較簡單，主要查詢了任務信息，如果還需要其他信息，比如和流程實例、流程定義等，可以自行增加其他的表關聯，比如要和業務表關聯需要一個很重要的字段就是BUSINESS_KEY_,這個和ACT_RU_EXECUTION表關聯即可。

這個視圖定義好之后，代辦查詢可以用如下的更簡潔的SQL實現：

SELECT?*?FROM?V_TASKLIST?WHERE?ASSIGNEE?=?：userId?OR?CANDIDATE?=?：userId

這樣的話，和業務表關聯也非常的方便，也不會受到API的限制，也不涉及和系統的ORM兼容的問題，基本上想查詢什么信息就能用一個簡單的SQL查詢到什么信息，基本可以作為一個通用的解決方案了。

上述例子僅提供了Oracle的代碼，對于兼容多數據庫的設計，比較麻煩，各種數據庫都對視圖的創建做了較多的限制，比如SQLServer不能在SQL中寫ORDER BY，MySQL中FROM字句不能嵌套子查詢，以及不同數據庫字段類型定義不同等，在我們的解決方案中，基本上就是把上述SQL做了拆分，定義了若干非常小的視圖，然后V_TASKLIST視圖再查詢這些視圖。具體上開發者可以靈活處理，本文不再展開。

標簽：

總結

以上是生活随笔為你收集整理的mysql待办事项表名_Activiti中彻底解决待办事项列表查询复杂、API不友好的设计方案...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。