Flowable 已经执行完毕的流程去哪找？-低调大师

Flowable 已经执行完毕的流程去哪找？

2022-11-08 423

@[toc] 在之前的文章中松哥和小伙伴们聊过，正在执行的流程信息是保存在以 ACT_RU_ 为前缀的表中，执行完毕的流程信息则保存在以 ACT_HI_ 为前缀的表中，也就是流程历史信息表，当然这个历史信息表继续细分的话，还有好多种，今天我们就来聊一聊这个话题。

假设我有如下一个流程：

当这个流程执行完毕后，以 ACT_RU_ 为前缀的表中的数据均已清空，现在如果想查看刚刚执行过的流程信息，我们就得去以 ACT_HI_ 为前缀的表中。

1. 历史流程信息

历史流程信息查看，方式如下：

@Test
void test05() {
    List<historicprocessinstance> list = historyService.createHistoricProcessInstanceQuery().finished().list();
    for (HistoricProcessInstance hpi : list) {
        logger.info("name:{},startTime:{},endTime:{}",hpi.getName(),hpi.getStartTime(),hpi.getEndTime());
    }
}

调用的时候执行的 finished() 方法表示查询已经执行完毕的流程信息（从这里也可以看出，对于未执行完毕的流程信息也会保存在历史表中）。

我们来看下这个查询对应的 SQL，如下：

SELECT RES.* , DEF.KEY_ as PROC_DEF_KEY_, DEF.NAME_ as PROC_DEF_NAME_, DEF.VERSION_ as PROC_DEF_VERSION_, DEF.DEPLOYMENT_ID_ as DEPLOYMENT_ID_ from ACT_HI_PROCINST RES left outer join ACT_RE_PROCDEF DEF on RES.PROC_DEF_ID_ = DEF.ID_ WHERE RES.END_TIME_ is not NULL order by RES.ID_ asc

从这个 SQL 中可以看到，这个查询本质上就是查询的 ACT_HI_PROCINST 表。如下图：

如果我们在查询的时候不限制流程是否执行完毕，那么我们的查询方法如下：

@Test
void test05() {
    List<historicprocessinstance> list = historyService.createHistoricProcessInstanceQuery().list();
    for (HistoricProcessInstance hpi : list) {
        logger.info("name:{},startTime:{},endTime:{}",hpi.getName(),hpi.getStartTime(),hpi.getEndTime());
    }
}

对应的查询 SQL 如下：

SELECT RES.* , DEF.KEY_ as PROC_DEF_KEY_, DEF.NAME_ as PROC_DEF_NAME_, DEF.VERSION_ as PROC_DEF_VERSION_, DEF.DEPLOYMENT_ID_ as DEPLOYMENT_ID_ from ACT_HI_PROCINST RES left outer join ACT_RE_PROCDEF DEF on RES.PROC_DEF_ID_ = DEF.ID_ order by RES.ID_ asc

和前面的 SQL 相比，后面的 SQL 少了 WHERE RES.END_TIME_ is not NULL 条件，也就是说，判断一个流程是否执行完毕，就看它的 END_TIME_ 是否为空，不为空就表示流程已经执行结束了，为空就表示流程尚在执行中。

2. 历史任务查询

刚刚我们查询的是历史流程，接下来我们来看下历史任务，也就是查询一个流程中执行过的 Task 信息，如下表示查询所有的历史流程任务：

@Test
void test06() {
    List<historictaskinstance> list = historyService.createHistoricTaskInstanceQuery().list();
    for (HistoricTaskInstance hti : list) {
        logger.info("name:{},assignee:{},createTime:{},endTime:{}",hti.getName(),hti.getAssignee(),hti.getCreateTime(),hti.getEndTime());
    }
}

这个查询对应的 SQL 如下：

SELECT RES.* from ACT_HI_TASKINST RES order by RES.ID_ asc

可以看到，历史任务表就是 ACT_HI_TASKINST，如下图：

当然，这里还有很多其他的玩法，例如查询某一个流程已经执行完毕的历史任务，如下：

