activiti学习由浅入深02 weir 2014-12-26 11:09:09.0 java,activiti 1900 接着上一节开始,我们通过画图设计出业务流程图,然后上传到系统中(会存入数据库)并部署,然后就可以根据我们所绘制的图来完成我们的具体业务个体的处理,所以这种方式有点像流程作业一样。 这里我准备拿一个请假流程的例子开始我们的流程设计,先看一下最终的图形: 可以看到图片上面有园(细线的园、粗线的园),圆角矩形,带箭头的线,菱形里面还有粗线的X等这些图形都是BPMN2.0规范里面的,你可以先对它做一些大致的了解。 关于流程图的画法有很多种比如再看下面一个: 可以从开始——》部门审批 也可以从开始——》提交申请——》部门审批 这里还可以加一个判断就是部门审批完了之后还要经理审批 还可以是部门主管只能审批小于3天的请假超过三天要交给经理审批 可以说一个请假流程就可以设计出来好多版本,至于怎么设计完全取决于各公司的实际业务需求,还是我之前说的画图就是画业务需求 所以我不打算来叙述怎么画图,我想通过图片的后台代码xml、数据库表的存放结构以及activiti的api怎么调用综合叙述一下从图形到xml,怎么存放在数据库表里面和怎么调用这些表数据来让我们清晰的知道我的程序是怎么一步一步实现的。 所以这个活不好干也不好总结。 在我们还没有开始之前我们先去看一下activiti的数据库结构: http://www.cnblogs.com/llzgzljl/p/3356108.html ACT_ID_*: ’ID’表示identity (组织机构),IdentityService接口所操作的表。用户记录,流程中使用到的用户和组。这些表包含标识的信息,如用户,用户组,等等。 act_id_group 用户组信息表 act_id_info 用户扩展信息表 act_id_membership 用户与用户组对应信息表 act_id_user 用户信息表 看到这里我们就有疑问了,activiti本身有用户表呀,可是我们的系统也有用户表,这就告诉我们系统的用户要和activiti本身的用户同步,这是我们必须要做的,只有这样activiti才能有用户信息才能使用我们系统的用户信息进行工作。 为什么我们在做画图突然说起activiti的数据库了呢? 当你看到有 Initiator 发起人 Assignee 受托人,代理人 Candidate users(comma separated) 候选用户(逗号分隔) Candidate groups(comma separated) 候选组(逗号分隔) 逗号分隔 那就是说可以是多个了 这些信息你会想到什么,肯定是要有用户的呀,那么用户从哪里来的呀,就是上面activiti的几个表呀,哦哦哦,这时就恍然大悟了,这就是我们为什么要同步用户明细的原因,也就是为什么我们要先了解这几张表的原因。 通过我们看用户手册可以知道: Activiti对任务分配的扩展 当分配不复杂时,用户和组的设置非常麻烦。 为避免复杂性,可以使用用户任务的自定义扩展。 assignee属性:这个自定义扩展可以直接把用户任务分配给指定用户。 activiti:assignee=”kermit” /> 它和使用上面定义的humanPerformer 效果完全一样。 candidateUsers属性:这个自定义扩展可以为任务设置候选人。 activiti:candidateUsers=”kermit, gonzo” /> 它和使用上面定义的potentialOwner 效果完全一样。 注意它不需要像使用potentialOwner通过user(kermit)声明, 因为这个属性只能用于人员。 candidateGroups属性:这个自定义扩展可以为任务设置候选组。 activiti:candidateGroups=”management, accountancy” /> 它和使用上面定义的potentialOwner 效果完全一样。 注意它不需要像使用potentialOwner通过group(management)声明, 因为这个属性只能用于群组。 candidateUsers和 candidateGroups 可以同时设置在同一个用户任务中。 注意:虽然activiti提供了一个账号管理组件, 也提供了IdentityService, 但是账号组件不会检测设置的用户是否村爱。 它嵌入到应用中,也允许activiti与其他已存的账户管理方案集成。 首先我们接触的是 org.activiti.engine.impl.persistence.entity.UserEntity 和identityService.saveUser() org.activiti.engine.IdentityService.saveUser(User user) 也就是说有了这两个东西我们就可以在添加系统用户的时候一起把用户信息添加到activiti的用户表里面了 至于同步用户组我这里就不讲了,这里说多了也说不完,而且也没有什么统一的标准,如果你们的系统非常庞大恐怕activiti你们也就不会考虑使用了,如果你们的系统所需要的需求非常特殊那activiti也未必能够满足你们,这个时候你们就会有三种考虑购买更好的工作流中间件,自己开发工作流中间件和对开源工作流进行重构来满足需求。 这里有一些文章大家可以看看: http://www.kafeitu.me/activiti/2012/04/23/synchronize-or-redesign-user-and-role-for-activiti.html 这里为了测试使用我创建了一些用户: for (int i = 0; i < 30; i++) { User user=new User(); user.setUsername(“weir”+i); user.setPassword(“111″); user.setEmail(“634623907@qq.com”); user.setTel(“18218066985″); user.setUserId(“100″+i); userService.addUser(user); UserEntity ue=new UserEntity(user.getUserId()); ue.setEmail(user.getEmail()); ue.setPassword(user.getPassword()); ue.setFirstName(user.getUsername()); ue.setLastName(user.getUsername()); identityService.saveUser(ue); } 查看你的用户表和act_id_user 表,已经有了内容。 有了这些你就可以做一些简单的流程图,我们这里还是以请假流程为例子。