BPMN2.0简单入门

概述

BPM业务流程管理，从管理业务流程的角度来说，我们现有的IT系统大多数都属于这一类，比如供应链领域的InStock（WMS），物流管理/提货送货预约（TMS），订单管理OMS、SRM、CRM等。都可以称之为BPM系统。

​

就和我们处理现实中的问题的解决思路一样，我们通常对已经存在复杂问题进行模型化的抽象，通过模型来推导解决问题的方案。也就是所谓的建模（这一过程也被称之为Business Process Modeling业务流程建模）。BPM有很多种建模语言，BPMN（Business Process Modeling Notation）就是其中的一种建模语言。

​

工作流建模规范其实不止一种，类似的规范还有XPDL、BPML等，BPMN没有它们出现的早，但却是使用最多、最广泛的一个。截至目前BPMN有2个版本：BPMN 1.0（2004年）和BPMN 2.0（2011年），最新版本是BPMN 2.0。

BPMN以XML作为载体，提供了一套标准的标记语言，并通过一套标准的、易记、和好理解的符号，让业务人员和技术人员都能很快上手。

​

BPMN（Business Process Model and Notation），可以译为“业务流程模型与标记法”，是流程建模的全球标准，也是成功将业务IT化的一个最重要的组件。现在越来越多的组织都在使用BPMN，并且越来越多的大学也将BPMN作为一门科程来教学。 原因如下：

  • 标准：BPMN不是被某个企业拥有的，而是被OMG这个机构拥有的。OMG（Object Management Group）这个组织已经建立了其它世界级的标准，比如大名鼎鼎的UML。BPMN标准得到了许多软件产品的支持，这样就可以降低对某个特定厂商产品的依赖。
  • 简单：BPMN背后的原理很简单，这是可以非常快速上手使用这些符号的原因。
  • 表达能力：如果有必要，你可以用BPMN来精确地描述流程是怎样工作的。但是这可比仅仅粗略地描述流程程要困难得多。精确建模是可行的，但不是强制的。
  • 在IT中实施：BPMN被开发出来主要就是为了支持用技术实现流程（流程自动化）。IT在公司中越重要，使用BPMN就会越有帮助。

​

BPMN旨在减少众多业务建模工具和流程记录工具之间的断层。由业务人员做出来的业务流程模型与由IT实施人员设计和构建的流程执行模型在很大程度上都是一个不断趋近而又不断交错的，有必要将原有的业务流程模型转换为执行模型，而这个转换对于业务流程拥有者和IT实施人员来说，都是容易出错且很艰难的过程。

例如：HR部门使用Word或者用纸笔来绘制和记录他们的请假和入职流程，然后将这个文档交给技术人员，技术人员再使用专门的流程工具把原始的流程图做一些修改，这样可以放到系统中去执行，然后HR部门又补充了一些内容，于是要修改那个原始的业务模型，交给IT人员，IT人员再去修改执行模样……周而复始。

而BPMN作为易用的，标准的建模标记语言，可以减少业务与IT用户之间的混乱。它也是为了这而设计的：BPMN创建了一座桥梁，连接业务流程建模标记到IT执行语言，减少业务建模与技术实现的断层。

​

请一定牢记BPMN倡导的“设计即实现”！

​

​

基本元素

流对象（Flow Objects）

流对象是BPMN2.0中最重要的元素，包括活动（Activities）、事件（Events）、网关（Gateways）。

​

活动

Activities可以译为“活动”、“节点”、“步骤”，一个活动可以是流程中的一个基本处理单元（如人工任务、服务任务），也可以是一个组合单元（如外部子流程、嵌套子流程）。

任务：普通任务（undefined）、发送任务（send）、接收任务（receive）、用户任务（user）、手工任务（manual）、业务规则任务（business rule）、服务任务（service）、脚本任务 （script）。

子任务：普通子任务 （sub process）、调用活动（call activity）、事务子任务（transactional）、事件子任务（event）、展开的子任务（expanded）。

任务又可以添加串行多实例（三条竖线），并行多实例（三条横线），循环（首尾相接的箭头）这三个标记，展开的子任务除了这三个标记以外还可以添加Ad-hoc标记（一条波浪线）。

image-20210125145648868

image-20210125142045254

image-20210125143537817

image-20210125143856730

​

事件

按阶段维度分类：开始事件（Start）、中间事件（Intermediate）、结束事件（End）。