@Test
void test07() {
    List<historicprocessinstance> instanceList = historyService.createHistoricProcessInstanceQuery().list();
    for (HistoricProcessInstance hpi : instanceList) {
        List<historictaskinstance> list = historyService.createHistoricTaskInstanceQuery().processInstanceId(hpi.getId()).finished().list();
        for (HistoricTaskInstance hti : list) {
            logger.info("name:{},assignee:{},createTime:{},endTime:{}", hti.getName(), hti.getAssignee(), hti.getCreateTime(), hti.getEndTime());
        }
    }
}

这个里边的查询历史任务的 SQL 如下：

SELECT RES.* from ACT_HI_TASKINST RES WHERE RES.PROC_INST_ID_ = ? and RES.END_TIME_ is not null order by RES.ID_ asc

可以看到，跟前面相比，多了两个条件：

流程实例 ID
流程结束时间不为 null

从这里也可以看出来，这个 finish 方法的执行逻辑跟我们前面讲的是一样的。

3. 历史活动查询

历史任务就是各种 Task，历史活动则包括跟多内容，像开始/结束节点，连线等等这些信息都算是活动，这个在之前的文章中松哥已经和大家介绍过了。

查询代码如下：

@Test
void test08() {
    List<historicactivityinstance> list = historyService.createHistoricActivityInstanceQuery().list();
    for (HistoricActivityInstance hai : list) {
        logger.info("name:{},startTime:{},assignee:{},type:{}",hai.getActivityName(),hai.getStartTime(),hai.getAssignee(),hai.getActivityType());
    }
}

这个查询对应的 SQL 如下：

SELECT RES.* from ACT_HI_ACTINST RES order by RES.ID_ asc

可以看到，ACT_HI_ACTINST 表中保存了历史活动信息。

4. 历史变量查询

查询流程执行的历史变量，方式如下：

@Test
void test09() {
    HistoricProcessInstance pi = historyService.createHistoricProcessInstanceQuery().singleResult();
    List<historicvariableinstance> list = historyService.createHistoricVariableInstanceQuery().processInstanceId(pi.getId()).list();
    for (HistoricVariableInstance hvi : list) {
        logger.info("name:{},type:{},value:{}", hvi.getVariableName(), hvi.getVariableTypeName(), hvi.getValue());
    }
}

这个查询对应的 SQL 如下：

SELECT RES.* from ACT_HI_VARINST RES WHERE RES.PROC_INST_ID_ = ? order by RES.ID_ asc

可以看到流程的历史变量信息保存在 ACT_HI_VARINST 表中。

5. 历史日志查询

有的小伙伴看到日志这两个字可能会觉得奇怪，咦？流程执行还有日志吗？没听说过呀！

其实历史日志查询就是前面那几种的一个集大成者，用法如下：

@Test
void test10() {
    HistoricProcessInstance pi = historyService.createHistoricProcessInstanceQuery().singleResult();
    ProcessInstanceHistoryLog historyLog = historyService.createProcessInstanceHistoryLogQuery(pi.getId())
            //包括历史活动
            .includeActivities()
            //包括历史任务
            .includeTasks()
            //包括历史变量
            .includeVariables()
            .singleResult();
    logger.info("id:{},startTime:{},endTime:{}", historyLog.getId(), historyLog.getStartTime(), historyLog.getEndTime());
    List<historicdata> historicData = historyLog.getHistoricData();
    for (HistoricData data : historicData) {
        if (data instanceof HistoricActivityInstance) {
            HistoricActivityInstance hai = (HistoricActivityInstance) data;
            logger.info("name:{},type:{}", hai.getActivityName(), hai.getActivityType());
        }
        if (data instanceof HistoricTaskInstance) {
            HistoricTaskInstance hti = (HistoricTaskInstance) data;
            logger.info("name:{},assignee:{}", hti.getName(), hti.getAssignee());
        }
        if (data instanceof HistoricVariableInstance) {
            HistoricVariableInstance hvi = (HistoricVariableInstance) data;
            logger.info("name:{},type:{},value:{}", hvi.getVariableName(), hvi.getVariableTypeName(), hvi.getValue());
        }
    }
}

这个里边，首先是查询基本的流程日志信息，这个本质上就是查询历史流程实例信息，对应的 SQL 如下：

select RES.*, DEF.KEY_ as PROC_DEF_KEY_, DEF.NAME_ as PROC_DEF_NAME_, DEF.VERSION_ as PROC_DEF_VERSION_, DEF.DEPLOYMENT_ID_ as DEPLOYMENT_ID_ from ACT_HI_PROCINST RES left outer join ACT_RE_PROCDEF DEF on RES.PROC_DEF_ID_ = DEF.ID_ where PROC_INST_ID_ = ?

