Activiti高级功能简介
- Activiti的高级用例,会超越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传统历史管理器的附加品
- 虽然所有数据都在数据库表中,但是并没有为查询优化,不容易获取
真实的使用场景:
- 审计跟踪
- 将事件日志数据放到大数据存储中