我更新了几篇关于可流动宋歌的文章，但是考虑到我的一些朋友可能从来没有接触过流程引擎，我再和朋友们梳理一些基本内容。
1. 为什么需要工作流
在宋歌将前一篇文章转发到朋友圈后，一些朋友评论说，他们从来不明白为什么需要工作流。今天，我们先来谈谈这个话题。
假设我有一个请假的请求，流程如下:
休假可以提交给我的老板，老板可以选择批准或拒绝，并会给我一个批准或拒绝的通知。
这个流程比较简单，我们很容易想到解决方案，不需要工作流就可以解决。有一种特殊的休假形式。当A想休假时，休假表单中会添加一条记录。该记录的内容包括休假天数、原因、休假审批人B和一个名为status的字段。此状态字段指示休假申请的当前状态(待批、已批准或已拒绝)。然后，B登录系统后，在休假表中找到A的休假信息，然后选择批准。此时，只需更改状态字段的值。
这个过程很简单，相信朋友们都能想到。
然而，这是一个非常简单的过程。一般来说，这样的流程确实没有必要使用工作流，但是现实中，我们涉及到的工作流往往非常复杂。我举个例子，先说报销审批，可能很多小伙伴都经历过。
小伙伴们看到这个过程相对复杂。这时候如果用一个状态字段来形容，就不好说是怎么回事了。批准的每一步都可能被批准或拒绝。拒绝并不意味着过程的结束。员工修改后可以继续提交报销材料。这时候如果还用status来描述，那么status就会有n个以上的值来代表不同的情况，维护起来非常不方便。
很复杂吗？不，我们来看另一个生产笔记本电脑的例子。假设公司开发一款新的笔记本电脑，从研发到生产的整个过程可能是这样的:
和上面两个相比，这个稍微复杂一点。不仅有串行任务，还有并行任务。如何设计这样的系统？仅仅通过状态字段来描述系统显然是不够的。这个时候我们就不得不考虑一个通用的，更易维护的方案来实现这样一个系统，这就是工作流。
2. 三大工作流
早期的一个工作流是PM，是Ja实现的企业级流程引擎，也是oss开发的产品之一。
PM的创始人是Tom Baeyens，他后来离开oss加入Alfresco，推出了基于PM4的开源工作流系统Activiti，而PM在后续的代码中完全抛弃了PM4的代码。从这个过程也可以看出，PM在开发过程中由于观点不同，变成了两个PM和Activiti。
然而，戏剧性的是，activity 5并没有持续多久，然后一个卡蒙达就从Activiti中分离出来了。Activiti继续发展，从其中分离出一种流动体。。。
因为开发PM、Activiti、Camunda、flow的人或多或少都有关联，所以让人不得不猜测，拉一群不同意见的人单干是他们的企业文化。
因此，现在市场上有三种主流流程引擎:
ActivitiFlowableCamunda
这三者各有特点:
Activiti 目前是侧重云，他目前的设计会向 Spring Cloud、Docker 这些去靠拢。Flowable 核心思想还是在做一个功能丰富的流程引擎工具，除了最最基础的工作流，他还提供了很多其他的扩展点，我们可以基于 Flowable 实现出许多我们想要的功能（当然这也是小伙伴们觉得 Flowable 使用复杂的原因之一）。Camunda 相对于前两个而言比较轻量级，Camunda 有一个比较有特色的功能就是他提供了一个小巧的编辑器，基于 bpmn.io 来实现的（松哥之前已经发文讲过了）。如果你的项目需求是做一个轻巧的、灵活的、定制性强的编辑器，工作流是嵌入式的，那么可以选择 Camunda。
如果仔细对比这三者的区别，可以做一个长表，这个网站已经有很多人总结过了，这里宋哥就不多赘述了。
3. 流程图
既然有三个不同的工作流程，那么三个不同的工作流程画出来的流程图是不是不一样？
不是这样的。
实际上，工作流程图有一个统一的标准，那就是BPMN。BPMN的全称是business process model and notation，中文翻译成business process model and notation。这个中国人太拐弯抹角了，就简称BPMN吧。
这是一组图形表示，它使用图形来表示业务流程模型。BPMN最初是由业务流程管理倡议(BPMI)开发的，BPMI在2005年与对象管理集团(OMG)合并。2011年1月，OMG发布了2.0版本，并更改了现在的名称。
总之，流程图有一个特别老的规范，那就是BPMN，还有我们前面说的，不管是Activiti，flow还是Camunda，都支持这个规范，所以不管你用哪个流程引擎，都可以用同一套流程图。
那么这个规范到底说了什么呢？
下面以上面的笔记本生产流程图为例，给朋友们简单介绍一下:
从上图可以看出，流程图主要包括四个方面:
事件连线任务网关
一个一个说吧。
事件
首先，一个流程图中应该有一个开始事件和一个结束事件，也就是你上图看到的两个圆圈。还有一些中间事件和边界事件。举一个中间定时事件的例子。例如，在用户下订单后，可能会有一个延迟交付5分钟的中间计时事件。
环
连接是连接事件、任务、网关等的线。一般是普通连接。有时有一些连接的条件，如宋歌在他的前一篇文章中分享的休假。如果经理同意请假申请，他会走哪条线。如果经理不同意请假申请，他会走哪条线。对于上图对应的笔记本生产，如果经理认可，就加载图纸进行生产，如果经理不认可，就重新设计。
工作
任务其实有很多种分类。
如果细分可以大致分为以下几类:
接收任务
在上面的流程图中，等待准备工作完成是一个接收任务。在这个任务中不需要做任何额外的事情。此时进程会自动停止，需要手动点击才能推动进程继续向下。
发送任务
这通常用于向外部参与者发送消息。
服务任务
这通常由系统自动完成。其实说白了就是自定义类，在自定义类里我们可以做自己想做的事情。
脚本任务
自动化活动。当流程执行到脚本任务时，自动执行相应的脚本。
业务规则任务
新引入BPMN2.0连接业务规则引擎，业务规则任务用于同步执行一个或多个规则。
用户任务
用于对需要由人类参与者完成的工作进行建模。
虽然有很多子类别，但是如果你仔细看，其实这些类别可以分为两类:
用户任务：表示人工要介入做的事情。比如同意与否，或者输入一些参数，要让人工完成任务，就需要一个表单系统，让人工输入数据，或者显示数据给人看，这也是为什么用户任务和表单系统结合在一起的原因，用户任务需要用户向引擎提交一个完成任务的动作，否则流程会暂停在这里等待。服务任务：表示机器自动做的事情。调用服务的任务，这个服务可以是一个 Spring JaBean，也可以是一个远程 REST 服务，流程会自动执行服务任务。
活动
活动可以被视为一项特殊的任务。活动可以调用另一个流程作为当前流程的子流程运行。活动还可以分为用户活动、脚本活动等等。在显示方面，活动比任务边界更深。仅此而已。
门
如果对网关进行细分，有许多不同类型的网关。
互斥网关
这种网关也被称为专用网关。我们之前请假流程中的网关是专属网关。这个入口只有一个有效出口。
相容网关
这个网关会有多个出口，只要满足条件就会实现。
事件网关
事件网关由中间事件驱动，只有在等待事件发生后才会触发决策。基于事件的网关允许基于事件做出决策。
并行网关
并行网关通常成对出现。在上面生产笔记本的过程中，通过并行网关实现了生产屏幕、键盘等并行操作。
这些是关于流程引擎的一些基本概念。理顺了这些基本概念之后，我们再回头看之前关于流程引擎的文章，应该会有一些不同的理解:
Spring Boot 整合流程引擎 Flowable，so easy！SpringBoot+Vue+Flowable，模拟一个请假审批流程！49张图带领小伙伴们体验一把 Flowable-UISpring Security + Vue + Flowable 怎么玩？
免责声明：本站所有文章内容,图片，视频等均是来源于用户投稿和互联网及文摘转载整编而成，不代表本站观点，不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益，请在线联系站长,一经查实,本站将立刻删除。
