Activiti_玩转工作流

 一、初步认识工作流

  工作流就是将开发中由代码控制的业务流程状态抽取出来，然后进行统一控制的机制！比如在实际开发中，我们需要表明一个状态的改变，可以通过字段status来进行转化，常见的业务请假流程四个环节的状态有：'待提交审核'，'主管审核'、'经理审核'、'审核完成'。当我们在实现这几个状态的改变时，是通过硬编码实现的，执行待提交审核状态，就一定会到达主管审核，以此类推！如果业务需求发生了改变，流程只需要三个环节：待提交审核'，'主管审核'、'审核完成'，这时我们就得去更改代码了，需要在进行'主管审核'后，直接将状态更改为;审核完成'状态，看起来这样好像也不麻烦，就更改一处！！但是，这只是一个小小的流程而已，如果业务再复杂一点呢，一旦更改流程，是不是代码需要大改了？这样就很不方便啊！而工作流，就帮我们解决了这个问题，工作流适用于业务复杂且需求经常性变更的流程中。
    

 

二、工作流介绍

Activiti5是由Alfresco软件在2010年5月17日发布的业务流程管理（BPM）框架，它是覆盖了业务流程管理、工作流、服务协作等领域的一个开源的、灵活的、易扩展的可执行流程语言框架。Activiti基于Apache许可的开源BPM平台，创始人Tom Baeyens是JBoss jBPM的项目架构师，它特色是提供了eclipse插件，开发人员可以通过插件直接绘画出业务流程图。

三、 两种工作流环境的搭建：

a、activiti单独运行StandaloneProcessEngineConfiguration
b、activiti与spring整合SpringProcessEngineConfiguration
搭建时需要五种activity表处理策略，即databaseSchemaUpdate配置的五种值
false（默认）：检查数据库表的版本和依赖库的版本， 如果版本不匹配就抛出异常。
true:构建流程引擎时，执行检查，如果需要就执行更新。 如果表不存在，就创建。（常用）
create-drop: 构建流程引擎时创建数据库表， 关闭流程引擎时删除这些表。
drop-create：先删除表再创建表。（常用，使用完成后改为true）
create: 构建流程引擎时创建数据库表， 关闭流程引擎时不删除这些表。

## 四、activiti.cfg.xml（activiti的配置文件）

Activiti核心配置文件，配置流程引擎创建工具的基本参数和数据库连接池参数。

定义数据库配置参数：
jdbcUrl: 数据库的JDBC URL。
jdbcDriver: 对应不同数据库类型的驱动。
jdbcUsername: 连接数据库的用户名。
jdbcPassword: 连接数据库的密码。
基于JDBC参数配置的数据库连接 会使用默认的MyBatis连接池。 下面的参数可以用来配置连接池（来自MyBatis参数）：
jdbcMaxActiveConnections: 连接池中处于被使用状态的连接的最大值。默认为10。

jdbcMaxIdleConnections: 连接池中处于空闲状态的连接的最大值。

jdbcMaxCheckoutTime: 连接被取出使用的最长时间，超过时间会被强制回收。 默认为20000（20秒）。
jdbcMaxWaitTime: 这是一个底层配置，让连接池可以在长时间无法获得连接时， 打印一条日志，并重新尝试获取一个连接。（避免因为错误配置导致沉默的操作失败）。 默认为20000（20秒）。
示例数据库配置：
---------------------```

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans   http://www.springframework.org/schema/beans/spring-beans.xsd">

  <bean id="processEngineConfiguration" class="org.activiti.engine.impl.cfg.StandaloneProcessEngineConfiguration">
    <!--数据连接信息  -->
    <property name="jdbcUrl" value="jdbc:mysql:///activiti?createDatabaseIfNotExist=true" />
    <property name="jdbcDriver" value="com.mysql.jdbc.Driver" />
    <property name="jdbcUsername" value="root" />
    <property name="jdbcPassword" value="123456" />
    <!-- 自动建表 -->
    <property name="databaseSchemaUpdate" value="true" />
  </bean>

</beans>

```

Activiti–持久化-数据库持久化

Activiti是一个强大的业务流程管理（BPM）框架，他本身需要数据库支持，它使用了Mybatis作为持久化框架，对于数据库管理系统（DBMS）支持多个。并且它的数据库表名有一定的特征。

Activiti的后台是有数据库的支持，所有的表都以ACT_开头。 第二部分是表示表的用途的两个字母标识。 用途也和服务的API对应。
1)ACT_RE_: 'RE’表示repository。 这个前缀的表包含了流程定义和流程静态资源(bpmn和png) （图片，规则，等等）。
2)ACT_RU_: 'RU’表示runtime。 这些运行时的表，包含流程实例，任务，变量，异步任务，等运行中的数据。 Activiti只在流程实例执行过程中保存这些数据， 在流程结束时就会删除这些记录。 这样运行时表可以一直很小速度很快。
3)ACT_ID_: 'ID’表示identity。 这些表包含身份信息，比如用户，组等等。
4)ACT_HI_: 'HI’表示history。 这些表包含历史数据，比如历史流程实例， 变量，任务等等。
5) ACT_GE_*: 通用数据， 用于不同场景下。

资源库流程规则表

1)act_re_deployment 部署信息表
2)act_re_model 流程设计模型信息表
3)act_re_procdef 流程定义数据表

运行时数据库

1)act_ru_execution 运行时流程执行实例表
2)act_ru_identitylink 运行时流程人员表，主要存储任务节点与参与者的相关信息
3)act_ru_task 运行时任务节点表
4)act_ru_variable 运行时流程变量数据表

历史数据库表

