Activiti7.0实战学习(五):用户处理任务后表中数据做了哪些变化？
背景
- 查询出指定某个用户的任务列表
- 根据任务的ID进行任务处理
- 看任务处理后，表中发生了哪些变化？
过程
-
处理任务代码逻辑
-
数据库表变化
-
act_ru_task表
说明：由于sanding已经填写了请假申请单，因此activiti把表中原来那条记录给删除了。又新插入了一条了数据。而这条数据就是部门经理这个负责人进行请假单审批了。而这里字段ASSIGNEE为什么为null，是因为我们在流程实例化的时候，并没有添加具体的某个负责人。测试的时候，可以手动操作数据库去填写即可。 -
act_hi_actinst表
说明：原来这张表有两条数据。2504这条数据的END_TIME是null的, 而当sanding这人负责人(只要有任务都是负责人)填写了请假申请单后，END_TIME字段就有值了。且，又新插入了一条数据5001,这条数据是任务流程图中的第三个环节，刚好一个环节（节点，任务节点）一条行为的历史记录，而且我们依然可以看见它的END_TIME字段依然为null。 -
通过分析sanding处理任务后，得到的结论。那么部门经理处理完任务后，也是同样的效果，继续向后面节点移动（领导审批（leader check））。而当leader check完成后，那么act_hi_actinst表中一定对应着5条记录，每个环节（每个节点）对应一条记录。而act_ru_task一定没有数据了。因为这个流程实例已经完成了。而为什么要删除，就是为了保证表中的数据量小，加快查询速度。
-
变化的不只是这两种表，凡是逻辑上相关联的表，数据都会变化的。但是在实际应用场景中，我们可以选择记录一些重要的信息，一些不重要的记录，就可以丢掉。
-
此操作影响的表有(可能操作不是特别规范，因为构建流程图的时候，是没有参与者，导致有些表其实是没有生成记录的，因此下表的第2条记录和第5条记录就没有数据)
| 表名 | 是否受影响 |
|---|---|
| act_hi_actinst | 是 |
| act_hi_identitylink | 是 |
| act_hi_taskinst | 是 |
| act_ru_execution | 是 |
| act_ru_identitylink | 是 |
| act_ru_task | 是 |
- 部门经理进行任务处理（lisi）这个名称是手动插入到数据的，自定义名称即可。
lisi未处理任务的时候，数据库表情况。
代码查询演示
控制台打印
lisi执行任务，代码逻辑演示
数据库表变化
-
act_ru_task
ASSIGNEE是null, 是因为我在流程定义的时候，未选择参与者，实际应用场景中一定是有的，不然审批没有任何意义。当wangwu去完成任务的时候，我们需要手动把wangwu赋值到ASSIGNEE字段上即可。
这里的结果，跟上文的推测，一模一样。 -
act_hi_actinst
数据变化过程：跟上文分析sanding处理任务后是一样的。也跟推测一模一样的。
- 领导进行任务处理(wangwu)这个名称是手动插入到数据的，自定义名称即可。
wangwu未执行任务时，代码逻辑演示
控制台打印
wangwu未执行任务时，数据库act_ru_task表
wangwu处理任务代码逻辑
wangwu处理任务后数据库表变化
- act_ru_task表（可以看见表中一条数据都没有了）
- act_hi_actinst表（可以看见5条记录）
总结：流程定义图上有5个任务节点，分别是开始，填写申请单，部门经理审批，领导审批，结束。刚好对应5条记录。观察发现开始事件和结束时间的TASK_ID是null 。而这里的ASSIGNEE为什么是null可能跟自己定义流程图有关系。（后续找原因）
多注意字段END_TIME是否为null
小结
- 这节的知识是非常重要的，它告诉我们流程实例随着任务完成后，数据库表中的数据变化，其实就是Activiti的工作过程。
- 理解一个最简单的。那么其他的都差不多了。比如一个任务给多个人处理。一个任务给多人中的其中一人处理。都能去推。
- 推的依据就是流程实例究竟是怎样的？流程实例中的每个节点（每个环节）都是一条记录。而需要当前环节（节点）处理任务的时候，act_ru_task表就对应当前流程实例一条待处理的记录。
- 一旦某个流程实例完成了，act_ru_task对应的这个流程实例的记录将一条也不存在。而act_hi_actinst将对每个环节，也就是每个任务节点都有一条数据。