af56a642182640b6ad2ef52c7932f3d4.jpg

Activiti高级功能简介

• Activit的高级用例,会超越BPMN 2.0流程的范畴,使用Activiti高级功能需要有Activiti开发的明确目标和足够的Activiti开发经验

监听流程解析

• bpmn 2.0 xml文件需要被解析为Activiti内部模型,然后才能在Activiti引擎中运行.解析过程发生在发布流程或在内存中找不到对应流程的时候,这时会从数据库查询对应的xml
• 对于每个流程 ,BpmnParser类都会创建一个新的BpmnParse实例.这个实例会作为解析过程中的容器来使用
• 解析过程:
  • 对于每个BPMN 2.0元素,引擎中都会有一个对应的org.activiti.engine.parse.BpmnParseHandler实例
  • 解析器会保存一个BPMN 2.0元素与BpmnParseHandler实例的映射
  • 默认Activiti使用BpmnParseHandler来处理所有支持的元素
  • 同时也使用BpmnParseHandler来提供执行监听器,以支持流程历史
• 可以向Activiti引擎中添加自定义的org.activiti.engine.parse.BpmnParseHandler实例
• 经常使用的用例是把执行监听器添加到对应的环节,来处理一些事件队列.Activiti在内部就是这样进行历史处理的
• 要想添加这样的自定义处理器,需要为Activit增加配置:

<property name="preBpmnParseHandlers">
  <list>
    <bean class="org.activiti.parsing.MyFirstBpmnParseHandler" />
  </list>
</property>

<property name="postBpmnParseHandlers">
  <list>
    <bean class="org.activiti.parsing.MySecondBpmnParseHandler" />
    <bean class="org.activiti.parsing.MyThirdBpmnParseHandler" />
  </list>
</property>

• 当自定义处理器内部逻辑对处理顺序有要求时需要考虑:
  • 配置到preBpmnParseHandlers的BpmnParseHandler实例会添加在默认处理器的前面
  • 配置到postBpmnParseHandlers的BpmnParseHandler实例会添加在默认处理器的后面
• 接口- org.activiti.engine.parse.BpmnParseHandler:

public interface BpmnParseHandler {

  Collection<Class>? extends BaseElement>> getHandledTypes();

  void parse(BpmnParse bpmnParse, BaseElement element);

}

• 在BpmnParseHandler接口中:
  • getHandledTypes()方法会翻译这个解析器处理的所有类型的集合,这些都是BaseElement的子类,返回集合的泛型限制也说明了这一点
  • 也可以继承AbstractBpmnParseHandler类并重写getHandledType()方法,这样就只需要返回一个类型,而不是一个集合
  • 这个类也包含需要默认解析处理器所需要的方法
  • BpmnParseHandler实例只有在解析器访问到这个方法返回的类型时才会被调用
• 示例:
  • 当BPMN 2.0 xml包含process元素时,就会执行executeParse方法中的逻辑
  • 这是一个已经完成类型转换的方法,替换BpmnParseHandler接口中的parse方法

public class TestBPMNParseHandler extends AbstractBpmnParseHandler<Process> {

  protected Class<? extends BaseElement> getHandledType() {
    return Process.class;
  }

  protected void executeParse(BpmnParse bpmnParse, Process element) {
     ..
  }

}

• 注意:
  • 在编写自定义解析处理器时,不要使用任何解析BPMN 2.0结构的内部类,这会导致出现问题很难定义
  • 应该实现BpmnParseHandler接口或集成内部抽象类 org.activiti.engine.impl.bpmn.parser.handler.AbstractBpmnParseHandler
  • 也可以替换默认的BpmnParseHandler实例,把解析BPMN 2.0元素替换为解析Activiti内部模型:

<property name="customDefaultBpmnParseHandlers">
  <list>
    ...
  </list>
</property>

• 示例: 将所有任务强制设置为异步

public class CustomUserTaskBpmnParseHandler extends ServiceTaskParseHandler {

  protected void executeParse(BpmnParse bpmnParse, ServiceTask serviceTask) {

    // Do the regular stuff
    super.executeParse(bpmnParse, serviceTask);

    // Make always async
    ActivityImpl activity = findActivity(bpmnParse, serviceTask.getId());
    activity.setAsync(true);
  }

}

支持高并发的UUID的ID生成器

