flowable的流转与扩展

一、引言

我们在业务开发中，使用flowable的过程中，一般实际使用的，都是flowable提供给我们的一些门面服务。即下图中的servcie

对于任意一个service，比如runtimeService，我们查看它的实现类，会发现都是形如commandExecutor.execute(new XXCmd())的代码。点击查看commandExecutor类，会发现这下面是几是一条责任链。下面我们先从初始化开始分析这个责任链的构建。

二、初始化

整个初始化的过程，基本如上图。此处具体代码如下：

在初始化的过程中，initCommandExecutors()方法内，初始化了命令执行器。我们来看具体代码：

public void initCommandExecutors() {
    //初始化命令默认配置(主要设置事务类型)
    initDefaultCommandConfig();
    //初始化schema命令配置
    initSchemaCommandConfig();
    // 初始化命令调用者
    initCommandInvoker();
    // 初始化命令拦截器
    initCommandInterceptors();
    // 初始化命令执行者
    initCommandExecutor();
}

接下来看下initCommandInvoker方法

public void initCommandInterceptors() {
    if (commandInterceptors == null) {
        commandInterceptors = new ArrayList<>();
        // 加入前置自定义拦截器
        if (customPreCommandInterceptors != null) {
            commandInterceptors.addAll(customPreCommandInterceptors);
        }
        
        // 加入默认拦截器
        commandInterceptors.addAll(getDefaultCommandInterceptors());
        
        // 加入后置自定义拦截器
        if (customPostCommandInterceptors != null) {
            commandInterceptors.addAll(customPostCommandInterceptors);
        }
        
        // 加入命令调用者的拦截器
        commandInterceptors.add(commandInvoker);
    }
}

显然，我们可以通过自定义customPreCommandInterceptors或者customPostCommandInterceptors，在flowable流程中，加入我们需要的自定义拦截器。下面我们看下默认拦截器的初始化：

public Collection<? extends CommandInterceptor> getDefaultCommandInterceptors() {
    if (defaultCommandInterceptors == null) {
        List<CommandInterceptor> interceptors = new ArrayList<>();
        // 加入日志拦截器
        interceptors.add(new LogInterceptor());

        // 如果db是crdb，加入crdb重试拦截器
        if (DATABASE_TYPE_COCKROACHDB.equals(databaseType)) {
            interceptors.add(new CrDbRetryInterceptor());
        }

        // 加入事务拦截器
        CommandInterceptor transactionInterceptor = createTransactionInterceptor();
        if (transactionInterceptor != null) {
            interceptors.add(transactionInterceptor);
        }

        //加入命令上下文拦截器（用于命令上下文的环境依赖创建初始化工作）
        if (commandContextFactory != null) {
            String engineCfgKey = getEngineCfgKey();
            CommandContextInterceptor commandContextInterceptor = new CommandContextInterceptor(commandContextFactory, 
                    classLoader, useClassForNameClassLoading, clock, objectMapper);
            engineConfigurations.put(engineCfgKey, this);
            commandContextInterceptor.setEngineCfgKey(engineCfgKey);
            commandContextInterceptor.setEngineConfigurations(engineConfigurations);
            interceptors.add(commandContextInterceptor);
        }

        // 加入事务上下文拦截器
        if (transactionContextFactory != null) {
            interceptors.add(new TransactionContextInterceptor(transactionContextFactory));
        }

        // 加入额外拦截器列表-实际有一个bpmn的可覆盖上下文拦截器
        List<CommandInterceptor> additionalCommandInterceptors = getAdditionalDefaultCommandInterceptors();
        if (additionalCommandInterceptors != null) {
            interceptors.addAll(additionalCommandInterceptors);
        }
        
        defaultCommandInterceptors = interceptors;
    }
    return defaultCommandInterceptors;
}

到这里，其实拦截器虽然加好了，但是还没有形成责任链，即定义好每一个拦截器的next。flowable接下来在initCommandExecutor中，遍历了拦截器列表，进行了批量设置，代码如下：

public void initCommandExecutor() {
    if (commandExecutor == null) {
        // 循环设置next，并返回第一个拦截器
        CommandInterceptor first = initInterceptorChain(commandInterceptors);
        // 设定命令拦截器
        commandExecutor = new CommandExecutorImpl(getDefaultCommandConfig(), first);
    }
}