1)act_hi_actinst 历史节点表
2)act_hi_attachment 历史附件表
3)act_hi_comment 历史意见表
4)act_hi_identitylink 历史流程人员表
5)act_hi_detail 历史详情表，提供历史变量的查询
6)act_hi_procinst 历史流程实例表
7)act_hi_taskinst 历史任务实例表
8)act_hi_varinst 历史变量表

组织机构表

1)act_id_group 用户组信息表 JBPM_ID_MEMBERSHIP
2)act_id_info 用户扩展信息表
3)act_id_membership 用户与用户组对应信息表
4)act_id_user 用户信息表
这四张表很常见，基本的组织机构管理，关于用户认证方面建议还是自己开发一套，组件自带的功能太简单，使用中有很多需求难以满足

通用数据表

1)act_ge_bytearray 二进制数据表
2)act_ge_property 属性数据表存储整个流程引擎级别的数据,初始化表结构时，会默认插入三条记录。
---------------------
 

案例：请假流程

开始--->员工申请请假
                     --->主管审核-->主管审核不通过--->员工申请请假
                           ---主管审核通过--->（申请天数达3天以上需要）经理审核--->经理审核不通过--->员工申请请假
                                                                                                      ---->经理审核通过--->（结束）
                                                                     ---->（申请天数小于3天不需经理审核直接）审核通过--->（结束）
1、在流程定义的设计中（对应第二部分的3）
我们在“开始事件”设置initial为startUser，在第一个任务“员工申请请假”的Assignee的值中设计成${startUser}
在“主管审核”任务中设置Candidate-groups对应act_id_group中主管身份的id值
在“经理审核”任务中设置Candidate-groups对应act_id_group中经理身份的id值
在“主管审核”任务中指向“员工申请请假”的连线condition上设置${status=='0'}
在“主管审核”任务中指向“经理审核”的连接condition上设置${status=='1'&&day>=3}
在“主管审核”任务中指向“结束”的连接condition上设置${status=='1'&&day<3}
在“经理审核”任务中指向“员工申请请假”的连线condition上设置${managerStatus=='0'}
在“经理审核”任务中指向“结束”的连线condition上设置${managerStatus=='1'}

2、将设计出的流程定义进行部署（对应第二部分的4）
3、流程开始
a、员工填写请假条，进行点击保存，这时就要开启流程实例，并设置流程发起人为该登录员工的id，并且需要指定该请假条的信息key，因为到时需要设置全局变量day(对应第二部分的8)
b、该员工可以查看他当前的待办任务（对应第二部分的9）
c、该员工可以提交请假任务,这时需要获取通过Task获取流程实例id，从而获取到流程实例查询对象，接着获取到businessKey，从而关联得到该员工请假的day数据，并把day放入到variables里（对应第二部分的10）
d、这时到达了主管审核，登录系统的主管需要通过查询候选人组任务（对应第二部分的14），查看需要审核的任务，点击拾取操作（对应第二部分的15）成为该任务的负责人，然后查看他当前的待办任务进行（对应第二部分的9），然后主管就可以为该员工进行审核了，执行审核后需要把审核结果的status的值放入到variables中（对应第二部分的10）
如果status=='1'且day>=3，则流程会执行到“经理审核”
如果status=='1'且day<3，则流程结束
如果status=='0',则流程会执行到“员工申请请假”，员工可以重新更改申请信息，进行再次申请
e、到达“经理审核”，登录系统的经理需要通过查询候选人组任务（对应第二部分的14），查看需要审核的任务，点击拾取操作（对应第二部分的15）成为该任务的负责人，然后查看他当前的待办任务（对应第二部分的9），然后主管就可以为该员工进行审核了，执行审核后需要把审核结果managerStatus的值放入到variables中（对应第二部分的10）
如果managerStatus==‘1’,则流程结束
如果managerStatus==‘0’，则会回到”员工申请请假“，员工可以重新更改申请信息，进行再次申请

总结

1、从第三部分的案例中，
如果业务需求更改为只要申请一个月才需要经理审核，我们可以直接设计流程定义，重新进行部署流程定义即可解决业务需求的变更
如果业务需要突然不需要主管审核了，我们可以直接设计流程定义，删除主管审核环节，重新部署即可解决业务需求的变更
2、在实际开发中，案例中的day最好存放一个pojo对象，然后引用pojo的变量数据即可，这时如果业务需求变更需要用到其他数据作为判断依据，我们也不需要进行更改代码了，只要更改condition条件即可，比如到经理的审核条件变成只要是主管身份才需要经理进行审核，那么在使用pojo对象时，我们尽量将登录用户的信息都保存到pojo对象中，通过${user.userType=='1'&&status=='1'}才到经理审核
3、在请假案例中也可以加入排他网关，防止条件没有一个符合时，导致流程异常终止
4、需要更复杂的分支与汇聚流程，可以使用包含网关和并行网关
5、需要进行任务后对业务数据进行操作，可以使用监听器
最后再讲一讲activiti的常用表
act_ge_bytearray 存取了流程定义的资源文件和序列化的流程变量
act_hi_actinst 流程实例的历史任务
act_hi_identitylink 历史流程参与者的数据表
act_hi_procinst 历史流程实例表
act_hi_taskinst  历史任务实例表
act_hi_varinst 历史流程变量表
act_id_group候选组表
act_id_membership候选组与候选人关联表
act_id_user候选人表
act_re_deployment流程定义部署表
act_re_procdef流程定义信息表
act_ru_identitylink 当前流程参与者的数据表
act_ru_task当前任务表
act_ru_variable当前流程变量表
---------------------