接下来我写了三个 include，每一个 include 都对应一句 SQL：

includeActivities 对应的 SQL 如下：

SELECT RES.* from ACT_HI_ACTINST RES WHERE RES.PROC_INST_ID_ = ? order by RES.ID_ asc

includeTasks 对应的 SQL 如下：

SELECT RES.* from ACT_HI_TASKINST RES WHERE RES.PROC_INST_ID_ = ? order by RES.ID_ asc

includeVariables 对应的 SQL 如下：

SELECT RES.* from ACT_HI_VARINST RES WHERE RES.PROC_INST_ID_ = ? order by RES.ID_ asc

最终查询完成后，调用 getHistoricData 方法可以查看这些额外的数据，List 集合中存放的 HistoricData 也分为不同的类型：

includeActivities 方法对应最终查询出来的类型是 HistoricActivityInstance。
includeTasks 方法对应最终查询出来的类型是 HistoricTaskInstance。
includeVariables 方法对应最终查询出来的类型是 HistoricVariableInstance。

在遍历的时候通过类型判断去查看具体是哪一种变量类型。

综上，这个历史日志查询其实就是一个集大成者。

6. 历史权限查询

这个是用来查询流程或者任务的处理人，例如查询流程的处理人，方式如下：

@Test
void test11() {
    HistoricProcessInstance pi = historyService.createHistoricProcessInstanceQuery().singleResult();
    List<historicidentitylink> links = historyService.getHistoricIdentityLinksForProcessInstance(pi.getId());
    for (HistoricIdentityLink link : links) {
        logger.info("userId:{}",link.getUserId());
    }
}

这个是查询流程对应的处理人，对应的 SQL 如下：

select * from ACT_HI_IDENTITYLINK where PROC_INST_ID_ = ?

如果想查询任务的处理人，对应的方式如下：

@Test
void test12() {
    String taskName = "提交请假申请";
    HistoricTaskInstance hti = historyService.createHistoricTaskInstanceQuery().taskName(taskName).singleResult();
    List<historicidentitylink> links = historyService.getHistoricIdentityLinksForTask(hti.getId());
    for (HistoricIdentityLink link : links) {
        logger.info("{} 任务的处理人是 {}",taskName,link.getUserId());
    }
}

这个查询对应的 SQL 如下：

select * from ACT_HI_IDENTITYLINK where TASK_ID_ = ?

和前面的相比，其实就多了一个查询条件 TASK_ID_。

7. 自定义查询 SQL

和前面讲的很多查询类似，当我们弄懂了每一个历史查询的 API 操作的是哪一个数据表，就会发现，历史数据的查询，也可以自定义 SQL。

举个例子和小伙伴们看下，例如查询某一个流程已经执行完毕的历史任务：

@Test
void test13() {
    List<historicprocessinstance> instanceList = historyService.createHistoricProcessInstanceQuery().list();
    for (HistoricProcessInstance hpi : instanceList) {
        List<historictaskinstance> list = historyService.createNativeHistoricTaskInstanceQuery()
                .sql("SELECT RES.* from ACT_HI_TASKINST RES WHERE RES.PROC_INST_ID_ = #{pid} and RES.END_TIME_ is not null order by RES.ID_ asc")
                .parameter("pid",hpi.getId()).list();
        for (HistoricTaskInstance hti : list) {
            logger.info("name:{},assignee:{},createTime:{},endTime:{}", hti.getName(), hti.getAssignee(), hti.getCreateTime(), hti.getEndTime());
        }
    }
}

flowable 底层是 MyBatis，所有 SQL 中参数的传递形式和 MyBatis 一致。

8. 历史数据记录级别

Flowable 需要记录哪些历史数据，有一个日志级别用来描述这个事情，默认有四种级别：

None: 这个表示不存储任何历史信息，好处是流程执行的时候效率会比较快，坏处是流程执行结束后，看不到曾经执行过的流程信息了。
Activity: 这个会存储所有流程实例和活动实例，在流程实例结束时，顶级流程实例变量的最新值将复制到历史变量实例中，不会存储详细信息。
Audit: 在 Activity 的基础上，还会存储历史详细信息，包括权限信息等。默认的日志记录级别即次。
Full: 这个是在 Audit 的基础上，还会存储变量的变化信息，这会记录大量的数据，也会导致流程执行变慢。

