加签

加签是指当前节点审批完后需要额外再加一个审批人进行审批,额外加的审批用户审批完后流程流转到下一节点。比如正常审批流程为A->B->C,如果B执行了加签动作,那么流程就变为A->B-->D-->C,节点D就是加进来的。

医学上有个万能药叫做安慰剂,没有任何药物作用,可能就是一颗糖果,但患者并不知道,但因患者对医生信任、患者叫自我暗示以及对某种药物疗效的期望等而起到镇痛、镇蘸或缓解症状的作用。为什么提到这个呢,因为加签的方案就是一个安慰剂方案,用户感知到加签是从审批历史里感知的,在做加签操作时,审批历史里面记录了加签的动作,但是后台执行了重新分配(reassign)的操作将当前流程重新分配给另外一个人,达到加签的效果,所以加签就一行代码

taskService.setAssignee(task.getTaskId(), user);

这样可能会有以问题

流程图无法体现加签,因为并没有新的节点产生

如果你的系统做好了对activiti进行改造的准备,那么标准的activiti流程图是远远满足不了你的需求的,你需要额外的方案记录审批历史绘制流程图。

征询

之所以把加签和征询放在一起讲,是因为加签篇幅不够,索性就放到一起。征询是指,你对当前的流程不是很清楚,你需要将流程转发给另外一个人需要另外一个人给你指导,另外一个人审批完后流程回到你这里,你根据他的审批意见进行审批。简单说,如果正常的审批流程为A->B->C,如果B执行了征询操作,那么流程就变为了A->B-->D-->B->C,征询和加签的区别就在于,征询会回到发起征询的节点,加签不会。

征询就是两次的重新分配,怎么说呢

1. B重新分配给D

2. D重新分配给B

两次的reassign操作就可以实现征询,要解决的问题就是怎么协调好这两次重新分配。

1. B执行征询操作时,通过变量标记征询动作,并将征询人B的信息(主要是账号)保存在变量中

2. D执行回复操作时(流程变为征询后,被征询人只有回复的权限),从变量中取出B的账号,重新将流程分配给B

3. B执行正常的审批操作,流程正常流转。

B执行征询操作

/**
 * 征询
 *
 * @param context
 * @param task
 * @param users
 * @param user
 * @return
 */
@Override
public TaskResponse inquire(TaskResponse task, List<String> users, String user) {
    Map<String, Object> taskParams = new HashMap<>();
    taskParams.put("outcome", "inquire");
    taskParams.put("approveUser", user);
    
    //执行重新分配操作
    taskService.setAssignee(task.getTaskId(), users.get(0));
    //标识状态为征询,需要记录在本地变量中
    taskService.setVariableLocal(task.getTaskId(), "status", "inquire");
    //记录征询人信息
    taskService.setVariableLocal(task.getTaskId(), "originUser", user);
    Task t = taskService.createTaskQuery()
            .taskId(task.getTaskId())
            .singleResult();
    String instanceId = t.getProcessInstanceId();
    return this.taskResponse(t, instanceId);
}

D执行回复操作

/**
 * 征询
 *
 * @param context
 * @param task
 * @param toUser
 * @param user
 * @return
 */
@Override
public TaskResponse reply(BPMContextInfo context, TaskResponse task, String toUser, String user) {
    if (toUser == null) {
        toUser = (String) taskService.getVariableLocal(task.getTaskId(), "originUser");
    }
    Map<String, Object> taskParams = new HashMap<>();
    taskParams.put("outcome", "reply");
    taskParams.put("approveUser", user);
    
     //执行重新分配操作
    taskService.setAssignee(task.getTaskId(), toUser);
    taskService.removeVariable(task.getTaskId(), "status");
    taskService.removeVariable(task.getTaskId(), "originUser");
    Task t = taskService.createTaskQuery()
            .taskId(task.getTaskId())
            .singleResult();
    String instanceId = t.getProcessInstanceId();
    return this.taskResponse(t, instanceId);
}

通过两次reassign的配合实现征询操作。

结束语

activiti方面的技术通过十篇的文档已经介绍完,如果你准备用activiti搭建一个流程平台的话,这十篇文档会给你很多参考。

, ,
Trackback

4 comments untill now

  1. 你这个征询的测试让我看不明白,能不能给点完整的,可以上手测试看效果的代码,总感觉你这两块代码不完整

  2. 后面的代码涉及到项目核心代码,只有在文章中贴出一部分,我到时重新整理一份

  3. 你好 请问多人征询怎么实现呢?

  4. 多人征询就和多人审批一样,直接分配给多人就行了

Add your comment now