Activiti中彻底解决待办事项列表查询复杂、API不友好的设计方案
Activiti中彻底解决待办事项列表查询复杂、API不友好的设计方案
李玉珏 发表于3年前
Activiti中彻底解决待办事项列表查询复杂、API不友好的设计方案
  • 发表于 3年前
  • 阅读 10234
  • 收藏 12
  • 点赞 1
  • 评论 3
摘要: 我们使用工作流引擎,一个非常重要的功能就是获取待办事项列表,在Activiti中,我们可以通过TaskService的相关API进行查询,这些API设计优雅,但是实际使用中往往不够方便,也缺乏灵活性,达不到技术解决方案的要求。本文提供的设计方案,在不改变Activiti既有设计的前提下,解决了待办事项列表查询的方便性、灵活性、通用性,供开发者参考。

       我们使用工作流引擎,一个非常重要的功能就是获取待办事项列表,在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视图再查询这些视图。具体上开发者可以灵活处理,本文不再展开。

共有 人打赏支持
李玉珏
粉丝 198
博文 43
码字总数 64437
评论 (3)
启明89
感谢大神的分享,这个视图非常好,我还想请教一下在TaskListener实现类的notify方法中如何获取当前登录用户的信息呢?
李玉珏

引用来自“启明89”的评论

感谢大神的分享,这个视图非常好,我还想请教一下在TaskListener实现类的notify方法中如何获取当前登录用户的信息呢?

我们登录用户信息是放到线程局部变量中的
dizh
学习了~
×
李玉珏
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: