BPMN2.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.****.net/ronghao100/article/details/6617257
2 BPMN Method and Type