Springboot应用程序有两种运行方式
Read the rest of this entry
加签是指当前节点审批完后需要额外再加一个审批人进行审批，额外加的审批用户审批完后流程流转到下一节点。比如正常审批流程为A->B->C，如果B执行了加签动作，那么流程就变为A->B-->D-->C，节点D就是加进来的。
医学上有个万能药叫做安慰剂，没有任何药物作用，可能就是一颗糖果，但患者并不知道，但因患者对医生信任、患者叫自我暗示以及对某种药物疗效的期望等而起到镇痛、镇蘸或缓解症状的作用。为什么提到这个呢，因为加签的方案就是一个安慰剂方案，用户感知到加签是从审批历史里感知的，在做加签操作时，审批历史里面记录了加签的动作，但是后台执行了重新分配(reassign)的操作将当前流程重新分配给另外一个人，达到加签的效果，所以加签就一行代码
taskService.setAssignee(task.getTaskId(), user);
Read the rest of this entry
回退操作是指，将流程退回到上一个节点，基本思路是通过审批历史服务HistoryService找到审批审批的上一节点，然后跟通用拒绝操作类似，将流程拨回到该节点，要注意的一个问题是，如果碰到并行审批，在并行线上回退应该回退到哪里呢？
如图，如果审批顺序为主管审批->上级领导审批->董事长审批，这时候总监审批执行回退操作，应该回退到哪个节点呢，显然不是董事长，因为这是两个并行互不干扰的审批，正常应该回退到主管审批这里，所以回退操作应该是基于execution的回退。如果你对ecxecution不了解，你可以查看之前的文章SpringBoot Activiti6系列教程(六)-Execution说明
因此，方案就是找到该execution的上个审批节点将流程回退到该节点。
Read the rest of this entry
从这章开始，就正式进入activiti的实战开发，使用activiti实现各种审批动作，包括一些中国式流程操作，比如回退，征询等，这些操作activiti的标准功能是没有的，但因为activiti不算复杂，也比较灵活，因此可以通过一些技巧或者变通的方法实现，这章就讨论通用拒绝的实现。为什么叫通用拒绝，因为在activiti里，正常的拒绝都是通过连接线加条件判断实现，你可以定义一个变量如outcome，拒绝的时候给这个变量赋值REJECT，在连接线上设置条件表达式从而实现拒绝操作。如图：
项目经理拒绝到发起人的表达式为${outcome=='REJECT'}，在流程里设置好变量就能实现拒绝操作：
taskService.setVariable(taskId, "outcome", "approve"); taskService.complete(taskId);
这种拒绝实现方式优点是简单，标准支持，灵活性强，能够从任意节点拒绝回任意节点，但缺点也是明显的
Read the rest of this entry
接上一篇文章，我们探究了execution的运行机制，activiti里变量的作用域就是通过execution实现，activiti里变量按作用域有以下几种
执行变量作用域在execution上，本地变量作用域在task上，临时变量不存储数据库，流程进入等待节点（比如UserTask）变量自动清除。
需要使用变量的是RuntimeService和TaskService，本文主要对这两个service中变量的使用做详细说明，避免在不了解变量使用范围的情况下，错误的使用变量，导致流程出错。
Read the rest of this entry
在activiti中有几个概念经常用，但文档也没有讲的很清楚，如果不理解，有可能会误用。本文就详细探讨以下几个概念
我们在前面章节讲过，bpmn流程模型文件需要通过RepositoryService进行发布，相同名称的流程模型重新部署后会升一个版本，但并不影响之前的流程，还未结束的流程还是会按照发起时候的版本走。因此deployment就表示一次资源的部署，资源类型不一定是bpmn文件，可以是任意文件。上传的资源元信息保存在ACT_RE_DEPLOYMENT中，资源内容以二进制形式保存在表ACT_GE_BYTEARRAY中，两张表通过DEPLOYMENT_ID字段关联
Read the rest of this entry
Service负责执行动作，Query负责执行查询，也就是涉及到数据的增、删、改由Service负责，涉及到数据的查由Query负责，在spring boot中，Service可以通过注入获取，Query可以通过相应的Service获取，所有的Service都可以通过ProcessEngine获取。
activiti有8个service管理着activiti所有的资源
Read the rest of this entry
在上一章节中，介绍了如何基于bpmn2.0的xml文件发起流程和获取待办，其中流程文件和代码打包在一起，但实际项目中很少会把流程文件和代码一起打包部署，这样的话，每次流程更新或者发布新流程都需要重新部署应用，因此我们制定了以下部署方案：
activit部署资源文件需要通过RepositoryService创建一个deployment，通过该deployment进行资源的部署，不单单是bpmn流程文件，activiti可以部署任何文件。
上传资源到activiti
Read the rest of this entry
在前面两节，我们介绍了如何部署activiti三个应用以及如何使用第三方数据库，如果你还没阅读前两章也不影响本文的阅读，如果有兴趣了解下，可以点击以下链接
从本章开始，就正式开始activiti程序开发，我们先从一个最简单的activiti流程开发，流程图如下：
流程很简单，发起后，由管理员admin审批，然后结束。
bpmn源文件代码如下
Read the rest of this entry
activiti默认采用内存数据库h2，作为本地测试是够了，但是作为测试环境，开发环境和生产环境，是远远不够的，我们需要使用更为强大和灵活的数据库，以下是zip包里提供的数据库创建脚本
activiti.db2.create.engine.sql activiti.db2.create.history.sql activiti.db2.create.identity.sql activiti.h2.create.engine.sql activiti.h2.create.history.sql activiti.h2.create.identity.sql activiti.hsql.create.engine.sql activiti.hsql.create.history.sql activiti.hsql.create.identity.sql activiti.mssql.create.engine.sql activiti.mssql.create.history.sql activiti.mssql.create.identity.sql activiti.mysql.create.engine.sql activiti.mysql.create.history.sql activiti.mysql.create.identity.sql activiti.mysql55.create.engine.sql activiti.mysql55.create.history.sql activiti.oracle.create.engine.sql activiti.oracle.create.history.sql activiti.oracle.create.identity.sql activiti.postgres.create.engine.sql activiti.postgres.create.history.sql activiti.postgres.create.identity.sql
Read the rest of this entry