Activity探究上

最新推荐文章于 2022-03-31 16:25:39 发布

不混吃的熊

最新推荐文章于 2022-03-31 16:25:39 发布

阅读量203

点赞数

CC 4.0 BY-SA版权

本文链接：https://blog.csdn.net/weixin_42676300/article/details/106759865

本文深入探讨了工作流引擎的概念，对比了Activity与传统流的区别，介绍了JBPM、Activity、JFlow和Flowable等常见工作流引擎，并详细解析了Activiti框架的结构与使用方法，包括流程部署、实例化、任务分配及历史信息查询等关键环节。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Activity与传统流的差别

先下个定义，对于工作流引擎。
定义：抽离了审批过程的服务于业务的，使代码员更易于操作流的一种可视化，流程编辑工具。

虽然工作中用到的是一个jflow但是我想Activity和jflow应该是一样的吧，手头只有Activity的教程，就将就着用了。

介绍一些常用的工作引擎：

JBPM（Java Business Process Management）
Activity
JFlow made in China
Flowable

百度这么发达，就不一一去介绍什么优劣点了。知道有这么几个就好了。我用的就是Activity这些框架不理解原理是用不起来的。先讲一下流的概念。
事务流，就是我们日常理解的流程，比如去街道办办个事，或者是结婚离婚，首先需要拍照，复印身份证，还有两个人在场，最后是盖章。每一个步骤负责的人不一样，但是有一个既定的流程。这就是事务流的概念。
举一个很久以前听过的例子，学生请假。
假定学生表和老师表已经建好，假定学生请假老师同意就好了，当然大多数学校也是这样操作的。
然后我们站在业务的角度去分析这个过程的设计。
首先学生提交假条，由老师审批
过程涉及两个部分
学生提交假条
老师审批

要求，学生必须提交老师才能看到。
学生能看到审批到哪了。
首先需要一个权限表，得知道那个学生是哪个老师负责的吧。
然后每次申请流程的时候根据表主动注入到负责人。
申请审核表的结构应该是
String Teacher_id
String student_id
String reason_context
Int event_states 默认0为编辑 1为发起 2为同意 3为不同意
建立起一个建议的流程结构
请假的时候当提交之后每次执行

Select * from __ where Teacher_id=__ and states=1

此时即为老师所能查看到的节点。
学生查看

Select * from __ where stuendt_id=__

即可查看到制定流程
具体的流程操作应该是可以想象的，这样操作问题会比较多。
比如流程更改，那么数据库第一个就要充电，就是预留了足够多的states来描述各级审批事件，那么后端源码也是需要大量的对应业务是更改的。后端和前端还要以此去一步步更改。
如果我们能把流程抽离出来，这样我们只需要关注权限的映射而绝非流程的过程。这样是不是可以把一大堆琐碎的事情解决掉。于是出现了一系列的流程引擎。而activity不能说是佼佼者，但是也是TOP中的一位。其他的大体设计思路也雷同，就用Activity去讲解这个流程引擎是一个什么东东。

Activity 的历史

我学习的逻辑往往是，原因，过程，结果。使用，结构。缺了那块都不是很舒服。
所以我们来讲讲activity的往日今生。往往里面会有一些有意思的故事。
概要
Activiti是由Alfresco软件在2010年5月17日发布的业务流程管理(BPM)框架,它是覆盖了业务流程管理，工作流，服务协作等领域的一个开源，灵活的，易扩展的可执行流程语言框架。
　　 Activiti基于Apache许可的开源BPM平台，创始人Tom Baeyens是JBoss JBPM的项目架构师，它的特色是提供了eclipse插件，开发人员可以通过插件直接绘画出业务流程图。
可以看出来，估计是不开心了，于是开源了的故事。果然程序员是最任性的工作者之一，不过如果不任性，估计很多很开心的东西就出不来了，比如说火狐等等。想象是因为用能力了才任性还是任性一直就带着，渐渐地就有能力了。我想后者可能性大一点，所以推荐程序猿门都任性一点，可能能力就慢慢提起来了。因为能在任性的前提下苟住，已经能说明很多问题了。
在任何一个新建的Activity引擎下，都会新建25个表，表都是以act_**_**作为表名。先讲解一下这些表结构。
Activiti表说明
　　1，流程部署相关表：
　　　　act_re_deployement 部署对象表
　　　　act_rep_procdef 流程定义表
　　　　act_ge_bytearray 资源文件表
　　　　act_ge_prperty 主键生成策略表（对于部署对象表的主键ID）
　　2，流程实例相关表:
　　　　act_ru_execution 正在执行的执行对象表（包含执行对象ID和流程实例ID，如果有多个线程可能流程实例ID不一样）
　　　　act_hi_procinst 流程实例历史表
　　　　act_hi_actinst 存放历史所有完成的任务
　　3，Task 任务相关表:
　　　　act_ru_task 代办任务表（只对应节点是UserTask的）
　　　　act_hi_taskinst 代办任务历史表（只对应节点是UserTask的）
　　　　act_hi_actinst 所有节点活动历史表（对应流程的所有节点的活动历史，从开始节点一直到结束节点中间的所有节点的活动都会被记录）
　　4，流程变量表：
　　　　act_ru_variable 正在执行的流程变量表
　　　　act_hi_variable 流程变量历史表
在表建立之后如何使用引擎和使用表
在这里插入图片描述
配置文件，构造器，基类，衍生子类的结构。也就是我们用啥，那就是基类。图示的基类，就很明显是ProcessEngine去描述流程控制的关键核心。
而如何拿到这个核心，将作为这块编程的第一个部分。
//用法
ProcessEngine processEngine = ProcessEngines.getDefaultProcessEngine();
基于此之上的操作，即为每个服务去精确处理的一块。可以对应着服务去看看表，基本不是一对一就是一对多。简单的来说就是每一个衍生服务，都是对抽象的具象化的一个概念去搞出来的这个框架。最值得一提的还是它的这种抽离的思想，我觉着就是AOP的一个具体实例，这种理念是真的好。一步步再解放程序员。如果往下细究，每一个服务本身都应该封装了一些实体，都是有一个完整的ORM过程，去对应的增删查改。这里就是用用，理解一下，就不往下解析源码了。
在这里插入图片描述
为了更精确的拆解到每一个细分点，我做了一个上图所示的思维导图。
从服务本身到流程的生命周期。做了一个简化的示意图。
第一个部分先到这里，第二个部分开始讲解如何快速建造一个流程引擎，此后基于的项目一开始都是基于maven进行处理的。
　2，RepositoryService
　　说明：Activiti的仓库服务类。所谓的仓库指流程定义文档的两个文件：bpmn文件和流程图片该service可以用来删除部署的流程定义
　　3，RuntimeService
　　说明：Activiti的流程执行服务类，可以从这个服务类中获取很多关于流程执行的相关的信息。
　　4，TaskService
　　说明：是Activiti的任务服务类。可以从这个类中获取任务的相关信息，如当前正在执行的个人待办和用户组待办任务。
　　5，HistoryService
　　说明：Activiti的查询历史信息的类，在一个流程执行完成后，这个对象为我们提供查询历史信息，可以跟踪流程实例对应所有待办节点的运行情况。
　　6，ProcessDefinition
　　说明：流程定义类，可以从这里获得资源文件等。
　　7，ProcessInstance
　　说明：代表流程定义的执行实例，当一个部署的流程图启动后，该流程只有一条流程实例数据，但是它的流程任务可以有多个，
　　每个任务对应流程图中相应的流程节点。

先看，细细认识一下这些子类。