1. activiti是按照key, value的方式保存变量的，历史变量会导致历史表极速膨胀。效率出问题的时候别哭。

2. 流程变量的主要目的是辅助工作流，保存运行阶段的数据，它没有设计成易于查询统计的形式，所以基本也没办法进行查询和统计。

然后，如果感觉还是历史流程变量适合自己的需求，需要进行如下两件事情：

1. 设置processEngineConfiguration的属性，默认值是audit

<property name="history" value="full" />

或者使用

histroeryservcie 查询 act_hi_variable表就好

repositoryService.deleteDeployment(processDefinitionId, true);

第二个参数cascade=true，表示级联删除这个部署下的所有流程定义，资源，实例，任务，定时任务，历史。

 assignee表示负责人，是实际在处理这个任务的人员。因为三个和尚没水吃，activiti里严格遵守专事专办。从根本上禁止一个任务多人负责，最后谁都不负责的问题。

 candidate表示候选人，适用于客服、销售之类抢单的场景。一个单子几个人都可以看到，谁抢到算谁的。谁抢单多谁赚得多。canidates里保存哪些人可以抢单，assignee为空时，这些候选人都可以抢，哪个抢到了，就把assignee设置为这个人，等于告诉别人，不用再抢了，已经有人抢走了。所有设置了assignee的任务，用candidateUser()不会查询出来，就是不想让别人看到别人抢走的单据，心生怨恨。抢到单子的人，也可以通过unclaim()释放，这样assignee又变成null了，其他人又可以抢了。

 identitylink里还有一种partcipant类型，用来记录参与者，如果一个人处理过一个任务，就会在identityLink表里记录为task对应的流程的参与者，可以通过createProcessInstanceQuery().involvedUser("zhangsan")查询到某个人经手过的所有流程。

 task里有一个owner字段，记录着这个任务的原负责人，当任务的负责人有事，无法亲手处理问题，就会把这个任务委托给其他人，被委托后的任务，assignee字段对应委托后的负责人，owner记录着委托前的原负责人。

 historicProcessInstance里有一个starterUserid字段，记录了流程发起人。

官方不支持分表分库。

修改为分表分库可以参考以下方案：

1. 按照processInstanceId分表

2. 对于根据id主键搜索的sql无需修改，分表分库之前与之后可以复用

3. 对于范围查询，要根据分表分库的方式进行重写

正常的工作流程时：流程到达一个userTask，暂停，生成一个任务，任务完成时，触发对应的流程继续执行。

如果你把任务删除了，流程就会一辈子等在那个地方，这个流程就挂死了。

所以我们不允许你删除一个与流程关联的任务，因为你删除了任务，对应的流程就永远的死掉了。

首先，在xml里设置activiti:skipExperssion="${shouldSkipThisNode}"的条件

然后，在进入这个节点之前，设置变量

shouldSkipThisNode : true

_ACTIVITI_SKIP_EXPRESSION_ENABLED : true

注意，一定要设置_ACTIVITI_SKIP_EXPRESSION_ENABLED，否则activiti不会判断skipExpression

啥是消息开始事件呢，就是要由消息触发的开始事件，业务场景就是，工作流引擎接收到一个外部消息，就发起一个流程。

对应的方法就是startProcessInstanceByMessage()。

如果你问startProcessInstanceByMessage()和startProcessInstanceById()有什么不同，其实从技术上没有任何不同。

区别在业务层面，我可以跟业务方聊需求的时候，让业务方给我一个messageCode，然后设置一个messageStartEvent，设置对应的messageCode可以触发它，发起一个流程。

别的startEvent就没办法这么干，只能你告诉业务方使用流程的id或key。

taskCandidateUser()不但会返回candidate-users设置的候选任务，还会返回candidate-groups设置的候选任务。

实际上，activiti会先通过identityService的findGroupsByUserId()获得user的所有group，再拼一个sql搜索所有的candidate-users,candidate-groups候选任务

那taskCandidateGroup这个岂不是没啥用？

这是一个业务问题，我想对候选任务按照业务组分类时，就需要用到taskCandidateGroups()

只有三种参与者类型

1.负责人（单人独占）

2.候选人（多人候选，领取后变成单人独占）

3.会签（实际是复制多个任务，每个任务单人独占）   或者 使用 并行网关 后面带多个userTask

    processEngine.getHistoryService().createHistoricVariableInstanceQuery().list()

https://github.com/Activiti/Activiti/blob/master/modules/activiti-engine/src/main/java/org/activiti/engine/impl/el/ExpressionManager.java

要通过cmd，调用Context.getExpressionManager().createExpression(text);生成Expression，然后调用expression.getValue(VariableScope variableScope);获得结果

runtimeService.deleteProcessInstance(processInstanceId, "delete reason")

involvedUser()会通过identity_link搜索指定用户参与过的所有流程实例，可能是“发起人”，“任务的负责人”，“任务的候选人”等等。默认能搜到的流程实例都是未完成的。

List processInstances = processEngine.getRuntimeService()
                                     .createProcessInstanceQuery()
                                     .involvedUser("zhangsan")
                                     .list();

activiti坚持着专事专办的精神，一个任务只能有一个负责人，这样可以避免多头领导，最终三个和尚没水吃。

一个任务还可以分配多个候选人，或候选组。这是为了在特定场景下，可以同时让多个人看到这条任务，但是最终只能有一个人领取，并完成这个任务。

