5.3.1.任务配置页签
任务配置页签是人工任务节点中最为重要的属性配置页签,在这个配置页签当中,可以配置当前节点生成任务的名称、处理任务的URL、是否为会签任务、任务处理人等信息。如下图所示。
我们先从第一部分开始,第一部分是让我们配置当前人工任务节点生成任务时的一些基本属性的,这其中,任务名称与URL两个属性我们在开始节点已经有过介绍,这里的这两个属性与开始节点任务配置的那两个完成相同,第三个属性是任务类型,从下拉框中可以看到,任务类型有两种,分别是普通任务与会签任务,默认就是普通任务。
当我们把任务类型改为会签任务是,第二部分灰掉的会签任务完成规则就变的可用,这就表示当前人工任务节点在生成任务时将以会签任务的形式创建,这里需要指出的时,如果把任务类型改为会签任务,那么就需要在第三部分任务处理人任务当中至少要保证运行时有超过一个人来处理当前任务,这样每个任务处理人都有对应的任务生成,默认每个任务处理人都必须完成自己的会签任务,流程实例才能离开当前人工任务节点向下流转。在任务类型为会签任务,同时任务处理人超过一个人时,默认所有人都必须完成自己的会签任务流程才能继续,如果想改变这种默认执行方式那么就需要修改第二个会签任务完成规则部分。第二部分会签任务完成规则共有五个选项,其各自含义如下表所示。属性名 | 类型 | 描述 |
所有任务全部完成 | 无 | 默认值,也就是当前人工任务节点产生的所有会签任务全部完成后流程才能继续向下流转。 |
完成任务数 | 数字 | 当流程会签任务完成数必须要大于等于当前数字的值,流程才能继续向下流转。 |
完成百分比 数字 当流程会签任务完成数的百分比必须要大于等于当前数字的值,流程才能继续向下流转。 | ||
表达式 | Boolean类型 | 指定一个表达式,要求当前表达式的值必须要返回一个Boolean类型,如果返回true,那么流程将继续向下流转,其它未完成的会签任务将会被取消。如定义表达式为“${approveCount>2?true:false}”,这个表达式就表示当approveCount这个流程变量值大于2时,返回true,否则返回false。每个会签任务完成时都会解析这个表达式的值是否返回true,如果是流程将继续向下流转,否则流程将继续等待。 |
指定Bean | 字符串 | 指定一个实现了com.bstek.uflo.process.handler.CountersignHandler接口的类配置到spring当中后的bean的id,运行时引擎会找到这个bean,执行CountersignHandler接口实现类的handle方法,如果该访问返回true,流程将继续向下流转,否则流程将继续等待。 在指定Bean时,除了可以手工输入外,还可以通过右边的“选择”按钮来连接远程包含uflo-console模块的应用服务,我们只需要从中选择一个合适的bean的id即可,弹出窗口的URL值格式如下: http://localhost:8080/uflo-test/dorado/uflo/list.handler |
属性名 | 类型 | 描述 |
流程发起人 | 无 | 用当前流程实例的发起人来作为当前人工任务产生的任务的任务处理人,这样无论任务类型是什么,只会有一个任务产生,因为只有一个任务处理人。 |
指定泳道 | 字符串 | 指定一个在流程模版级别定义的泳道的值为作为当前任务的处理人,这样,如果泳道的运行时值是一个集合类型,同时任务类型又是会签类型,那么就会产生多个任务,如果是普通任务,那么产生的就是竞争任务。 |
EL表达式 | 字符串 | 指定一个表达式的值为作为当前任务的处理人,这样,如果表达式的值是一个集合类型,同时任务类型又是会签类型,那么就会产生多个任务,如果是普通任务,那么产生的就是竞争任务。 |
字符串 | 指定一个实现了com.bstek.uflo.process.handler.AssignmentHandler接口并配置到spring中的bean的id作为当前任务的处理人,这样,如果该接口返回值是一个集合类型,同时任务类型又是会签类型,那么就会产生多个任务,如果是普通任务,那么产生的就是竞争任务。在指定Bean的值时,除了可以手工输入目标bean的id,还可以通过右边的“选择”按钮来选择一个在服务器已配置到spring中该接口的bean的id,弹出窗口的URL值格式如下: http://localhost:8080/uflo-test/dorado/uflo/list.handler | |
指定参与者 | 列表 | 指定参与者这种任务处理人分配方式最为复杂,它需要与包含uflo-console模块的已启动的应用建立连接,通过访问下面格式的URL, http://localhost:8080/uflo-test/dorado/uflo/list.assignee.provider 加载所有实现了com.bstek.uflo.process.assign.AssigneeProvider接口任务处理人提供类,关于AssigneeProvider接口见本小节后半部分描述。 |
关于任务处理人分配,这里我们需要重点关注一下,在UFLO当中,对于任务用户系统的组织机构员工信息,没有任何要求,任何类型的用户组织机构信息都可以通过这里的指定参与者与我们的任务处理人分配关联起来。在指定参与者这种任务处理人分配方式当中,我们的设计器需要连接远程包含包含uflo-console模块的已启动的应用,通过访问指定的URL,实现加载所有实现了com.bstek.uflo.process.assign.AssigneeProvider接口的类,该接口源码如下。
AssigneeProvider类源码
import java.util.Collection;
/**
* @author Jacky.gao
* @since 2013年8月17日 */
public interface AssigneeProvider { /**
* 设计器层面是否要用树形结构进行展示
* @return 返回true,表示设计器会用树形加载当前任务处理人列表 */
boolean isTree(); /**
* @return 返回当前任务处理人提供者名称,比如员工列表,部门列表等
*/
String getName(); /**
* 分页方式查询返回具体的任务处理人,可以是具体的人,也可以是部门等之类容器型对象 * @param pageQuery
* @param parentId
*/
void queryEntities(PageQuery<Entity> pageQuery,String parentId); /**
* 根据指定的处理人ID,返回具体的任务处理人用户名
* @param entityId 处理人ID,可能是一个用户的用户名,这样就是直接返回这个用户名,也可能是一个部门的ID,那么就是返回这个部门 下的所有用户的用户名等
* @return
*/
Collection<String> getUsers(String entityId); /**
* @return 是否禁用当前任务处理人提供器
*/
boolean disable();
}
该接口中所有方法的描述上面的代码当中都进行的详细的描述,可以看到,它并不要求返回的是一个用户还是一个部门,它可以是任何一种我们业务系统当中可能的组织机构信息,所以我们说这种方式在与我们的业务系统结合时是足够灵活的,开发人员在实现这个接口后,只需要将其配置到Spring当中,就可以在我们的设计器当中看到并使用它了。
在UFLO当中,默认我们提供了两个默认的AssigneeProvider接口的实现类,分别是com.bstek.uflo.process.assign.impl.DeptAssigneeProvider及com.bstek.uflo.process.assign.impl.UserAssigneeProvider,这两个实现类分别代表两种不同类型的任务处理人提供者,有兴趣的开发人员可以查询它们的源码,以学习AssigneeProvider的具体写法。
在任务处理人配置当中,还有最后一个属性,那就是“允许上一节为当前节点指定任务处理人”,如下图所示。一旦该属性勾选,那么业务流程开发中,允许在其它人工任务处理节点中为当前节点指定一个或多个具体的任务处理人,在具体操作的时候需要通过TaskClient接口提供的saveTaskAppointor方法实现。
更多建议: