1.工作流入门

夏天的味道٥

已于 2023-10-30 09:41:07 修改

阅读量242

点赞数

分类专栏： Flowable 学习文章标签： 1024程序员节 flowable spring boot

于 2023-10-24 10:22:25 首次发布

本文链接：https://blog.csdn.net/qq_42217906/article/details/131222295

版权

Flowable 学习专栏收录该内容

1 篇文章 0 订阅

订阅专栏

应公司诉求，最近需要做一个业务物料相关的主数据创建流程审批项目，思前想后，记得以前接触过Activiti但很久没有使用了，咨询身边朋友发现他们已不再使用Activiti了，而使用Flowable来代替了。查阅相关资料了解到，Flowable其实就是Activiti的衍生物。

flowable中文文档地址：https://tkjohn.github.io/flowable-userguide/#_introduction

1、为什么需要⼯作流

在任何行业和企业中，都有各种各样的流程，例如：

请假流程
报销流程
入职流程
离职流程
出差流程
等等……

就算你自己没有设计过工作流，那么你每天肯定也在使用各种流程。

2、工作流引擎使用场景

工作流在企业管理系统中是高频使用的功能，一个最常见的例子是请假加班申请与审批的过程。事实上，工作流引擎能支持的业务场景远远不止单据审批，几乎所有涉及到业务流转、多人按流程完成工作的场景背后都可以通过工作流引擎作为支撑。基于工作流引擎，可以搭建客户关系管理系统（CRM）、运输管理系统（TMS）、仓储管理系统（WMS）、财务费用系统等多种复杂业务系统。对于达到一定规模的企业，良好的 BPM（业务流程管理，Business Process Management）体系可以支持创建公司内横跨不同部门的复杂业务流程，既提高工作效率、又可推动企业规范化发展。

3、三⼤⼯作流

        ⼀个⽐较早的⼯作流是 jBPM，这是⼀个由 Java 实现的企业级流程引擎，是 JBoss 公司开发的产品之⼀。
        jBPM 的创建者是 Tom Baeyens，这个⼤佬后来离开了 JBoss，并加⼊到 Alfresco，并推出了基于 jBPM4 的开源⼯作流系统 Activiti，⽽ jBPM 则在后续的代码中完全放弃了 jBPM4 的代码。从这个过程中也能看出来，jBPM 在发展过程中，由于意⻅相左，后来变成了两个 jBPM 和 Activiti。
        然⽽戏剧的是，Activiti5 没搞多久，从 Activiti 中⼜分出来⼀个 Camunda，Activiti 继续发展，⼜从中分出来⼀个 Flowable 。。。
        j由于开发 jBPM、Activiti、Camunda 以及 Flowable 的⼈多多少少有⼀些关联性，让⼈不得不猜测意⻅相左拉⼀票⼈出来单⼲是他们的企业⽂化。所以现在市⾯上主流的流程引擎就⼀共有三个：

Activiti
Flowable
Camunda

这三个各有特点：

Activiti ⽬前是侧重云，他⽬前的设计会向 Spring Cloud、Docker 这些去靠拢。
Flowable 核⼼思想还是在做⼀个功能丰富的流程引擎⼯具，除了最最基础的⼯作流，他还提供了很多其他的扩展点，我们可以基于 Flowable 实现出许多我们想要的功能，这也是⼩伙伴们觉得 Flowable 使⽤复杂的原因之⼀。
Camunda 相对于前两个⽽⾔⽐较轻量级，Camunda 有⼀个⽐较有特⾊的功能就是他提供了⼀个⼩巧的编辑器，基于 bpmn.io 来实现的。如果你的项⽬需求是做⼀个轻巧的、灵活的、定制性强的编辑器，⼯作流是嵌⼊式的，那么可以选择 Camunda。

4、流程图

        上面提到过3种工作流，这三个不同的⼯作流画出来的流程图都是相同的。⼯作流程图这块其实有⼀个统⼀的标准，那就是 BPMN。BPMN 全称是 Business Process Model and Notation，中⽂译作业务流程模型和标记法。
        这是⼀套图形化表⽰法，⽤图形来表⽰业务流程模型。BPMN 最初由业务流程管理倡议组织（BPMI, Business Process Management Initiative）开发， BPMI 于 2005 年与对象管理组织（OMG, Object Management Group）合并，并于 2011 年 1 ⽉ OMG 发布 2.0 版本，同时改为现在的名称。
        ⼀句话，就是流程图这块有⼀个特别古⽼的规范，那就是 BPMN，⽽我们前⾯所说的⽆论是 Activiti、 Flowable 还是 Camunda，都是⽀持这个规范的，所以呢，⽆论你使⽤哪⼀个流程引擎，都可以使⽤同⼀套流程图。
在这里插入图片描述
从上图中可以看到，⼀个流程图中主要包含四⽅⾯的内容：

事件
连线
任务
⽹关

事件
⾸先在⼀个流程图中应该有开始事件和结束事件，也就是上图⼤家看到的两个圆圈。另外还有⼀些中间事件、边界事件等。举个中间定时事件的例⼦，⽐如⽤户下单之后，可以有⼀个中间定时事件，延迟 5 分钟发货。

连线
连线就是将事件、任务、⽹关等连在⼀起的线条，⼀般情况下就是普通连线，有的时候连线会有⼀些条件，如果经理审批通过，就载⼊图纸准备⽣产，如果经理审批不通过，就重新设计。

任务

接收任务

在上⾯的流程图中，等待准备⼯作完成这⼀项就是⼀个接收任务。这个任务⾥并不需要额外做什么事情，流程到这⼀步就⾃动停下来了，需要⼈⼯去点⼀下，推动流程继续向下执⾏。
发送任务

这个⼀般⽤来把消息发送给外部参与者。
服务任务

这个⼀般由系统⾃动完成，其实说⽩了就是我们的⼀个⾃定义类，可以在⼀个⾃定义类⾥边完成想要做的事情。
脚本任务

⼀个⾃动化活动。当流程执⾏到脚本任务时，⾃动执⾏相应的脚本。
业务规则任务

BPMN2.0 新引⼊⽤来对接业务规则引擎，业务规则任务⽤于同步执⾏⼀个或多个规则。
用户任务

⽤于为那些需要由⼈⼯参与者完成的⼯作建模。虽然细分类别很多，但是仔细看，其实这⼏种⼜可以归为两⼤类：

用户任务：表⽰⼈⼯要介⼊做的事情。⽐如同意与否，或者输⼊⼀些参数，要让⼈⼯完成任务，就需要⼀个表单系统，让⼈⼯输⼊数据，或者显⽰数据给⼈看，这也是为什么⽤⼾任务和表单系统结合在⼀起的原因，用户任务需要⽤户向引擎提交⼀个完成任务的动作，否则流程会暂停在这⾥等待。
服务任务：表⽰机器⾃动做的事情。调⽤服务的任务，这个服务可以是⼀个 Spring JavaBean，也可以是⼀个远程 REST服务，流程会⾃动执⾏服务任务。