工作流:就是一个可以处理复杂情况的状态机。
例如,员工请假这个流程:首先员工提交请假申请,假设有项目经理进行审批,审批有两种结果:通过或者拒绝。
实现上面这个需求:
在这样的实现思路中,请假的流程我们是通过 status 这个字段来控制的。例如:
上面这个例子,status 就是状态码,通过这个字段的值来控制流程的状态,这种方式我们可以称之为使用状态机来解决流程问题,但是,这种思路,只能解决非常简单的流程问题。
报销审批流程
在这个流程中,已经没法使用 status 去描述这个请假走到哪一步了。如果非要用 status,那么 status 可能会有很多取值:
笔记本电脑生产流程
这个流程中,不仅有串行任务,也有并行任务。虽然技术上来说,status 也还能做,但是,用 status 字段去描述这个流程,会非常非常复杂。
三大主流工作流,只要掌握其中一个,另外两个可以非常容易的上手。
最早的工作流是 jBPM
,目前市面上大部分工作流的共同祖先。
工作流执行的基础是流程图。
一个完整的流程,要干嘛,先得画出来一个完整的流程图。
上面介绍了三种不同的工作流,那么三种不同的工作流的流程图绘制方式是否一样?
其实,流程图的绘制,有一套统一的标准:BPMN(Business Process Model And Notation),中文译作业务流程模型和标记法。
BPMN 就是一套图形化表示法,用图形来绘制、梳理业务流程模型。就是说,BPMN 其实是一套非常古老的流程图规范,Activiti、Flowable 以及 Camunda 都是支持这个规范的。所以,无论使用哪一个流程图,都可以依照 BPMN 规范去绘制流程图。
虽然 BPMN 大家都支持,但是,在具体的使用细节上,不同的流程引擎还是有差别的。
从上图中,大致上可以归类出,流程分为:
事件:
开始事件/结束事件等等。
这是我们上面用到的事件,实际上,还有很多其他类型的事件。
连线:
连接各个不同元素之间的线条,就是连线。
注意,线条之上,可能会有条件。例如,在互斥网关上,满足一定的条件,流程图就继续往下走,不满足条件,流程图就回到之前的某一个位置上。
任务:
在上面的流程图中,所有的矩形,都是任务,但是任务还有很多细分。
需要人工参与完成的工作建模。
机器自动完成的事情,例如用户请假,经理审批通过,审批通过之后,想通过企业微信给用户发送一个通知,告诉他请假通过。这样的任务,可以使用服务任务,当流程走到这一步的时候,自动调用某一个 Java Bean,或者某一个远程服务去完成通知的发送,这是自动完成的,不需要人工介入。
活动可以算是一种特殊的任务。活动之中,往往可以在活动中,调用另外一个流程使之作为当前流程的子流程去执行。活动一般又可以继续细分为用户活动、脚本活动等等...
这个接收任务中,其实并不需要做什么额外的事情,流程到这一步就自动停下来,需要人工去助力一把,去推动流程继续向下走。
将消息发送给外部的参与者。
一个自动化的活动,当流程执行到脚本任务的时候,自动执行相应的脚本。
BPMN2.0 中引入的用来对接业务规则的引擎,业务规则主要用于同步执行一个或者多个规则。
虽然这里分类比较多,但是实际上,任务主要就两种:
网关:
这个可以有多个入口,但是只有一个有效的出口。
并行网关一般是成对出现的,当有并行操作的时候,可以使用并行网关。
这种网关可能会存在多个有效的出口。
通过中间事件驱动的网关,当等待的事件触发之后,才会触发决策。