public CommandInterceptor initInterceptorChain(List<CommandInterceptor> chain) {
    if (chain == null || chain.isEmpty()) {
        throw new FlowableException("invalid command interceptor chain configuration: " + chain);
    }
    for (int i = 0; i < chain.size() - 1; i++) {
        chain.get(i).setNext(chain.get(i + 1));
    }
    return chain.get(0);
}

图中的命令执行者，其实就是上文中的commandExecutor。至此责任链已经在流程引擎启动阶段，注册到了各个我们日常使用的service。

三、流程流转过程

3.1命令执行器分析

上面已经说过，命令真正执行，实际都是调用commandExecutor的excute方法（即通过命令执行器执行），对于命令执行器，代码的具体流转如下

图中的节点推进器中的操作列表，实际每一步操作，大多是当前操作执行完成后，再去压入下一步操作。具体情况我们后续分析。且对于flowable的命令模式，实际并不是所有操作都有后续操作，例如AbstractQuery.query也会进入此命令执行器，但是显然此时不需要进行额外操作。

3.2 流程流转的分析

讲流程流转之前，我们先补充一些基本概念，即流程元素、操作与推进。

3.3.1 流程元素

先看下flowable的类图：

其中在flowable中，flowNode代表流程元素，它有以下子类：

flownode代表流程节点，基本实现为事件（如开始事件/结束事件），网关（如排他网关，并行网关），活动三种，其中活动的主要实现为子进程和事件。
squenceFlow代表顺序流。
dataObject代表数据对象

一张流程图上的所有元素，都可以认为是流程元素。

先明确两个操作，即当前节点操作，与寻找下一条线的操作。对于操作与推进，分析如下：

3.3.2 操作与推进

操作

我们对flowable进行可视化编辑的时候，可以对每个节点添加边界事件，执行监听器等，这些组件的执行，都是通过操作来完成的。

对于flowable来讲，操作的基类为AbstractOperation。所有操作都会实现此类。他的实现列表如下：

这些实现中，在流程流转中最常用的为ContinueProcessOperation和TakeOutgoingSequenceFlowsOperation。分别代表继续流程操作和寻找顺序流操作（出线）。

在工作流引擎执行过程中，每经过一个流程元素，都需要执行该节点的继续流程操作。每个流程节点执行完成，都需要进行寻找顺序流操作，确定接下来的线的走向。

节点推进器

上面讲的操作，在flowable中，被节点操作推进器，即AbstractAgenda所持有。这个抽象类中，我们常用的实现类为DefaultFlowableEngineAgenda。AbstractAgenda实现了Agenda接口，而Agenda接口有继承了session。简单类图如下：

对于议程，我们的常用操作，是在Agenda中，具体代码如下：

public interface Agenda extends Session {

    /**
     * 返回操作计划是否为空
     */
    boolean isEmpty();

    /**
     * 把下一个操作返回并从队列中移除
     */
    Runnable getNextOperation();

    /**
     * 把操作加入队列
     */
    void planOperation(Runnable operation);
    
    /**
     * 加入一个异步执行的操作
     */
    <V> void planFutureOperation(CompletableFuture<V> future, BiConsumer<V, Throwable> completeAction);

}

AbstractAgenda持有的对象如下：

public abstract class AbstractAgenda implements Agenda {
    // 命令上下文
    protected CommandContext commandContext;
    // 操作列表
    protected LinkedList<Runnable> operations = new LinkedList<>();
    // 异步操作列表
    protected List<ExecuteFutureActionOperation<?>> futureOperations = new ArrayList<>();
}

3.3.3流程流转分析

下面是一个简单的bpmn流程图的例子，我们接下来结合这张图，继续分析流程的流转

简要描述当流程经过流程节点，或者顺序流时，会执行的操作如下：

如果当前节点是流程节点，则可以执行当前节点操作。当前流程节点操作如果完成，就会执行寻找下一条线的操作。
如果当前节点本身就是顺序流（线），执行完成后只会进入顺序流指向节点的当前节点操作。

每一次流程流转中，工作流引擎都会一直尝试完成这两种操作。对于上面的流程图，如果是执行了开始流程与请假审批同意流程，那么经历过的操作顺序分别如下图：

我们可以发现，当流程满足条件能自动向后执行时，当前节点操作与寻找下一条线的操作，总是交替运行的。实际上，每个操作进行中，如果符合条件，都会向操作栈中，压入下一（多）个操作。这种压入有时是在操作自身中进行的，有时是通过行为（ActivityBehavior）进行的。

3.3 异步流程分析

在flowable的任务节点中，我们可以通过勾选异步，来实现当前操作异步处理。这块具体代码逻辑如下图：

四、自定义扩展

flowable通过对外提供一些spi以及自定义设置的方法，支持我们进行一些自定义扩展。下面简单讲一下id生成器与缓存的初始化与自定义扩展。

4.1 id生成器

flowable的id生成器，使用接口IdGenerator类，此类中只有一个方法，即getNextId方法，代码如下：

public interface IdGenerator {
    String getNextId();
}

在需要获取id时，flowable会调用此方法。我们可以通过实现此接口，并压入配置的方式，使用自己的id生成器。

flowable自行实现的全局id生成器，有两种，即DbIdGenerator与StrongUuidGenerator。默认为DbIdGenerator。spring自动化配置时，定义为StrongUuidGenerator。

4.1.1DbIdGenerator

先来聊下DbIdGenerator。实际上DbIdGenerator数据存储在数据库。每次取回后会在本地进行缓存一个区间段（2500）。然后更新数据库中的对应字段（act_ge_property表中，name_为next.dbid的字段）。全局自增，且不能区分业务。当前区间段用完会重新请求数据库。

这种id显然存在以下问题：

长度容易变动，且id单调递增，容易被识别出单量
qps较高时，对数据库请求较多

4.1.2 StrongUuidGenerator

实际为uuid方案，不依赖数据库。

4.1.3 自定义

只要实现IdGenerator接口，并且写入配置即可。对于非spring环境示例代码如下：

public class SelfWithoutSpringTest {

    @Test
    public void testProcessEngine() {
        ProcessEngineConfiguration configuration = new StandaloneProcessEngineConfiguration();
        //数据库配置
        configuration.setJdbcDriver("com.mysql.jdbc.Driver");
        configuration.setJdbcUsername("XXX");
        configuration.setJdbcPassword("XXX");
        configuration.setJdbcUrl("XXX");
        configuration.setIdGenerator(new MyIdGenerator());

        ProcessEngine processEngine = configuration.buildProcessEngine();
        RuntimeService runtimeService = processEngine.getRuntimeService();

        ProcessInstance processInstance =
                runtimeService.startProcessInstanceById("benAskForLeaveFlow:5:758ba816-acdd-11ed-8563-aa5b81408f73");

        log.info(JSON.toJSONString(processInstance.getId()));
    }

    class MyIdGenerator implements IdGenerator {

        @Override
        public String getNextId() {
            return "ben-"+UUID.randomUUID().toString();
        }
    }
}

对于spring环境，实例代码如下

@Configuration
public class flowableIdConfig {

    @Bean
    @Primary
    public IdGenerator primaryIdGenerator(){
        return new PrimaryIdGenerator();
    }

    @Bean
    @Process
    public IdGenerator processIdGenerator(){
        return new ProcessIdGenerator();
    }
}

public class PrimaryIdGenerator implements IdGenerator {
    
    public String getNextId() {
        return "primary-"+ UUID.randomUUID().toString();
    }
}

public class ProcessIdGenerator implements IdGenerator {

    public String getNextId() {
        return "process-"+ UUID.randomUUID().toString();
    }
}

4.2 缓存

flowable运行中的缓存，大致可以分为两种，即流程定义缓存和各种实体缓存。

对流程定义(ProcessDefinition)这类数据的缓存，因为变更较少且访问频繁，将数据解析后常驻缓存在了进程中，且因每次部署时都是重新插入新的数据，所以不会存在有一致性的问题。
对于各数据实体的缓存，Flowable 设计了生命周期为一次命令的缓存，这类缓存能有效降低一次调用中相同数据对DB的多次查询，并随着CommandContext的销毁而销毁。

下面我们详细分析啊下流程定义的缓存

4.2.1缓存的初始化

在flowbale的的init中，下面的代码，主要用于初始化本地缓存

    initProcessDefinitionCache();
    initProcessDefinitionInfoCache();
    initAppResourceCache();
    initKnowledgeBaseCache();

