5.Task-任务处理操作:
在继续任务处理的相关操作之前,我们先来简单认识一下BPMN文件的相关属性信息
首先我们先看整体的BPMN文件,红色框框选中的就是整个流程的ID,但是在数据库中显示的话会是以Key的形式展示
接着我们再来看看任务处理节点
主要有两个是我们需要注意的,一个就是Name就是直接定义任务节点处理的业务,另外一个就是Assignee就是直接定义任务节点的处理人.
了解完这些最基本的BPMN文件的概念之后,我们再来了解一下Task在数据库中主要操作的两个表分别是act_ru_task和act_ru_identitylink这两张表.
act_ru_task主要是存放我们的任务节点的信息
act_ru_identitylink主要就是存放我们关于任务节点中执行人的相关信息
了解完上面这些概念之后,我们就能继续我们关于Task的操作了.
任务节点其实是和流程实例相关的!!!
想想我们创建完流程实例之后,流程实例最开始的那个任务节点是不是就按理就已经创建完毕了,相应的如果我们将某个流程实例中的所有任务节点都已经执行完毕的话,那么这个流程实例是不是就相应的执行完毕了呢?
这些问题我们在下面的操作过程中都会以实例来验证!!!
那么我们先来验证第一点,创建完相应的流程实例之后,相应的最开始的任务节点是否会自动产生呢?
首先先看一下我们本次使用的BPMN文件
5.1-Task-任务节点查询操作:
我们可以看到我们创建完流程实例时候,流程实例中最开始的任务节点就已经生成了,那么显然我们关于第一点的证明就已经完毕了.
此时我们已经有任务节点了,那么这时候我们在去数据库里面看看我们之前将的那两张表的数据发生看什么样的变化吧
我们先来看看act_ru_task表:
我们可以看到该任务节点的相关信息都已经记录到该表了
我们再来看看act_ru_identitylink表:
可以看执行者的信息也已经添加进来了.
接下来我们在仔细讲一下任务节点的查询操作
5.1.1-查询所有任务节点的信息 :
我们上面的查询操作是查询的所有任务节点的状态
@Autowired private TaskService taskService; @Test public void getTasks(){ List<Task>tasks=taskService.createTaskQuery().list(); for(Task task:tasks){ System.out.println("ID:"+task.getId()); System.out.println("Assignee:"+task.getAssignee()); } }
显然这种操作只能是管理员才能拥有的操作,所以我们应该为一般的人员设置只能查询自己当前任务节点的方法,那么 就到下面的方法了
5.1.2-查询该用户下的任务节点:
@Test public void getTaskByAssignee(){ List<Task>tasks=taskService.createTaskQuery().taskAssignee("wukong").list(); for(Task task:tasks){ System.out.println("ID:"+task.getId()); System.out.println("Assignee:"+task.getAssignee()); } }
这样我们就能查找特定执行下的任务了
那么我们分别查询一下bajie和wukong两者的下的任务节点:
可以看到bajie的任务节点已经存在了
当我们去在查询一下wukong的任务节点的时候,其实大家也能够猜到了,很明显wukong的任务节点是还没有生成的:
可以看到wukong下面的确什么任务节点都没有,其实我们想一下,wukong所属的任务节点是在bajie的任务节点之下的,那么显然是不是bajie的任务节点执行完毕之后,wukong的任务节点就能够看到了呢?说干就干.那么我们接下来就来看看执行任务节点
5.2-Task-任务节点完成操作:
//执行任务 @Test public void completeTask(){ taskService.complete("13909b7d-3e72-11eb-beee-3c58c24c1a1b"); System.out.println("该任务节点已经处理完毕"); }
这里我们 是通过TaskId来执行任务的
我们运行一下代码
可以看到已经成功运行了,这时候我们再来重新看一下两张数据表里面的是数据发生了什么样的变化吧
act_ru_task:
可以看到任务已经流转到下面一个流程了,并且之前一个bajie的任务节点已经消失了,只剩下了wukong的审批请假的任务节点了
那么显然我们现在再去查找bajie和wuykong所属的任务节点的时候,大家应该也能够有猜到相应的结果了:
act_ru_identitylink:
可以看到执行人这张表里面则不是像act_ru_task表一样直接删除之前的在执行人信息,还是不断添加整个流程里面的执行人信息的
看完上面两个表的数据之后,我们尝试将整个流程的任务节点都执行完,看看最后任务节点以及流程实例最后会是什么样的?
可以看到当我们将所有的任务节点全部执行完毕之后,相应的流程实例也会自动的消失掉,这样的确是符合正常的流程的,完成之后自动消失.
接着我们再来看看我们两张表中的数据发生了怎么样的变化:
act_ru_task:
act_ru_identitylink:
可以看到这两张表中关于该流程实例的所有任务节点以及执行人的信息全部都已经删除了.
虽然这两张表里面的数据都已经删除了,但是Activiti7为我们提供了另外一张表来帮我们存储我们的历史数据,这张表我们之后也会提到,这里先不讲.这样假如我们有溯源的功能的话,我们也是可以实现的,这样看来,这种流程执行完毕就把相应的任务节点删除掉,只保留当前存在且待执行的任务节点的确是合理的,毕竟任务节点到后面只会越来越多,如果不进行这种类似的操作的话,那么后续查询的速度就会越来越满,严重影响用户体验.
5.3-Task-任务节点拾取,退还,交办操作:
上面我们的任务都是单线的,意思就是一条线走到底的,但是我们有时候的任务可能是这样的:
那么显然我们的任务节点就会出现我在标题中写的那三种操作方式,拾取,退还,交办操作.
我们还是先来看看我们这次定义的BPMN文件是什么样的:
还是老样子,先部署流程–>创建流程实例–>执行候选任务的各项操作
我们创建完了,接下来我们分别查询一下wukong,bajie,shaseng下面是否有任务节点:
可以看到我们分别查询了wukong,bajie,shaseng下面的任务节点,发现都是没有相应的任务的.显然这也刚好符合候选任务的定义的,的确是需要我们主动分配.
那么接下来我们就开始候选任务中的第一项操作
