Activiti工作流私人学习笔记

一、基础概念：
    1、activiti是个开源免费的工作流程框架，遵循BPMN2（Business Process Modeling Notation - BPMN业务流程模型注解）的规范，其
       简约思想的设计使得activiti非常轻量级，数据库层使用MyBatis，并且能与Spring完美的集成。目前activiti的新版本已经7.0了，
       但是此处的笔记是基于6.0.0版本。
       官方网站：https://www.activiti.org
       下载地址：https://www.activiti.org/download.html
       官网用户手册：https://www.activiti.org/userguide/6.latest/
      
    
    
    2、activiti的创始人Tom Bayen，跟Jboss jbpm流程框架是同一个创始人，是在离开Jboss公司后加入Alfresco公司后开发出来的
       新流程框架，并且相较于jbpm，activiti更加简单快捷，更容易上手。同时，activiti的前身是基于jbpm4衍生的，沿用了很多jbpm4
       的思想和设计理念，而jbpm5则进行了大改版，基本与原来的jbpm3、jbpm4没多大关联。

       
       
    3、activity的流程设计器（即画流程图），有两种方式：
        （1）原activity团队开发的基于eclipse插件（activiti-designer）：
              activiti-designer下载地址：https://github.com/Activiti/Activiti-Designer/releases
              在eclipse上直接在线更新地址：http://www.activiti.org/designer/update
              
              注意：使用离线安装插件时，需要额外下载 org.eclipse.emf.transaction、org.eclipse.emf.validation、org.eclipse.emf.workspace
                    这三个jar包，然后放入到eclipse的plugins的文件夹中，然后将activiti-designer插件文件拷贝到eclipse的dropins文件夹中
                    （不能通过在dropins中创建.link文件来链接文件）。
              
              
        （2）signavio公司开发的基于Web的activiti modeler流程设计器。
      
    
    
    
    4、如果任务审批是制定到组中，则此组下的人都有权限进行审批，但是最终一个任务只能有一个人审批（不考虑多审的情况下），在审批候选人确
       定要审批该任务前，会先制定TaskService.claim(...)方法，声明此任务被具体的那个候选人领取，任务被领取后其他候选人就不能再领取和审
       批此任务，只能等待声明人去完成审批TaskService.complete(...)。
    
    
    
    
    5、activiti在5.0版本之前，流程文件的后缀为 bpmn20.xml，在5.0开始改为bpmn后缀，其实文件格式内容是一样的，仅仅是后缀名修改了而已，这样
       是为了尽量保持BPMN2要求的规范(BPMN2规范定义的流程文件后缀就是bpmn)。
    
    
    

        
    6、activiti的待办任务来源有如下几种方式（即指定办理人的方式）：    
        方式一：直接分配办理人，通过指定activiti:assignee属性来实现。
        方式二：指定候选人范围内，通过指定activiti:candidateUsers属性来实现。
        方式三：指定候选组，通过指定activiti:candidateGroups属性来实现。
        方式四：转移给代办人，以代办人身份获取任务，办理完成后会重新交回给原办理人。
        方式五：转办过来的任务。即把任务的原办理人重新分配给其他用户。
        
    
    
    7、与任务相关的人分为几种类型：
        拥有人：此任务的拥有人，通常都是为空。一般在使用任务委派时，则拥有人是原办理人，而办理人字段则变为委派人。
        办理人：任务的办理人，有此人负责办理任务。
        参与人：不能签收和办理任务，只能是给任务提供意见的人。
       
     

    8、activiti的用户信息与业务系统中的用户信息做整合时，通常有如下几种方案：
        方案一：通过引起接口同步数据。在业务系统的用户信息做修改时，同时调用引起接口对activiti框架用户信息做修改，保持数据的同步。
        方案二：自定义Session工厂，自定义用户和组的实体管理器（EntityManager），用来替代原项目的用户和组Session工厂以及实体管理器。
        方案三：使用视图代替物理表。对ACE_ID_USER等表删除掉，基于业务用户表进行创建视图，结构与物理表保存一致。
        方案四：集成LDAP轻量目录访问协议来统一管理用户资源，通过LDAP来获取用户数据。
       
    
    
    9、activiti框架，是没有拒绝、回退概念的，流程也是没有状态的，判断流程完成也只是判断是否结束时间为依据。但是目前国内大部分的审批
       场景，可能都需要有拒绝、回退的功能，这部分功能需要自己额外扩展实现。如下有比较好的方案：
        回退功能的实现方案：删除当前活动任务，然后读取出org.activiti.bpmn.model.Process对象，指定节点重新开始执行审批。
                           注意使用此方案时，需要注意并行的任务（例如会签、并行网关），以及包含子流程的情况。
                           
        拒绝功能实现方案：直接调用框架的流程删除功能进行删除。
        
        流程状态：新增一个存储流程状态的表，可以在调用审批接口的时候，更新流程状态。
    
    
    
    10、activiti框架有防并发的处理机制，例如对task任务的审批，对应的数据库表ACT_RU_TASK有REV_字段，当审批任务时会对此表进行删除操作，
        在执行删除时，会带上REV_版本号字段作为删除条件，如果删除结果影响的条数为0，则会抛出异常，告知使用者此任务出现并发情况。
        具体可查看org.activiti.engine.impl.db.DbSqlSession.flushDeleteEntities(Class<? extends Entity>, Collection<Entity>)的删除判断。
    
    
    
    
二、基础功能：    
    1、activiti的流程图元素，主要分为如下几类：
    （1）启动和结束事件：表示一个流程的启动点和结束点，所有流程都有起始和结束点。
    （2）顺序流：是节点之间关系的连接者，关联各个节点。
    （3）任务：流程的工作节点，相当于流程所需要处理的审批流程数。
    （4）网关：用于控制流