其中除了initProcessDefinitionInfoCache方法，其余三个传入limitcount后，都是只是通过重写linkedHashmap的removeEldestEntry方法，来实现了LRU模式。initProcessDefinitionInfoCache还会对返回类型封装为ProcessDefinitionInfoCacheObject。以initProcessDefinitionCache为例，我们继续看下此方法的代码：

public void initProcessDefinitionCache() {
    // 流程定义缓存不存在，则初始化
    if (processDefinitionCache == null) {
        if (processDefinitionCacheLimit <= 0) {
            // 初始化一个容量无限的缓存map
            processDefinitionCache = new DefaultDeploymentCache<>();
        } else {
            // 初始化一个容量为limit的LRU的map
            processDefinitionCache = new DefaultDeploymentCache<>(processDefinitionCacheLimit);
        }
    }
}

public DefaultDeploymentCache() {
    this.cache = Collections.synchronizedMap(new HashMap<>());
}

/**
 * Cache which has a hard limit: no more elements will be cached than the limit.
 */
public DefaultDeploymentCache(final int limit) {
    this.cache = Collections.synchronizedMap(new LinkedHashMap<String, T>(limit + 1, 0.75f, true) { 
        // +1是不要的，因为要在删除旧数据前，把老数据加进来
        // 0.75的负载因子是默认参数
        private static final long serialVersionUID = 1L;

        @Override
        protected boolean removeEldestEntry(Map.Entry<String, T> eldest) {
            boolean removeEldest = size() > limit;
            if (removeEldest && LOGGER.isTraceEnabled()) {
                LOGGER.trace("Cache limit is reached, {} will be evicted", eldest.getKey());
            }
            return removeEldest;
        }

    });
}

4.2.2、缓存的查询

对缓存进行查询时，就是简单的从map中获取数据，方法如下：

public T get(String id) {
    return cache.get(id);
}

4.2.3、缓存的设定

设定有限制的LRU的map，demo如下：

@Test
public void testProcessEngine() {
    ProcessEngineConfigurationImpl configuration = new StandaloneProcessEngineConfiguration();
    //数据库配置
    configuration.setJdbcDriver("com.mysql.jdbc.Driver");
    configuration.setJdbcUsername("XXX");
    configuration.setJdbcPassword("XXX");
    configuration.setJdbcUrl("XXX");
    configuration.setProcessDefinitionCacheLimit(1);

    ProcessEngine processEngine = configuration.buildProcessEngine();
    RuntimeService runtimeService = processEngine.getRuntimeService();

    ProcessInstance processInstance =
            runtimeService.startProcessInstanceById("benAskForLeaveFlow:5:758ba816-acdd-11ed-8563-aa5b81408f73");
    ProcessInstance processInstance2 =
            runtimeService.startProcessInstanceById("benTestFlow:11:ce3839b1-a7af-11ed-b124-ca62e3fd2f34");
    ProcessInstance processInstance3 =
            runtimeService.startProcessInstanceById("benAskForLeaveFlow:5:758ba816-acdd-11ed-8563-aa5b81408f73");


    log.info(JSON.toJSONString(processInstance.getId()));
}

流程启动过程中，在StartProcessInstanceCmd的execute方法内，会调用getProcessDefinition方法，这其中，又会调用deploymentCache.findDeployedProcessDefinitionById方法，尝试通过流程定义id，获取流程定义。此方法代码如下：

public ProcessDefinition findDeployedProcessDefinitionById(String processDefinitionId) {
    if (processDefinitionId == null) {
        throw new FlowableIllegalArgumentException("Invalid process definition id : null");
    }

    // first try the cache
    ProcessDefinitionCacheEntry cacheEntry = processDefinitionCache.get(processDefinitionId);
    ProcessDefinition processDefinition = cacheEntry != null ? cacheEntry.getProcessDefinition() : null;

    if (processDefinition == null) {
        processDefinition = processDefinitionEntityManager.findById(processDefinitionId);
        if (processDefinition == null) {
            throw new FlowableObjectNotFoundException("no deployed process definition found with id '" + processDefinitionId + "'", ProcessDefinition.class);
        }
        processDefinition = resolveProcessDefinition(processDefinition).getProcessDefinition();
    }
    return processDefinition;
}

