BPMN2.0协议解析

2021年9月21日 3点热度 0条评论 来源: 廖先贵

1      BPMN的历史背景

BPMN(Business Process Model and Notation),业务流程建模和标注。 Notation是BPMN的核心,即使用图形来表达业务流程。另外,BPMN是由OMG组织维护的一个公开的标准,与任何特定商业组织或工具是没有关系,无需为此付费。BPMN和传统的流程图的区别如下:

  • BPMN是一个正式的规范,各种图标、元件是有准确的含义和使用规范
  • BPMN可以描述基于事件触发的行为,比如响应超时、外部系统无法提供服务等

BPMN 标准发展版本历史如下。BPMN2.0在1.x基础上新增了元模型、存储、交互、执行。

版本号

发布时间

1.0

2007年3月

1.1

2008年1月

1.2

2009年1月

2.0

2011年1月

BPMN1.x被大多数的建模工具和BPMS厂商所支持。但是, BPMN1.x只是一些建模符号,不支持元模型,不支持存储和交换,也不支持执行。那么围绕着BPMN1.x的存储、交换和执行,必然会产生新的竞争,这次的主角换成了XPDL、BPEL和BPDM。

XPDL作为WfMC(工作流管理联盟)提出的流程定义语言规范,本身就是一个元模型,可以存储,并且具备执行语义。如今有超过80个的不同公司的产品使用XPDL来交换流程定义,同时也有一些厂商在自己提供的BPMN工具中使用了XPDL作为交换和存储格式。

为了抗衡XPDL,OASIS组织(包括几个大的平台公司,Microsoft、 BEA、 IBM、 SAP 、Sun、Oracle)开发了BPEL规范。但BPMN到BPEL的转换存在着先天上的缺陷,原因是BPMN是基于图的,而BPEL是基于块的。这个缺陷导致有些BPMN建模的流程无法映射到BPEL,两者的双向工程更是存在问题。这个缺陷成为人们反复诟病的对象。许多支持BPEL的产品为了解决这一问题,不得不在用户建模时做出种种限制,让用户绘制不出无法转换的模型。

而BPDM(业务流程定义元模型)则是OMG组织自己提出来解决BPMN存储和交换问题的规范。于2007年7月形成初稿,2008年7月被OMG最终采用。BPDM是一个标准的概念定义,用来表达业务流程模型。元模型定义了用来交换的概念,关系和场景,可以使得不同的建模工具所建模出来的流程模型进行交换。BPDM超越了BPMN和BPEL所定义的业务流程建模的要素,它定义了编排和编制。

三者的竞争关系似乎还将继续,但,BPMN2.0出现了。BPMN2.0相比BPMN1.x,最重要的变化在于其定义了流程的元模型和执行语义,即它自己解决了存储、交换和执行的问题,BPMN由单纯的业务建模重新回归了它的本源,即作为一个对业务人员友好的标准流程执行语言的图形化前端。BPMN2.0一出手,竞争就结束了,XPDL、BPEL和BPDM各自准备回家钓鱼。看起来胜利者似乎是BPMN,但看看BPMN2.0的领导者,就会发现最后的胜利者还是IBM,Oracle和SAP这些大厂商们,他们提交的草案明确要赋予BPMN2.0以执行语义,这迫使BPDM团队撤回了其提交,并将他们的提议与BPDM团队想法合并,这就是BPMN2.0最后内容的由来。

BPMN官网:http://www.bpmn.org

2      BPMN的例子

本章使用一个简单的订单处理的业务流程为例,简要的说明BPMN的作用。

2.1    一个简单的订单流程

企业收到订单后,检查购买者的信用卡,执行订单,提供发票。如下图所示,圆形表示事件,第一个元件表示开始事件,最后一个元件表示结束事件,圆角矩形表示一个任务(task/activity),带箭头的实现表示顺序流(sequenceFlow)

2.2    异常和结束状态

上图只描述了正常的情况。信用卡过期,仓库无库存如何处理?所以业务流程图中应该新增其它异常分支。在BPMN中,使用菱形表示网关(gateway),用来控制流程中的流向。注意图中包含了三个结束事件,每个结束事件表示不同的结束状态。

2.3    泳道(swimlane)和执行者(performer)

泳道用来指明任务的执行者。如下图所示,销售人员接受订单,仓库执行执行订单,财务处理发票。注意不是所有的任务都会有执行者(更精确的说,只有user task才有执行者)。