• 在高并发的场景中,默认的ID生成器可能因为无法很快的获取新ID区域而导致异常
• 所有流程引擎都有一个ID生成器,默认的ID生成器会在数据库划取一块ID范围,其余引擎不能使用相同范围的ID
• 在引擎运行期间,当默认的ID生成器发现已经越过ID范围时,就会启动一个新事务来获得新范围.在极限的情况下,高负载会导致问题
• 对于大部分情况,默认ID生成已经足够:
  • 默认的org.activiti.engine.impl.db.DbIdGenerator有一个idBlockSize属性,可以配置获取ID范围的大小,这样就可以改变获取ID的行为
  • 另一个可以选用的默认ID生成器是org.activiti.engine.impl.persistence.StrongUuidGenerator:
    • 会在本地生成一个唯一的UUID作为所有实体的标识
    • 因为生成UUID不需要访问数据库,所以在高并发环境下的表现比较好
• 默认ID生成器的性能依赖于运行硬件
• 将UUID生成器配置到Activiti:

<property name="idGenerator">
    <bean class="org.activiti.engine.impl.persistence.StrongUuidGenerator" />
</property>

• 使用UUID生成器需要添加依赖:

 <dependency>
    <groupId>com.fasterxml.uuid</groupId>
    <artifactId>java-uuid-generator</artifactId>
    <version>3.1.3</version>
</dependency>

多租户

• 多租户:
  • 通常是在软件需要作为多个不同组织服务时产生的概念
  • 关键是数据分片,组织不能看到其余组织的数据
  • 在这种场景下,组织,部门,小组就叫做租户
• 多租户和安装多个实例是从基本上不同的:
  • 多租户是一个Activiti流程引擎实例为每个组织分别运行,对应不同的数据表
  • 安装多个Activiti流程引擎实例时,虽然Activiti是轻量级的,运行流程引擎不会消耗很多资源,但是增加了复杂性,并需要更多维护工作.然而对于一些场景,也是正确的解决方案
• Activiti的多租户主要围绕着数据分片来实现:
  • Activiti没有强行校验多租户的规则,即Activiti不会校验查询和使用数据时用户是否使用了正确的租户
  • 校验由Activiti引擎的调用者层负责完成
  • Activiti只确认租户信息会被保存,并在查询流程数据时会被用到
• 在向Activiti流程引擎发布流程定义时,需要传递一个租户标识.是一个字符串,限制在256字符内,作为租户的唯一标识

 repositoryService.createDeployment()
            .addClassPathResource(...)
            .tenantId("myTenantId")
            .deploy();

• 通过部署传递租户Id有以下作用:
  • 所有包含在部署中的流程定义都会继承部署的tenantId
  • 所有从这些流程定义发起的流程实例,都会继承流程定义的tenantId
  • 所有流程实例运行阶段创建的任务都会继承流程实例的tenantId.单独运行的task也可以包含tenantId
  • 所有流程实例运行阶段创建的分支都会继承流程实例的tenantId
  • 在流程本身或通过API触发一个信号抛出事件可以通过tenantId实现.信号只会在租户环境下执行:如果有多个信号捕获事件,并且名字相同,实际只有正确的tenantId下的事件会被调用
  • 所有作业(定时器,异步调用)会集成tenantId,或者来自流程定义(比如定时开始事件),或流程实例(运行期创建的作业,比如异步调用).这样其实潜在的可以支持为一些租户指定不同优先级的自定义jobExecutor
  • 所有历史实体(历史流程实例,任务和节点)会从对应的运行状态集成tenantId
  • 作为单独的一部分,model也可以设置tenantId.这里的model用来存储Activiti modeler设计的bpmn 2.0模型
• 为了确保流程数据使用tenantId,所有的查询API都可以通过tenantId进行查询,可以使用其他的实体的对应查询实现替换:

runtimeService.createProcessInstanceQuery()
    .processInstanceTenantId("myTenantId")
    .processDefinitionKey("myProcessDefinitionKey")
    .variableValueEquals("myVar", "someValue")
    .list()

查询API也允许对tenantId使用like语法， 也可以过滤未设置tenantId的实体