按类型维度分类：空事件（None）、消息事件（Message）、时间事件（Timer）、条件事件（Conditional）、链接事件（Link）、信号事件（Signal）、错误事件（Error）、升级事件（Escalation）、中止事件（Termination）、补偿事件（Compensation）、放弃事件（Cancel）、多重事件（Multiple）、多重并行事件（Multiple Parallel）。

事件的分类可以有不同的维度，这些维度又是可以组合的，比如“消息开始事件”，或“信号结束事件”等等。也可以再细分成“抛出事件”、“捕获事件”，或“中断事件”和“非中断事件”。

image-20210125144349247

BPMN规范不强制要求建模的时候为流程添加开始事件和结束事件，其实可以忽略它们，但是如果添加了开始事件，就必须在流程图中为每条路径都添加一个结束事件。同理，如果在流程中添加了结束事件，也就需要有开始事件。

我们通常在建模的时候使用开始事件和结束事件，出于下述2种原因：

  • 有可能去指定流程的触发
  • 可以描述每个路径结束的最终状态

​

网关

Gateways可以译为“网关”、“决策”、“判断”，包括排他网关（exclusive - XOR）、包容网关（inclusive - OR）、并行网关（parallel - AND）、基于事件的网关（event based）、和灵活网关（complex）。

image-20210125140615288

  • 排他网关更专业的名称是基于数据的排他网关（exclusive data-based gateway）用于对流程中的决策建模。当执行到达这个网关时，会按照所有出口顺序流定义的顺序对它们进行计算。选择第一个条件计算为true的顺序流（当没有设置条件时，认为顺序流为true）继续流程。

  • 排他网关与包容网关的区别是，排他网关依次计算连线上表达式的值，第一个为true的分支会被执行，后面的都不会执行；而包容网关是所有为true的分支都会执行。

  • 并行网关与其他网关相比有一个重要区别：并行网关不计算条件。如果连接到并行网关的顺序流上定义了条件，会直接忽略该条件。也就是与并行网关相连的连线上都设置不了条件。

  • 并行网关，可以将执行分支（fork）为多条路径，也可以合并（join）多条入口路径的执行。

    • 分支：所有的出口顺序流都并行执行，为每一条顺序流创建一个并行执行。
    • 合并：所有到达并行网关的并行执行都会在网关处等待，直到每一条入口顺序流都到达了有个执行。然后流程经过该合并网关继续。

  • 如果并行网关同时具有多条入口与出口顺序流，可以同时具有分支与合并的行为。在这种情况下，网关首先合并所有入口顺序流，然后分裂为多条并行执行路径。

    image-20210125165716477

  • 网关不执行任何动作或决定，它只是任务流拆分或汇聚的可视化。

  • 复杂网关是需要借助SDK编写代码进行干预的网关。

  • 理解BPMN网关的符号含义：

    • 排他网关符号的X，代表的是XOR（也就是eXclusive OR）。逻辑运算异或其实就是找不同，就是不同为1，相同就是0，套用在XOR网关，只有存在一个true时才认为是通过，全为true或者全为false都是不能让流程继续流转的。
    • 包容网关符号的O，代表的是Or。逻辑运算或就是只要有一个1，结果就是1，套用在OR网关，只要有一个true就认为是通过，且所有为true的条件的分支都会继续流转。
    • 并行网关符号的+，代表的是AND。
    • 内部没有图标的网关默认为排他网关，BPMN 2.0规范不允许在同一个流程中混合使用有及没有X的网关标志。

​

连接对象（Connecting Objects）

包括顺序流（Sequence Flows）、关联（Associations）、数据关联（Data Associations）和消息流（Message Flows）。

image-20210125153746565

​

数据（Data）

包括数据对象（Data Objects）、数据对象（Data Objects）、数据存储（Data Store）。

用于描述活动所需或者产生的数据。用连线将它们与活动连接起来，不会影响流程的流转。

image-20210125142659954

​

参与者（Participants）

包括泳池（Pools）和泳道（Lanes）。

泳池可以是垂直或者水平的，用来对活动进行组织和分类。泳道常用来将活动按照角色划分，流程可以在一个pool中跨Lane流转，但是在同一个pool中消息流通常不跨lane流转。

image-20210125142816826

​

描述对象

包括组（Groups）和注释（Annotations）。

组用于描述和解释目的，不会影响流程的流转。顾名思义，注释提供一些附加性的文本信息给流程图的阅读者，也不会影响流程的流转。

image-20210125143138397

​

​

示例