　我们可以在上面代码中第七行加上断点进行debug。会发现上面业务代码中，每次启动流程时，map的容量都只有1，保留为最近使用，符合预期。

　　当然，我们也可以通过自行实现DeploymentCache类，把这份缓存替换为redis缓存，但是并不建议这么做，因为对于流程定义缓存，实际缓存对象为ProcessDefinitionCacheEntry。他持有的两个对象，即BpmnModel与Process，并没有实现序列化。此问题2017年在github已经提出，但是至今没有解决，详见https://github.com/flowable/flowable-engine/issues/481

五、并行网关流转的一些问题

5.1、Q：流程经过并行网关后，接下来会出现多个流程实例。看起来其中有一个流程实例是复用原有流程实例。这个复用原流程实例的实例，是如何确定的？

A：关于并行网关出线的时候，哪个线使用原流程，通过代码看是第一条线，具体代码在org.flowable.engine.impl.agenda.TakeOutgoingSequenceFlowsOperation#leaveFlowNode方法内。

// 获取所有出线流程
List<ExecutionEntity> outgoingExecutions = new ArrayList<>(flowNode.getOutgoingFlows().size());

// 获取第一个顺序流
SequenceFlow sequenceFlow = outgoingSequenceFlows.get(0);

// 复用第一个当前流程实例
execution.setCurrentFlowElement(sequenceFlow);
execution.setActive(false);
outgoingExecutions.add(execution);

// 为其他流程实例出线
if (outgoingSequenceFlows.size() > 1) {
    for (int i = 1; i < outgoingSequenceFlows.size(); i++) {

        ExecutionEntity parent = execution.getParentId() != null ? execution.getParent() : execution;
        ExecutionEntity outgoingExecutionEntity = processEngineConfiguration.getExecutionEntityManager().createChildExecution(parent);

        SequenceFlow outgoingSequenceFlow = outgoingSequenceFlows.get(i);
        outgoingExecutionEntity.setActive(false);
        outgoingExecutionEntity.setCurrentFlowElement(outgoingSequenceFlow);

        executionEntityManager.insert(outgoingExecutionEntity);
        outgoingExecutions.add(outgoingExecutionEntity);
    }
}

第一个线的概念，是在于flowable会把bpmn解析为一个Process对象，其中FlowNode持有一个outgoingFlows对象。对于出线列表对象中的第一个元素，即第一条线。对于同一个bpnm文件，生成的Process应该用于是一致的，所以谁使用原流程不是随机的，而是固定的。

5.2、Q：并行网关如何决定继续向下流转？

A：关于并行网关如何收线决定往下走，根据代码分析，是会比较这个并行网关进入的线的条数，和完成的条数是否一致（注意下，这里只看当前网关的进入线数量，而非上一个网关出线数量。因为两个数量可能不一致）。这块还是涉及到之前说的当前节点执行类和出线类。当前节点执行类（ContinueProcessOperation）发现当前节点为并行网关时，经过一系列操作，会调用并行网关操作行为尝试出线，即ParallelGatewayActivityBehavior.execute。关键代码就在这个方法中，简要罗列如下：

// 获取已完成实例
Collection<ExecutionEntity> joinedExecutions = executionEntityManager.findInactiveExecutionsByActivityIdAndProcessInstanceId(execution.getCurrentActivityId(), execution.getProcessInstanceId());
if (multiInstanceExecution != null) {
    joinedExecutions = cleanJoinedExecutions(joinedExecutions, multiInstanceExecution);
}

// 获取当前并行网关入线数量
int nbrOfExecutionsToJoin = parallelGateway.getIncomingFlows().size();
// 获取已完成实例
int nbrOfExecutionsCurrentlyJoined = joinedExecutions.size();

// Fork

// Is needed to set the endTime for all historic activity joins
CommandContextUtil.getActivityInstanceEntityManager().recordActivityEnd((ExecutionEntity) execution, null);

// 如果当前入线数量=已完成数量。那么出线
if (nbrOfExecutionsCurrentlyJoined == nbrOfExecutionsToJoin) {
// 省略
    // 出线操作
   CommandContextUtil.getAgenda().planTakeOutgoingSequenceFlowsOperation((ExecutionEntity) execution, false);

}

posted @ 2023-02-22 15:13 豆豆323 阅读(760) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

豆豆323