• 重要注意点:
  • 因为数据库的限制,特别是处理null的唯一校验.默认表示未设置租户的tenantId的值是空字符串
  • 流程定义key,流程定义version,tenantId的组合应该是唯一的,这个有数据库约束校验这个规则
  • 要注意tenantId不应设置为null,会影响一些数据库Oracle的查询,会把空字符串当做null处理
  • 这也是为什么withoutTenantId查询会检查空字符串或null.这意味着相同的流程定义,即流程定义key相同可以部署到不同的租户下,可以拥有各自的版本.当不使用租户时也不会影响使用
• 这些限制不会影响Activiti在集群环境下运行
• 可以通过调用repositoryService的changeDeploymentTenantId(String deploymentId, String newTenantId) 修改tenantId. 会修改之前继承的所有tenantId. 当需要从非多租户环境向多租户环境下切换时,会非常实用

执行自定义SQL

• Activiti API允许使用高级API操作数据库:
  • 在查询数据方面,查询API和Native Query API是非常强大的
  • 但是对于某些情况,不够轻便
  • 使用完全自定义的SQL语句:select, insert, update和delete.可以执行在Activiti的数据存储之上,但是完全又可以配置在流程引擎中:比如使用事务
• 为了使用自定义SQL,Activiti引擎使用MyBatis框架的功能:
  • 因此使用自定义SQL的第一件事,要创建MyBatis映射类
  • 假设不需要全部的任务数据,只需要其中的一小部分.可以使用Mapper实现:

public interface MyTestMapper {

    @Select("SELECT ID_ as id, NAME_ as name, CREATE_TIME_ as createTime FROM ACT_RU_TASK")
    List<Map<String, Object>> selectTasks();

}

• Mapper需要设置到流程引擎配置中:

...
<property name="customMybatisMappers">
  <set>
    <value>org.activiti.standalone.cfg.MyTestMapper</value>
  </set>
</property>
...

• 这个Mapper是一个接口:
  • MyBatis框架会在运行阶段为这个接口创建一个实例
  • 返回值是没有类型的,是一个map的list,和对应的行列对应
  • 如果需要也可以使用MyBatis映射
• 执行上面的查询:
  • 可以使用managementService.executeCustomSql方法
  • 这个方法需要一个CustomSqlExecution实体
  • 这个实体类是一个封装类,隐藏了引擎的内部实现所需执行的信息
  • 但是由于Java泛型,查询返回的结果可读性差
• 示例:
  • mapper类和返回类型类
  • 简单调用mapper方法 并返回结果

CustomSqlExecution<MyTestMapper, List<Map<String, Object>>> customSqlExecution =
          new AbstractCustomSqlExecution<MyTestMapper, List<Map<String, Object>>>(MyTestMapper.class) {

  public List<Map<String, Object>> execute(MyTestMapper customMapper) {
    return customMapper.selectTasks();
  }

};

List<Map<String, Object>> results = managementService.executeCustomSql(customSqlExecution);

list中的Map只包含id,name和create time, 不是全部的任务对象

• 可以通过这样的方式执行任意SQL:

 @Select({
        "SELECT task.ID_ as taskId, variable.LONG_ as variableValue FROM ACT_RU_VARIABLE variable",
        "inner join ACT_RU_TASK task on variable.TASK_ID_ = task.ID_",
        "where variable.NAME_ = #{variableName}"
    })
    List<Map<String, Object>> selectTaskWithSpecificVariable(String variableName);

使用这种方法,任务表会与变量表关联.只会获得对应名称的变量,任务Id和对应的数值会被返回

使用ProcessEngineConfigurator实现流程引擎配置

• 可以使用ProcessEngineConfigurator实现一种高级的扩展流程引擎的配置:
  • 创建一个org.activiti.engine.cfg.ProcessEngineConfigurator接口的实现
  • 注入到流程引擎配置里

<bean id="processEngineConfiguration" class="...SomeProcessEngineConfigurationClass">

    ...

    <property name="configurators">
        <list>
            <bean class="com.mycompany.MyConfigurator">
                ...
            </bean>
        </list>
    </property>

    ...

</bean>

• 实现ProcessEngineConfigurator接口需要实现两个方法:
  • configure: 将ProcessEngineConfiguration作为参数,可以通过这种方法添加自定义配置,这个方法在流程创建之前,在所有默认配置执行之前保证调用到
  • getPriority: 如果一些configurator存在依赖项的时候,允许对configurator进行排序
