工作流引擎使用进阶！详细分析工作流中的高级使用示例

Activiti的高级功能

• Activiti高级功能简介
• 监听流程解析
• 支持高并发的UUID的ID生成器
• 多租户
• 执行自定义SQL
• 使用ProcessEngineConfigurator实现流程引擎配置
• 启动安全BPMN 2.0xml
• 事件日志

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增加配置
• 当自定义处理器内部逻辑对处理顺序有要求时需要考虑：配置到preBpmnParseHandlers的BpmnParseHandler实例会添加在默认处理器的前面配置到postBpmnParseHandlers的BpmnParseHandler实例会添加在默认处理器的后面
• 接口- org.activiti.engine.parse.BpmnParseHandler
• 在BpmnParseHandler接口中：getHandledTypes（）方法会翻译这个解析器处理的所有类型的集合，这些都是BaseElement的子类，返回集合的泛型限制也说明了这一点也可以继承AbstractBpmnParseHandler类并重写**getHandledType（）**方法，这样就只需要返回一个类型，而不是一个集合这个类型也包含需要默认解析处理器所需要的方法BpmnParseHandler实例只有在解析器访问到这个方法返回的类型时才会被调用
• 示例：当BPMN 2.0 xml包含process元素时，就会执行executeParse方法中的逻辑这是一个已经完成类型转换的方法，替换BpmnParseHandler接口中的parse方法
• 注意：在编写自定义解析处理器时，不要使用任何解析BPMN 2.0结构的内部类，这会导致出现问题很难定义应该实现BpmnParseHandler接口或集成内部抽象类 org.activiti.engine.impl.bpmn.parser.handler.AbstractBpmnParseHandler也可以替换默认的BpmnParseHandler实例，把解析BPMN 2.0元素替换为解析Activiti内部模型

支持高并发的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
• 使用UUID生成器需要添加依赖

多租户

• 多租户：通常是在软件需要作为多个不同组织服务时产生的概念关键是数据分片，组织不能看到其余组织的数据在这种场景下，组织，部门，小组就叫做租户
• 多租户和安装多个实例是从基本上不同的：多租户是一个Activiti流程引擎实例为每个组织分别运行，对应不同的数据表安装多个Activiti流程引擎实例时，虽然Activiti是轻量级的，运行流程引擎不会消耗很多资源，但是增加了复杂性，并需要更多维护工作。然而对于一些场景，也是正确的解决方案
• Activiti的多租户主要围绕着数据分片来实现：Activiti没有强行校验多租户的规则，即Activiti不会校验查询和使用数据时用户是否使用了正确的租户校验由Activiti引擎的调用者层负责完成Activiti只确认租户信息会被保存，并在查询流程数据时会被用到
• 在向Activiti流程引擎发布流程定义时，需要传递一个租户标识。是一个字符串，限制在256字符内，作为租户的唯一标识
• 通过部署传递租户Id有以下作用：所有包含在部署中的流程定义都会继承部署的tenantId所有从这些流程定义发起的流程实例，都会继承流程定义的tenantId所有流程实例运行阶段创建的任务都会继承流程实例的tenantId.单独运行的task也可以包含tenantId所有流程实例运行阶段创建的分支都会继承流程实例的tenantId在流程本身或通过API触发一个信号抛出事件可以通过tenantId实现。信号只会在租户环境下执行：如果有多个信号捕获事件，并且名字相同，实际只有正确的tenantId下的事件会被调用所有作业（定时器，异步调用）会集成tenantId，或者来自流程定义（比如定时开始事件），或流程实例（运行期创建的作业，比如异步调用）。这样其实潜在的可以支持为一些租户指定不同优先级的自定义jobExecutor所有历史实例（历史流程实例，任务和节点）会从对应的运行状态集成tenantId作为单独的一部分，model也可以设置tenantId.这里的model用来存储Activiti modeler设计的bpmn 2.0模型
• 为了确保流程数据使用tenantId，所有的查询API都可以通通过tenantId进行查询，可以使用其他的实体的对应查询实现替换

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

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

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

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

使用ProcessEngineConfigurator实现流程引擎配置

• 可以使用ProcessEngineConfigurator实现一种高级的扩展流程引擎的配置：创建一个org.activiti.engine.cfg.ProcessEngineConfigurator接口的实现注入到流程引擎配置里
• 实现ProcessEngineConfigurator接口需要实现两个方法：
• configure: 将ProcessEngineConfiguration作为参数，可以通过这种方法添加自定义配置，这个方法在流程创建之前，在所有默认配置执行之前保证调用到
• getPriority： 如果一些configurator存在依赖项的时候，允许对configurator进行排序
• configurator实例：LDAP集成：这个configurator用来替换默认的user和group管理器类，使用处理LDAP用户存储的类基本上一个configurator允许很大程度上修改或增强流程引擎，对高级的场景非常有用使用自定义的版本替换流程定义缓存， 如下
• 流程引擎配置器也可以通过ServiceLoader自动从classpath中加载：放在jar中的configurator实现必须放在classpath下并在jar的META-INF/services目录下包含一个org.activiti.engine.cfg.ProcessEngineConfigurator文件文件的内容是自定义实现的全类名当流程引擎启动时，日志会显示找到了哪些configurator
• 这种ServiceLoader的方式在某些环境下可能无法正常运行。使用ProcessEngineConfiguration的enableConfiguratorServiceLoader属性来禁用这个功能，这个属性的默认值为true

启动安全BPMN 2.0xml

• 大多数情况下，BPMN 2.0流程发布到Activiti引擎是在严格的控制下的
• 然而在某些情况下，可能需要把比较随意的BPMN 2.0 xml上传到引擎，这时就要要考虑恶意用户会攻击服务器
• 为了避免BPMN 2.0xml引擎服务器受到攻击，可以在引擎中设置enableSafeBpmnXml
• 默认这这个功能没有开启。因为这个功能需要使用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.如果没有使用事件日志，可以删除这个表
• 启用数据库日志

或者在流程引擎运行阶段

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