关于java:Flowable-按角色分配任务

4次阅读

共计 4292 个字符，预计需要花费 11 分钟才能阅读完成。

@[toc]
后面松哥和大家分享的都是给 UserTask 设置解决人或者是候选用户，不过小伙伴们也晓得，在咱们为 UserTask 设置解决人的时候，除了设置单个的解决人，也能够设置 Group，就是某一个用户组内的所有用户都能够解决该 Task。

在 Flowable 中应用 Group 去归类某一类用户，然而这个实际上相似于咱们在本人零碎中平时所用的角色 Role。也就是说，咱们能够依照角色去给每一个 UserTask 设置解决人。

接下来松哥就来和小伙伴们聊一聊这里的一些细节。

首先咱们先来看下用户组的一些基本操作。

组的属性相对来说少一些，增加形式和 user 比拟像：

@Test
void test09() {GroupEntityImpl g = new GroupEntityImpl();
    g.setName("组长");
    g.setId("leader");
    g.setRevision(0);
    identityService.saveGroup(g);
}

增加之后，组的信息保留在 ACT_ID_GROUP 表中，如下图：

组创立好之后，接下来还要给组增加用户，增加形式如下：

identityService.createMembership("zhangsan", "leader");
identityService.createMembership("lisi", "leader");

这就是设置 zhangsan 和 lisi 是组长（留神用户和组的关联关系表中有外键，所以须要确保两个参数都是实在存在的）。

增加了关联关系之后，咱们再去查看 ACT_ID_MEMBERSHIP 表，如下：

掉用如下办法能够删除关联关系：

identityService.deleteMembership("zhangsan","leader");

如下，将 id 为 leader 的组名更新为主管，如下：

Group g = identityService.createGroupQuery().groupId("leader").singleResult();
g.setName("主管");
identityService.saveGroup(g);

删除组形式如下：

identityService.deleteGroup("leader");

删除组的同时，也会删除掉组和用户之间的关联关系，不过不必放心用户被删除。

能够依据 id 或者 name 或者组员信息等去查问组：

// 依据 id 查问组信息
Group g1 = identityService.createGroupQuery().groupId("leader").singleResult();
System.out.println("g1.getName() =" + g1.getName());
// 依据 name 查问组信息
Group g2 = identityService.createGroupQuery().groupName("组长").singleResult();
System.out.println("g2.getId() =" + g2.getId());
// 依据用户查问组信息（组里蕴含该用户）List<Group> list = identityService.createGroupQuery().groupMember("zhangsan").list();
for (Group group : list) {System.out.println("group.getName() =" + group.getName());
}

在咱们绘制流程图的时候，咱们能够为 UserTask 设置一个候选组，形式如下：

从这个中央大家也能够看到，后抉择是能够给多个的。

好了，设置实现后，咱们下载流程图的 XML 文件，而后来看下这个中央不同凡响之处：

<process id="demo01" name="测试流程" isExecutable="true">
  <documentation> 测试流程 </documentation>
  <startEvent id="startEvent1" flowable:formFieldValidation="true"></startEvent>
  <userTask id="sid-F2F3C468-79B9-447B-943F-7CD18CE9BECF" flowable:candidateGroups="leader" flowable:formFieldValidation="true"></userTask>
  <sequenceFlow id="sid-79C79920-2AD8-48FE-A59C-CC4D23C1895D" sourceRef="startEvent1" targetRef="sid-F2F3C468-79B9-447B-943F-7CD18CE9BECF"></sequenceFlow>
  <endEvent id="sid-2236991E-3643-4590-9001-E22C256CA584"></endEvent>
  <sequenceFlow id="sid-51105EB7-07F6-4190-9B2E-8F1F20A307D1" sourceRef="sid-F2F3C468-79B9-447B-943F-7CD18CE9BECF" targetRef="sid-2236991E-3643-4590-9001-E22C256CA584"></sequenceFlow>
</process>