• configurator实例:
  • LDAP集成:
    • 这个configurator用来替换默认的user和group管理器类,使用处理LDAP用户存储的类
    • 基本上一个configurator允许很大程度上修改或增强流程引擎,对高级的场景非常有用
  • 使用自定义的版本替换流程定义缓存, 如下:

public class ProcessDefinitionCacheConfigurator extends AbstractProcessEngineConfigurator {

    public void configure(ProcessEngineConfigurationImpl processEngineConfiguration) {
            MyCache myCache = new MyCache();
            processEngineConfiguration.setProcessDefinitionCache(enterpriseProcessDefinitionCache);
    }

}

• 流程引擎配置器也可以通过ServiceLoader自动从classpath中加载:
  • 放在jar中的configurator实现必须放在classpath下
  • 并在jar的META-INF/services目录下包含一个org.activiti.engine.cfg.ProcessEngineConfigurator文件
  • 文件的内容是自定义实现的全类名
  • 当流程引擎启动时,日志会显示找到了哪些configurator

INFO  org.activiti.engine.impl.cfg.ProcessEngineConfigurationImpl  - Found 1 auto-discoverable Process Engine Configurators
INFO  org.activiti.engine.impl.cfg.ProcessEngineConfigurationImpl  - Found 1 Process Engine Configurators in total:
INFO  org.activiti.engine.impl.cfg.ProcessEngineConfigurationImpl  - class org.activiti.MyCustomConfigurator

• 这种ServiceLoader的方式在某些环境下可能无法正常运行.使用ProcessEngineConfiguration的enableConfiguratorServiceLoader属性来禁用这个功能,这个属性的默认值为true

启动安全BPMN 2.0xml

• 大多数情况下,BPMN 2.0流程发布到Activiti引擎是在严格的控制下的
• 然而在某些情况下,可能需要把比较随意的BPMN 2.0 xml上传到引擎,这时就要要考虑恶意用户会攻击服务器
• 为了避免BPMN 2.0xml引擎服务器受到攻击,可以在引擎中设置enableSafeBpmnXml:

<property name="enableSafeBpmnXml" value="true"/>

• 默认这个功能没有开启.因为这个功能需要使用StaxSource类
• 由于JDK6,JBoss使用的是旧版的xml解析实现,无法使用StaxSource类,所以不能启用安全的BPMN 2.0xml
• 如果Activiti运行的平台支持安全的BPMN 2.0xml功能,建议打开

事件日志

• 在Activiti 5.16版本中,添加了事件日志机制:
  • 这种日志机制构建在通用目的下的Activiti引擎的事件机制,默认是禁用的
  • 目的是由引擎产生的事件会被捕获,包含所有事件数据的map会被创建出来,并提供给org.activiti.engine.impl.event.logger.EventFlusher, 会把数据刷新到别的地方
  • 默认会使用一个简单地基于数据库的事件处理器或者叫作刷新器,会使用jackson把map转换为JSON, 并保存到数据库中的EventLogEntryEntity实体
  • 默认会创建数据库日志表ACT_EVT_LOG. 如果没有使用事件日志,可以删除这个表
• 启用数据库日志:

processEngineConfiguration.setEnableDatabaseEventLogging(true);

或者在流程引擎运行阶段:

databaseEventLogger = new EventLogger(processEngineConfiguration.getClock());
runtimeService.addEventListener(databaseEventLogger);

• EventLogger类可以继承:
  • 在需要使用自定义的数据日志时:
    • createEventFlusher() 方法需要返回一个org.activiti.engine.impl.event.logger.EventFlusher接口的实例
    • managementService.getEventLogEntries(startLogNr, size) 可以获取Actviti的EventLogEntryEntity实例
• 可以使用大数据的NoSQL存储: MongoDb,Elastic Search等等来存储JSON。
• 使用的类是可插拔的: org.activiti.engine.impl.event.logger.EventLogger/EventFlusher和很多EventHandler类
• 可以切换成自定义应用场景: 不在数据库中存储JSON,而是放到队列或大数据存储中
• 注意:
  • 事件日志机制是Activiti传统历史管理器的附加品
  • 虽然所有数据都在数据库表中,但是并没有为查询优化,不容易获取
  • 真实的使用场景:
    • 审计跟踪
    • 将事件日志数据放到大数据存储中