2.4    子流程

执行订单是一个子流程,子流程必须有开始事件和结束事件,子流程内部的元件禁止和外部的元件直连,只能作为一个整体与父流程的元件相连接。

3      BPMN2.0中的基础元件

除了事件触发的行为,你几乎可以使用的本章节的元件创建所有的业务流程。

3.1    Activity

一个activity表示一份待完成的任务或工作,用圆角矩形表示。分为任务(task)和子流程(subprocess)。

3.1.1  任务

一个任务表示工作需要被外部实体完成,比如人工或自动服务。 任务的类型显示在矩形的左上角,用小图标区别。根据任务的类型,引擎会执行不同的功能。

 

人工任务(User Task)

人工任务表示需要人来执行的任务,有一个输入和一个输出。

相关的XML定义:

服务任务(Service Task)

Service Task是一个自动活动,它会调用一些服务, 比如web service,java service等等,必须有一个输入和一个输出。

相关的XML定义:

脚本任务(Script Task)

脚本任务时一个自动活动,当到达这个任务的时候流程引擎会执行一个脚本。必须有一个输入和一个输出。支持的脚本语言有Java,JavScript,XPath1.0,mvel。如下图所示。

相关的XML定义:

 

脚本任务与服务任务的区别。服务任务一般用来处理和外部服务之间的交互。脚本任务只用来执行一些简单的逻辑。

 

规则任务(Business Rule Task)

规则任务用来执行使用Drools定义的规则集,规则集通过ruleflow-group来识别。

Drools规则的定义

3.1.2  子流程(subprocess)

子流程表示多个activity的组合。子流程内部的元件禁止和外部的元件直连,只能作为一个整体与父流程的元件相连接。如下图所示。

jBPM中支持的子流程如下图。

3.2    网关(gateway)

网关用来控制业务流程走向。分为如下四个之类,每个类型网关都需要设置gateway direction属性。下面的值可以使用:

converging:网关必须拥有多个进入顺序流, 但是只能有一个外出顺序流。

diverging:网关必须拥有一个进入顺序流, 和多个外出顺序流。

 

3.2.1  唯一网关(Exclusive Gateway)

用一个内部包含X的菱形表示。

diverging

表示只有一个外向顺序流被执行。在执行时,必须确保至少一个外向顺序流上面的条件为true。

converging

每个入口顺序流执行完成之后,都会触发一次唯一网关后面的顺序流。

3.2.2  并行网关(Parallel Gateway)

Diverging

表示多个外向顺心流会同时执行。

Converging

等待所有的入口顺序流完成之后,才会触发出口顺序流。

3.2.3  包含网关(Inclusive Gateway)

Diverging

只要外向顺心流上面的条件为true,则都会被执行。

Converging

等待所有的active入口顺序流完成之后,才会触发出口顺序流。

3.3    开始事件

表示业务流程是如何开始的。用一个细线圆表示,园中的图标表示触发的方式。

空启动事件: 表示没有指明触发者。子流程必须有一个空启动事件。

消息启动事件: 由外部消息来触发流程的执行。

定时器启动事件: 由时间来触发流程的执行。

3.4    结束事件

使用粗线圆表示,意味着流程的一个顺序流的结束。和启动事件不一样,在一个流程中出现多个结束事件是非常常见的。

空结束事件

表示流程中一个路径的结束,不返回任何结果。

消息结束事件

表示流程中一个路径的结束,并发送一个消息。

Terminate结束事件

结束整个流程的执行,即使有并行路径在执行。

3.5    顺序流(Sequence Flow)

表示顺序执行的顺序,用实线箭头表达。

3.6    数据(Data Object)

Data Object可以理解为流程实例的局部临时变量,流程实例结束后Data Object也被释放。

 

Notofication对应的workitemhandler源码如下:

3.7    Artifact

artifact表示没有执行语义,也就是说对流程的执行没有任何影响。BPMN中有两种artifact,注释和分组。

3.8    注释(Text Annotation)

用于对流程图中的元件进行解释说明。

3.9    分组(Group)

用带虚线的矩形框表达,本质上没有任何执行相关的含义。

4      参考

1 https://blog.csdn.net/ronghao100/article/details/6617257

2 BPMN Method and Type

    原文作者:廖先贵
    原文地址: https://blog.csdn.net/liaoxiangui/article/details/80577721
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系管理员进行删除。