一共就这四种级别，在 Spring Boot 项目中，如果我们想要配置这个日志记录的级别，其实非常方便，直接在 application.properties 中进行配置即可，如下：

flowable.history-level=none

配置加了这个配置，我们随便启动一个流程，然后去查询 ACT_HI_ 系列的表，发现都是空的，没有数据。

如果我们将历史日志记录的级别改为 activity，那么就会记录下来流程信息以及活动信息，但是像执行的 Task 这些信息都是没有的（ACT_HI_TASKINST），包括流程参与者的信息（ACT_HI_IDENTITYLINK）等都不会记录下来。

如果我们将历史日志记录的级别改为 audit，则上面提到的这几种日志就都会记录下来。但是 ACT_HI_DETAIL 表还是空的，详细一个流程变量的变化过程不会被记录下来。

如果我们将日志记录级别改为 full，那么将会记录下更多的信息。ACT_HI_DETAIL 表中会记录下流程变量的详细信息。

整个过程我就不给小伙伴们演示了大家可以自行尝试。

好啦，关于历史数据的查询，松哥先和小伙伴们聊这么多～下篇文章我们继续～</historictaskinstance></historicprocessinstance></historicidentitylink></historicidentitylink></historicdata></historicvariableinstance></historicactivityinstance></historictaskinstance></historicprocessinstance></historictaskinstance></historicprocessinstance></historicprocessinstance>

微信关注我们

原文链接：https://my.oschina.net/lenve/blog/5589989

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Flowable 设置流程变量的四种方式

@[toc] 在之前的文章中，松哥也有和小伙伴们使用过流程变量，然而没有和大家系统的梳理过流程变量的具体玩法以及它对应的数据表详情，今天我们就来看看 Flowable 中流程变量的详细玩法。 1. 为什么需要流程变量首先我们来看看为什么需要流程变量。举一个简单的例子，假设我们有如下一个流程：这是一个请假流程，那么谁请假、请几天、起始时间、请假理由等等，这些都需要说明，不然领导审批的依据是啥？那么如何传递这些数据，我们就需要流程变量。 2. 流程变量的分类整体上来说，目前流程变量可以分为三种类型：全局流程变量：在整个流程执行期间，这个流程变量都是有效的。本地流程变量：这个只针对流程中某一个具体的 Task（任务）有效，这个任务执行完毕后，这个流程变量就失效了。临时流程变量：顾名思义就是临时的，这个不会存入到数据库中。在接下来的内容中，我会跟大家挨个介绍这些流程变量的用法。 3. 全局流程变量假设我们就是上面这个请假流程，我们一起来看下流程变量的设置和获取。 3.1 启动时设置第一种方式，就是我们可以在流程启动的时候，设置流程变量，如下： @Test void test...

2022-11-08

525

1. 无锁的概念在谈论无锁概念时，总会关联起乐观派与悲观派，对于乐观派而言，他们认为事情总会往好的方向发展，总是认为坏的情况发生的概率特别小，可以无所顾忌地做事，但对于悲观派而言，他们总会认为发展事态如果不及时控制，以后就无法挽回了，即使无法挽回的局面几乎不可能发生。这两种派系映射到并发编程中就如同加锁与无锁的策略，即加锁是一种悲观策略，无锁是一种乐观策略，因为对于加锁的并发程序来说，它们总是认为每次访问共享资源时总会发生冲突，因此必须对每一次数据操作实施加锁策略。而无锁则总是假设对共享资源的访问没有冲突，线程可以不停执行，无需加锁，无需等待，一旦发现冲突，无锁策略则采用一种称为CAS的技术来保证线程执行的安全性，这项CAS技术就是无锁策略实现的关键，下面我们进一步了解CAS技术的奇妙之处。 2. 什么是CAS CAS（Compare and Swap），即比较并替换，是用于实现多线程同步的原子指令。执行函数：CAS(V,E,N) 其包含3个参数 V表示要更新的变量 E表示预期值 N表示新值假定有两个操作A和B，如果从执行A的线程来看，当另一个线程执行B时，要么将B全部执行完...

2022-11-09

308

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。