小伙伴们看到，flowable:candidateGroups="leader" 就示意这个工作由一个候选用户组来解决，如果有多个候选的用户组，则不同用户组之间用 , 隔开。

当然，这是硬编码。如果想像候选用户一样，通过动静变量来传递用户组名称也是能够的，具体做法像上面这样：

这样，最终生成的 XML 文件则相似这样：flowable:candidateGroups="${g1}"。

接下来，咱们部署并启动一个流程，具体的部署和启动形式松哥在之前的文章中都曾经和大家介绍过了，这里简略看下办法就行了：


@Test
void test01() {Map<String, Object> variables = new HashMap<>();
    variables.put("g1", "leader");
    ProcessInstance pi = runtimeService.startProcessInstanceByKey("demo01",variables);
    logger.info("id:{},activityId:{}", pi.getId(), pi.getActivityId());
}

这个就是流程启动的过程，留神启动的时候加了参数，用来形容下一个 UserTask 的解决组。

启动胜利之后，咱们能够在 ACT_RU_IDENTITYLINK 表中查看到用户组和 UserTask 之间的关系：

接下来咱们能够依照查问候选人工作的形式，查问 zhangsan 须要实现的工作，如下：

@Test
void test19() {List<Task> list = taskService.createTaskQuery().taskCandidateUser("zhangsan").list();
    for (Task task : list) {logger.info("name:{},createTime:{}", task.getName(), task.getCreateTime());
    }
}

这个查问的外部实现，咱们能够拆分为两步：

查问进去 zhangsan 是属于哪个 group，这个查问执行的 SQL 如下：

SELECT RES.* from ACT_ID_GROUP RES WHERE exists(select 1 from ACT_ID_MEMBERSHIP M where M.GROUP_ID_ = RES.ID_ and M.USER_ID_ = ?) order by RES.ID_ asc

这个查问中有一个参数，参数的值就是 zhangsan，下面这个 SQL 能够查问进去 zhangsan 这个用户属于 leader 这个分组，在接下来的查问中，会 zhangsan 和 leader 两个参数都会用到。

查问 zhangsan 或者 leader 的工作，执行 SQL 如下：

SELECT RES.* from ACT_RU_TASK RES WHERE RES.ASSIGNEE_ is null and exists(select LINK.ID_ from ACT_RU_IDENTITYLINK LINK where LINK.TYPE_ = 'candidate' and LINK.TASK_ID_ = RES.ID_ and ( LINK.USER_ID_ = ? or ( LINK.GROUP_ID_ IN ( ?) ) ) ) order by RES.ID_ asc

能够看到，这个查问里，有两个参数了，两个参数的值别离是 zhangsan 和 leader。

也就是说，尽管咱们这里代码写的是依照 zhangsan 去查问，实际上查问的是 zhangsan 所属的用户组的 Task（这个逻辑也好了解，因为 zhangsan 所属的用户组的 Task 实际上也就是 zhangsan 的 Task）。

当然，咱们也能够间接依照 group 去查问，如下：

@Test
void test20() {List<Task> list = taskService.createTaskQuery().taskCandidateGroup("leader").list();
    for (Task task : list) {logger.info("name:{},createTime:{}", task.getName(), task.getCreateTime());
    }
}

这个查问原理跟下面的差不多，不过省事的是，这里一条 SQL 就搞定了（不须要依据用户名查问用户所属的分组了），如下：

SELECT RES.* from ACT_RU_TASK RES WHERE RES.ASSIGNEE_ is null and exists(select LINK.ID_ from ACT_RU_IDENTITYLINK LINK where LINK.TYPE_ = 'candidate' and LINK.TASK_ID_ = RES.ID_ and ( ( LINK.GROUP_ID_ IN ( ?) ) ) ) order by RES.ID_ asc

好啦，当这些工作查问进去后，接下来该如何执行，就和后面介绍的内容一样了，我这里就不再赘述了。

正文完