下面的这两个示例并不能真的在流程引擎中执行，它们只是演示了如何将现实世界中的真实业务场景用BPMN的图形符号建模出来。

就拿示例2订购Pizza的流程来讲，在顾客那个泳池中有一个“收到Pizza事件”，这是一个捕获消息中间事件（Message Intermediate Catch Event），它需要接收到一个抛出消息事件才会继续向后流转，但是在示例图中，它是由配送小哥那个泳道里的一个“配送Pizza”活动触发的。

Shipment Process

概述

在这个图中，你可以看到硬件零售商在将顾客订购的货物实际运送给顾客之前必须执行的准备步骤：

在这个例子里，我们只使用了一个泳池，以及为参与到此流程人员的使用不同的泳道。自动化意味着我们取消了这些人员之间的交流：我们只是假设他们以某种方式相互交流。

  • 如果我们有一个流程引擎来驱动这个流程，那么该引擎将分配用户任务，并负责这些人之间的通信。

  • 如果我们没有这样的流程引擎，但想显式地建立相关人员之间的通信模型，则必须使用下一章所述的协作图。

image-20210121100453004

详细说明

运送货物：这是一个普通的开始事件，表明准备已经完成。

​

判断是普通邮寄还是特殊邮寄：跟着排他网关后的这个店员任务，是一个用来弄清楚基于数据的排他网关推荐用法的好例子。排他网关“配送模式”并不负责判断这是一个特殊的运输或者普通的邮政运输。而是由排他网关前面的活动来负责这个判断。这个排他网关基于的是前面任务的结果，它只是像路由器一样去工作，提供可供选择的路径。任务代表实际的工作单元，而网关仅去路由顺序流。

​

配送模式：这个网关被称为排他网关是因为后续的两个分支中只有一个可以到达。如果我们需要特殊的运输，店员就需要去从不同的运输公司获得报价，然后指派给其中一个承运者并开始准备相关文件。但是，如果正常的邮寄就挺好的，店员就需要去查看一下是否需要额外的保险。

​

包容网关：如果需要额外保险，后勤经理就得去购买额外保险。否则，店员就需要去添加邮寄单。在这个场景中，图中所示的包容网关很有用，因为我们可以展示出有一个分支总是被采用，而另一个分支只有在需要额外保险时才被采用，但如果采用了，这可能与第一个分支，也就是“填写邮寄单”，并行执行。由于这种并行性，我们需要在“填写邮寄单”和“购买额外保险”之后去同步包容网关。

​

包容网关（同步）：在这个场景下，因为“填写邮寄单”总是会执行，所以这个包容网关会等待“填写邮寄单”完成。同样如果“需要额外保险”，那么这个包容网关也会等待“购买额外保险”结束。

​

并行网关（同步）：此外，我们也需要同步/汇聚“将包裹移至拣选区”这个最后的任务，因为我们想确保在最后这个任务以前，所有事情都已经做好了。

​

​

Pizza Collaboration

这是一个关于企业与企业协作的示例。因为我们要直接地建模Pizza客户和供应商之间的交互，所以我们将它们归类为“参与者”，因此为他们各自提供了专用泳池：

概述

请注意，这种类型的建模是没有默认的语义，也就是没有固定的画法、不是强制的。这就意味着，你不但可以在协作图中表示商业伙伴之间的交互，也可以放大到一个公司内部，表示不同部门间的交互、不同团队之间的交互，甚至是单独的工人个体间的交互或软件系统间的交互。这完全取决于建模的目的，因此，建模者必须做出决定，判断一个协作流程图中存在不同的泳池是不是有用的，或者是否要坚持在一个泳池中有多个泳道，就像上一章的Shipment Process流程图显示的那样，一个泳池里有多个泳道。

image-20210122101235752

​

详细说明

饿了想吃Pizza：如果我们一步步看这个流程图，我们应该从这个披萨顾客开始看，Pizza顾客这条泳道中的一个普通的开始事件表示，顾客他注意到他的肚子在咕咕叫。因此，这位顾客选好一个披萨并订购下了它。

​

收到订单：这是Pizza商家这条泳道中的一个消息开始事件，它是被客户的订单触发，显示为一个消息开始事件，消息流是从上面那个泳池的“订购比萨饼”指向这个事件。

​

