关于Flowable宋哥更新了好几篇文章，但是考虑到有的朋友可能没有接触过流程引擎，所以我有一些基础的内容，回来和朋友们整理一下出去。1.为什么需要工作流？宋哥把之前的文章转发到朋友圈后，有小伙伴评论说一直不明白为什么要工作流。今天我们就先来说说这个话题。假设我有一个请假申请，流程是这样的：请假可以提交给我的老板，老板可以选择批准或者拒绝，不管是批准还是拒绝都会给我一个通知。这个过程比较简单，我们也很容易想到解决方案。它可以在没有工作流程的情况下解决。有一个特殊的请假表格。当A要请假时，他会在请假单上添加一条记录。这条记录的内容包括请假天数、请假原因、请假审批人B和一个名为status的字段，该status字段表示请假申请的当前状态（待审批、已批准或已拒绝），然后B登录后系统，在请假单中查询到A的请假信息，然后选择批准，然后修改status字段的值即可。这个过程很简单，相信你也能想到。然而，这是一个非常简单的过程。一般来说，这样的流程确实没有必要使用工作流，但在现实中，我们涉及到的工作流往往非常复杂。我给大家举个例子，就说Reimbursementapproval吧，这个可能很多朋友都会遇到。朋友们可以看出这个过程比较复杂。这时候如果用状态字段来描述，就很难说是怎么回事了。每个批准步骤都可能被批准或拒绝。拒绝并不意味着流程的结束。员工修改报销信息后，可以继续提交。如果这时候还用status来描述，那么status就会有N多个值来表示不同的情况，维护起来很不方便。这很复杂吗？不，让我们看另一个生产笔记本电脑的例子。假设公司开发了一种新型笔记本电脑。有串行任务也有并行任务，这样的系统怎么设计？简单的通过status字段来描述显然是不够的。这时候，我们就不得不考虑一个通用的、更容易维护的方案来实现这样的系统。这种通用且易于维护的解决方案就是工作流。2、三大工作流一个比较早的工作流是jBPM，它是一个用Java实现的企业级流程引擎，是JBoss开发的产品之一。jBPM的创建者是TomBaeyens，他后来离开了JBoss加入了Alfresco，推出了基于jBPM4的开源工作流系统Activiti，而jBPM在后续的代码中完全抛弃了jBPM4的代码。从这个过程也可以看出，在jBPM的发展过程中，由于意见不合，后来变成了jBPM和Activiti两个。然而，戏剧性的是，Activiti5没干多久，又一个Camunda从Activiti中分离出来，而Activiti继续发展，又从中分离出一个Flowable。..由于开发jBPM、Activiti、Camunda、Flowable的人都或多或少有关联，所以不得不让人猜测是他们的企业文化，各执一词，拉着一群人单独干活。所以现在市面上主流的流程引擎有3种：ActivitiFlowableCamunda这三种各有特点：Activiti目前主打云，目前的设计会向SpringCloud和Docker靠拢。Flowable的核心思想仍然是做一个功能丰富的流程引擎工具。除了最基本的工作流程外，它还提供了很多其他的扩展点。我们可以基于Flowable实现很多我们想要的功能（当然这也是小伙伴觉得Flowable使用复杂的原因之一）。与前两者相比，Camunda相对轻巧。Camunda的一大特色是提供了一个基于bpmn.io的小编辑器（松哥之前已经发过）。如果您的项目要求是一个轻量级、灵活且高度可定制的具有嵌入式工作流程的编辑器，您可以选择Camunda。如果仔细比较这三者的区别，就可以做出一张长桌。网上很多人都总结过了，宋哥这里就不赘述了。3、既然流程图中存在三种不同的工作流程，那么这三种不同的工作流程绘制的流程图是否不同？不。工作流程图其实有一个统一的标准，就是BPMN。BPMN的全称是BusinessProcessModelandNotation，中文翻译为业务流程模型和表示法。这个中文太绕了，所以简称为BPMN。这是一组以图形方式表示业务流程模型的图形符号。BPMN最初是由业务流程管理倡议组织（BPMI，BusinessProcessManagementInitiative）开发的。BPMI于2005年与对象管理组（OMG，ObjectManagementGroup）合并，OMG于2011年1月发布2.0版本，同时更改为现在的名称。总之，流程图有一个特别古老的规范，就是BPMN，而我们前面说的，无论是Activiti、Flowable还是Camunda，都支持这个规范，所以不管你用哪个流程引擎，都可以使用同一组流程图。那么这个规范到底是怎么说的呢？下面以上面笔记本制作流程图为例，给小伙伴们简单介绍一下：从上图可以看出，一张流程图主要包括四个方面：事件连接任务网关下面一一说说。事件在流程图中首先应该有一个开始事件和一个结束事件，也就是你在上图中看到的两个圆圈。此外，还有一些中间事件、边界事件等。以中间计时事件为例。例如，用户下单后，可以有一个延迟5分钟发货的中间定时事件。Connection连接是连接事件、任务、网关等的线，一般是普通连接，有时候连接也是有一些条件的，比如上一篇宋哥分享的请假，如果经理同意休假申请，以哪一行为准，如果经理不同意休假申请，以哪一行为准。对应上图的笔记本生产，如果经理批准，就加载图纸准备生产，如果经理不批准，就重新设计。实际上有很多类别的任务。如果再细分的话，大致可以分为以下几种：接收任务在上面的流程图中，等待准备工作完成就是一个接收任务。这个任务不需要做任何额外的事情，流程会自动停在这一步，需要手动点击推动流程继续往下走。发送任务这通常用于向外部参与者发送消息。服务任务一般由系统自动完成。其实就是我们的自定义类，可以在自定义类中完成你想做的事情。脚本任务是一种自动化活动。当进程执行到一个脚本任务时，相应的脚本会自动执行。BPMN2.0新引入业务规则任务，与业务规则引擎对接，业务规则任务用于同步执行一条或多条规则。用户任务用于模拟需要由人类参与者完成的工作。虽然细分的种类很多，但如果仔细看，这些类型可以归为两类：用户任务：表示需要人类干预去做的事情。比如是否同意，或者输入一些参数。为了让人类完成任务，需要一个表单系统来让人类输入数据或显示数据以供人们查看。这就是将用户任务和表单系统结合在一起的原因。用户任务用户需要向引擎提交一个动作来完成任务，否则流程会在这里暂停等待。服务任务：表示机器自动完成的事情。调用服务的任务，这个服务可以是SpringJavaBean，也可以是远程REST服务，进程会自动执行服务任务。活动活动可以被认为是一种特殊的任务。一个活动可以调用另一个进程作为当前进程的子进程运行。活动还可以分为用户活动、脚本活动等。从视觉上看，活动的边框比任务的边框深。就这样。网关如果把网关细分的话，网关有很多种。互斥网关这种网关也称为互斥网关。我们之前的请假流程中的网关是互斥网关。该网关只有一个有效出口。兼容网关这种网关有多个出口，只要满足条件，都会执行。事件网关事件网关由中间事件驱动，等待事件发生后触发决策。基于事件的网关允许根据事件做出决策。并行网关并行网关一般成对出现。上述生产笔记本的过程中，生产屏幕、键盘等并行操作是通过并行网关实现的。嗯，这是关于流程引擎的一些基本概念。理清了这些基本概念之后，再回顾一下我们之前关于流程引擎的文章，应该会有一些不同的理解：SpringBoot集成流程引擎Flowable，soeasy！SpringBoot+Vue+Flowable，模拟一个请假审批流程！49图带领小伙伴体验Flowable怎么玩——UISpringSecurity+Vue+Flowable？
