mysql待办事项表名_Activiti中彻底解决待办事项列表查询复杂、API不友好的设计方案...

标签:

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

标签:

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值