基于事件的网关：“订购Pizza”活动后面有一个基于事件的网关。顾客在这里等着Pizza送达。基于事件的网关表明顾客实际上正在等待接下来可能发生的两个不同事件：或者是Pizza已交付（就像这个网关后面的那个消息捕获事件展示的），或者是Pizza在60分钟后还没有交付，即顾客等了一小时后，不再等待，然后致电供应商，索要Pizza。现在我们假设店员向顾客承诺Pizza会尽快送到，而客户再次等待Pizza，60分钟后再次询问，依此类推。

注：在官方文档原图的Order Pizza活动之后是一个包容网关，不知道是不是一处堪误。

image-20210122110407120

​

​

收到Pizza：在本例中，我们不但将消息事件用于信息化对象（像订购Pizza），而且也用于实物对象（像Pizza）。我们这样做是因为这些实物对象从根本上讲也充当着信息化对象：当Pizza实物被送到顾客家的门口，她会意思到Pizza已送达，这恰好是Pizza顾客那个泳池中相应消息事件的目的。当然了，我们只能以这种方式使用这个模型，因为这个示例本来也没打算在一个流程引擎中执行。

​

​

常见问题

问：是否必须水平地绘制BPMN图？如果我更喜欢垂直地画它们呢？

答：你可以从上到下来绘制流程图而不是从左到右，BPMN 2.0规范没有禁止这样。然而很多BPMN的实现厂商都不推荐这样做，比如Camunda，因为从上到下绘制是不寻常、不常见的，并且经验证实，如果采用与书面文字相同的方式描述，人们往往可以更好地理解业务流（按从左到右这样的顺序，无论是在西方世界，还是中国，都是适用的）。

​

问：BPMN和BPM是什么关系？

答：可以简单的理解成BPM是目标，BPMN是手段。通过BPMN（业务流程建模语言）来进行BPM（业务流程建模），这个建模结果就是业务流程的定义。这个流程定义规定了业务的流转过程由谁参与等等。

​

问：流程引擎是做什么用的？

答：前面已经解释了，使用BPMN来建模BPM，最后产出的是业务流程定义，而协调并执行这个流程，记录流程的执行过程和结果就是工作流引擎的职责范围了。

​

​

主流工作流引擎

JBPM

由JBoss公司开发，目前最高版本JPBM7，不过从JBPM5开始已经跟之前不是同一个产品了，JBPM5的代码基础不是JBPM4，而是从Drools Flow重新开始。下面要涉及的很多产品都是以JBPM4的代码为起点进行开发的。

Activiti

Alfresco软件开发，基于JBPM4，后并入OMG，目前最高版本activiti 7。Activiti5版本的时候，核心团队发生了比较大的变动（离职），activiti6的开发团队在新版本中去除了PVM，纳入了DMN，重构XML解析，BUG较多，目前主要团队致力于activiti7,5&6已经官宣不维护。

Flowable

基于activiti6，最新的开源版本是flowable6，开发团队是从activiti中分裂出来的，修复了一众activiti6的bug，并在其基础上研发了DMN支持，BPEL支持等等。相对开源版，其商业版的功能会更强大。

Camunda

基于activiti5，所以其保留了PVM，最新版本Camunda7，开发团队也是从activiti中分裂出来的，发展轨迹与flowable相似，同时也提供了商业版。

JFlow

前身ccFlow，国产的工作流引擎，由济南驰骋公司开发维护，主打中国式的业务流程，由于是国产的软件，中文化程度比较深，业务开发也对用户比较友好。国产的开源工作流引擎还是挺多的，JFlow是其中功能比较完善的一个，同时对比activiti，流程上更加中国化，支持自定义流程跳转，加签等。其他国产工作流就不列举了。

Osworkflow

完全用java语言编写的开放源代码的工作流引擎，具有显著的灵活性及完全面向有技术背景的用户的特点。由opensymphony组织维护，其不遵守XPDL等业务规范，完全使用XML编排业务。面向开发人员。

Shark

靠山是Enhydra。是一个可扩展的工作流引擎框架，它包括一个完全基于 WFMC 规范的标准实现，它使用XPDL（没有任何自己新的扩展）作为自身的工作流流程定义格式。其持久层和设计器都是自己公司研发的，持久层实现采用的标准是轻量级的Enhydra DODS O/R mapping 工具，设计器可以用Enhydra JaWE 图形XPDL编辑器。

Apache ODE

轻型的、可嵌入的组件，利用组件组装成一个完整的BPM系统。关键模块包括ODE BPEL编译器、ODE BPEL运行时、ODE数据访问对象（DAOs）、ODE集成层（ILs）和用户工具。虽然挂在Apache下面，但已经年久失修。

​

​

参考

​

​

EOF