01-工作流 workflow

title: 01-工作流 workflow
date: 2023-7-19 22:06:43
tags:
- Flowable

状态机解决流程问题

工作流:就是一个可以处理复杂情况的状态机。

例如,员工请假这个流程:首先员工提交请假申请,假设有项目经理进行审批,审批有两种结果:通过或者拒绝。

实现上面这个需求:

  1. 创建一张请假表,表中有员工的 id,请假的天数、请假的理由、项目经理的 id、请假的状态 status。
  2. 当员工请假的时候,就自动向这张表中添加一条记录。
  3. 然后,当项目经理登录到 OA 的时候,就来这张表中查询自己需要审批的请假申请,查到之后,可以选择批准或者拒绝。
  4. 接下来,员工登录之后,就可以查询到自己的请假申请的审批结果。

在这样的实现思路中,请假的流程我们是通过 status 这个字段来控制的。例如:

  • status=0:表示待审批
  • status=1:表示审批通过
  • status=2:表示拒绝

上面这个例子,status 就是状态码,通过这个字段的值来控制流程的状态,这种方式我们可以称之为使用状态机来解决流程问题,但是,这种思路,只能解决非常简单的流程问题。

一些复杂的流程

报销审批流程

01-工作流 workflow_第1张图片

在这个流程中,已经没法使用 status 去描述这个请假走到哪一步了。如果非要用 status,那么 status 可能会有很多取值:

  • 0:表示员工提交报销申请
  • 1:表示部门经理审批通过
  • 2:表示部门经理审批不通过,员工需要重新提交
  • 3:表示大区经理审批通过
  • 4:表示大区经理审批不通过
  • ...

笔记本电脑生产流程

01-工作流 workflow_第2张图片

这个流程中,不仅有串行任务,也有并行任务。虽然技术上来说,status 也还能做,但是,用 status 字段去描述这个流程,会非常非常复杂。

三大工作流

三大主流工作流,只要掌握其中一个,另外两个可以非常容易的上手。

最早的工作流是 jBPM,目前市面上大部分工作流的共同祖先。

  • Activiti:当 jBPM 发展到 jBPM4 这个版本的时候,内部发生了分歧,然后一波人出来单干,基于 jBPM4 开发出来了 Activiti5;留下来的人,继续开发 jBPM5 的时候,几乎完全重写了 jBPM4 的代码。目前 Activiti 的设计侧重于云,即更靠拢 Spring Cloud、Docker、K8s 等。
  • Flowable:Activiti5 在发展了一段时间之后,又从中分离出来一个团队,开发出来了 Flowable。Flowable 目前的核心思路还是做一个功能非常非常完善的流程引擎工具。除了常用的最最基本的工作流之外,Flowable 还提供了很多扩展点。
  • Camunda:Activiti5 发展没多久,从 Activiti5 中分离中的团队,开发的 Camunda。在这三个主流的流程引擎中,Camunda 是最为轻量级的一个,如果我们的系统,当用户在使用的过程中,需要动态的绘制流程图,那么可以使用 Camunda,这是一个小巧的工具,可以非常的方便的嵌入到我们自己的系统中。Camunda 还提供了一个 bpmn.js 的工具,可以非常方便的实现流程图的绘制。

流程图

工作流执行的基础是流程图。

一个完整的流程,要干嘛,先得画出来一个完整的流程图。

上面介绍了三种不同的工作流,那么三种不同的工作流的流程图绘制方式是否一样?

其实,流程图的绘制,有一套统一的标准:BPMN(Business Process Model And Notation),中文译作业务流程模型和标记法。

BPMN 就是一套图形化表示法,用图形来绘制、梳理业务流程模型。就是说,BPMN 其实是一套非常古老的流程图规范,Activiti、Flowable 以及 Camunda 都是支持这个规范的。所以,无论使用哪一个流程图,都可以依照 BPMN 规范去绘制流程图。

虽然 BPMN 大家都支持,但是,在具体的使用细节上,不同的流程引擎还是有差别的。

BPMN 流程图绘制规范

01-工作流 workflow_第3张图片

从上图中,大致上可以归类出,流程分为:

  • 事件
  • 连线
  • 任务
  • 网关

事件:

开始事件/结束事件等等。

01-工作流 workflow_第4张图片

这是我们上面用到的事件,实际上,还有很多其他类型的事件。

01-工作流 workflow_第5张图片

连线:

01-工作流 workflow_第6张图片

连接各个不同元素之间的线条,就是连线。

注意,线条之上,可能会有条件。例如,在互斥网关上,满足一定的条件,流程图就继续往下走,不满足条件,流程图就回到之前的某一个位置上。

任务:

在上面的流程图中,所有的矩形,都是任务,但是任务还有很多细分。

  • 用户任务

需要人工参与完成的工作建模。

01-工作流 workflow_第7张图片

  • 服务任务

机器自动完成的事情,例如用户请假,经理审批通过,审批通过之后,想通过企业微信给用户发送一个通知,告诉他请假通过。这样的任务,可以使用服务任务,当流程走到这一步的时候,自动调用某一个 Java Bean,或者某一个远程服务去完成通知的发送,这是自动完成的,不需要人工介入。

01-工作流 workflow_第8张图片

  • 活动

活动可以算是一种特殊的任务。活动之中,往往可以在活动中,调用另外一个流程使之作为当前流程的子流程去执行。活动一般又可以继续细分为用户活动、脚本活动等等...

01-工作流 workflow_第9张图片

  • 接收任务

这个接收任务中,其实并不需要做什么额外的事情,流程到这一步就自动停下来,需要人工去助力一把,去推动流程继续向下走。

01-工作流 workflow_第10张图片

  • 发送任务

将消息发送给外部的参与者。

01-工作流 workflow_第11张图片

  • 脚本任务

一个自动化的活动,当流程执行到脚本任务的时候,自动执行相应的脚本。

01-工作流 workflow_第12张图片

  • 业务规则任务

BPMN2.0 中引入的用来对接业务规则的引擎,业务规则主要用于同步执行一个或者多个规则。

01-工作流 workflow_第13张图片

虽然这里分类比较多,但是实际上,任务主要就两种:

  1. 用户任务:需要用户介入的任务。
  2. 服务任务:机器自动完成的任务。发送任务、接收任务、脚本任务等等,这些其实都是服务任务的细分而已。

网关:

  • 互斥网关

这个可以有多个入口,但是只有一个有效的出口。

01-工作流 workflow_第14张图片

  • 并行网关

并行网关一般是成对出现的,当有并行操作的时候,可以使用并行网关。

01-工作流 workflow_第15张图片

  • 相容网关

这种网关可能会存在多个有效的出口。

01-工作流 workflow_第16张图片

  • 事件网关

通过中间事件驱动的网关,当等待的事件触发之后,才会触发决策。

01-工作流 workflow_第17张图片

你可能感兴趣的:(01-工作流 workflow)