taskService.createTaskQuery().taskCandidateOrAssigned(userId).list();

    前一个节点设置流程变量，completeTask(taskId, map)这样传递进一个变量，叫step3Assignee="zhangsan"

    下一个节点设置activiti:assigne="${step3Assignee}"，就实现了前一个节点指定后一个节点的负责人



    或者使用监听器 动态指定 比上面的方式好

慎重慎重，如出问题，后果自负。

可能导致的问题：导致流程图崩溃，无法显示，以及各种隐性的尚未发现的问题

假如一个节点绑定了任务创建事件（插入一条或者更改业务数据），如果自由流随意跳转到该节点会再次触发任务创建事件，这样的结果会导致业务数据出现重复或者数据不正确
以此类推，所以慎用

Flowable本身已经支持了

  在activiti中使用流程发起人的步骤如下：
  1. 在startEvent中使用activiti:initiator="initiator"设置一个变量名。
  2. 发起流程时，先设置setAuthenticateduserId()设置流程发起人，再发起流程。

identityService.setAuthenticatedUserId("zhangsan");
try{
  runtimeService.startProcessInstanceById(id);
} finally {
  identitySerivce.setAuthenticatedUserId(null);
}

  这样操作后，发起流程后，会创建一个initiator流程变量（变量名是由activiti:initiator指定的），变量值是zhangsan，也就是当前的流程发起人。
  后续就可以使用expression引用这个变量，比如设置成assignee="${initiator}"


historicProcessInstance里也会保存start_user_id。可以用historicProcessInstanceQuery.startUserId("zhangsan")查询

     1. 如果想让spring对ExecutionListener实现依赖注入。就要让spring管理对应的bean，再从spring中获取这个bean。关键就是不能自己new一个class，如果你自己new了一个class，spring怎么知道这个class什么时候需要注入？

     2. 确认spring管理好bean之后，在actviiti中，使用expression表达式引用这个bean。

     不能用这种方式，这种方式就是直接new一个class，创建出的实例不是spring托管的，无法自动注入依赖：

     <activiti:executionListener class="org.activiti.engine.test.bpmn.event.IntermediateNoneEventTest$MyExecutionListener" event="start" />
     要使用expression从spring中获取托管的bean，expression部分写bean的id：

     <activiti:executionListener delegateExpression="${myExecutionListener}" event="end" />

runtimeService.deleteProcessInstance(String processInstanceId, String deleteReason)
进一步，把历史也删除

historyService.deleteHistoricProcessInstance(String processInstanceId)




或者直接使用流程跳转 跳转到结束节点即可

在log4j或者logback里配置org.activiti.engine.impl.persistence.entity=DEBUG就会在日志里打印sql了。

如果自己项目里使用了jdbcTemplate，还可以配置org.springframework.jdbc.core.JdbcTemplate=DEBUG。

hibernate是配置hibernate.show_sql=false这个参数，不是配置日志了。

首先要通过setAuthenticatedUserid("zhangsan")在发起流程之前设置流程发起人。

然后可以通过processEngine.getHistoryService().createHistoricProcessInstanceQuery().starterUserid("zhangsan").list()查询我发起的流程

之前提到隐藏在Facade模式下面的所有功能都是由Command实现的，而为这些Command提供支撑的就是拦截器了。如果这么说还不好理解，我们可以先看看Command接口的定义：

public interface Command <T> {
  T execute(CommandContext commandContext);
}
只有一个execute()方法，用于实现实际的操作。这里请大家注意方法的参数CommandContext，实际上执行Command所需的相关资源，都是通过它来获取的，比如访问数据库，查询一下当前的流程啊，操作一下任务啊，访问一些历史之类的，都要通过这个CommandContext命令上下文来完成。而这个CommandContext就是通过Interceptor拦截器来提供的。

拦截器作用，就是在命令执行前做一些事情，在命令执行后做一些事情。默认会使用日志，事务和准备CommandContext的拦截器。

日志拦截器会使用debug日志打印命令的执行情况。

事务拦截器顾名思义，是用来控制事务的，对于standalone，jta和spring环境下需要使用不同的拦截器，细节后面讨论。

CommandContext拦截器会为命令初始化对应的CommandContext，保证Command执行过程中可以访问必要的资源，主要是数据库相关的东西。

控制事务
对于standalone模式，实际上是通过TransactionContext来控制事务的，并没有使用TransactionInterceptor，在准备CommandContext时，会创建一个TransactionContext，同时开启事务，命令执行完毕后，关闭CommandContext同时提交事务。

对于jta或spring模式下，TransactionContext只负责注册TransactionListener，原本用于提交事务的commit()被置空，事务完全由Jta(Spring)TransactionInterceptor控制，其中会调用jta(spring)的api实现对事务的控制。

形象的比较一下standalone和jta(spring)的区别：

standalone: 调用api -> 构造对应cmd -> 进入拦截器链 -> 打开数据库连接，开启事务 -> 调用cmd执行操作，并返回结果 -> 返回

独立运行

jta/spring: 先调用jta/spring托管的服务（这时已打开事务） -> 服务内调用processEngine -> 创建cmd -> 进入过滤器链 -> jta(spring)TransactionManager复用已开启的事务 -> 调用cmd执行操作，并返回结果 -> 如果出现异常，jta(spring)TransactionManager会标记当前事务需要回滚 -> 返回到jta/spring托管的事务时，事务会判断是提交还是回滚，并最终生效。