BPMN 2.0 规范中文版
1.1. BPMN 2.0 是什么呢?
业务流程模型注解(Business Process Modeling Notation - BPMN)是 业
务流程模型的一种标准图形注解。这个标准 是由对象管理组(Object
Management Group - OMG)维护的。
基本上,BPMN 规范定义了任务看起来怎样的,哪些结构可以 与其他进行连
接,等等。这就意味着 意思不会被误解。
标准的早期版本(1.2 版以及之前)仅仅限制在模型上, 目标是在所有的利
益相关者之间形成通用的理解, 在文档,讨论和实现业务流程之上。 BPMN 标
准证明了它自己,现在市场上许多建模工具 都使用了 BPMN 标准中的元素和结
构。 实际上,现在的 jPDL 设计器也使用了 BPMN 元素。
BPMN 规范的 2.0 版本,当前已经处于最终阶段了, 已经计划不就就会完成,
允许添加精确的技术细节 在 BPMN 的图形和元素中, 同时制定 BPMN 元素的执行
语法。 通过使用 XML 语言来指定业务流程的可执行语法, BPMN 规范已经演变
为业务流程的语言, 可以执行在任何兼容 BPMN2 的流程引擎中, 同时依然可以
使用强大的图形注解。
1.2. 历史和目标
jBPM BPMN2 的实现是在 jBPM 4.0 发布之后 在 2009 年 8 月,在与社区进行
了紧密协作之后启动的。 而后,我们决定了第一个发布版(比如,文档/QA) 涉
及一部分 BPMN2 规范,将在 jBPM 4.3 发布。
我们的目标是建立一个原生 BPMN2 运行引擎 (或者说实现'可执行的
BPMN2')基于流程虚拟机 (Process Virtual Machine - PVM)。 注意,这个
版本的主要目标是原生可执行, 不是图形注解 - 但是我们清楚 对于未来的版
本是很重要的。
如果用户已经了解了 jBPM,就会发现
·配置结构保持不变
·API 与已经存在的完全一样或者很类似
·测试 BPMN2 流程也可以使用常用的 java 测试框架
·数据库表结构保持不变
所以,总体来说,我们的主要目标是保持所有在 jBPM 上好的事情, 加强它
们,使用一个标准的流程语言。
1.3. JPDL vs BPMN 2.0
第一个问题可能是,很正当的,映入脑海的是, 为什么已经有了 jPDL 还要
实现 BPMN2。它们两个语言 的目标都是定义可执行的业务流程。从高层次来看,
两个语言是等效的。主要的区别是 BPMN2 是“厂商中立”的,你可以使用标准,
而 jPDL 是绑定在 jBPM 上的(虽然会有一些争论 绑定在开源语言厂商比如 jPDL
和绑定在闭源产品)。
在 jBPM 中,两个语言实现都是建立在 jBPM 流程虚拟机上的 (PVM)。这意
味着两个语言共享通用功能 (持久化,事务,配置,也有基本流程结构,等等)。
结果就是,对 jBPM 核心的优化 会对两个语言有益。依靠 PVM,BPMN2 实现 建立
在基础上,已经在过去证明了它自己, 并拥有了很大的最终用户社区。
当执行语言,把它们相互比较的时候, 下面几点必须纳入考虑:
·BPMN2 是基于被 BPM 工业接受的一个标准。
·BPMN2 是与实现无关的。这一点的缺点是集成 java 技术 jPDL 总会更
早。 所以,从 java 开发者的角度,jPDL 更简单,感觉更自然 (一些 BPEL/WSDL
的“层次”也在 BPMN 中)。
·jPDL 的一个目标是 XML 可读,BPMN2 流程在 一定程度上也是可读的,
但是工具和更多规范的细节 会要求实现同等级的 生产力。
·java 开发者可以很快学会 jPDL,因为他们很了解 jPDL 语言, 会发现
实用工具有时候很麻烦, 语言本身也过于复杂了。
·BPMN2 包含一个很大的描述结构的集合,在规范中。 然而,对接口代
码的绑定在规范中是开放的 (与 XPDL 相比),即使 WSDL 通常会被默认使用。
这意味着流程的可移植性丧失了, 当我们把流程移植到一个引擎上,而这个引
擎不支持同样的绑定机制。 比如,调用 java 类通常是 jBPM 的默认实现 的绑
定方式。
很自然的,因为政治原因,BPMN2 规范发展的会比较慢。 jPDL 就可以快速
变化,和新技术进行集成, 当他们发布的时候, 与 BPMN2 相比可以加快步伐进
行演化。 当然,因为两个都建立在同一个 PVM 上,jPDL 中的逻辑 也可以一直
到 BPMN2 上, 作为一个扩展,不会出现很多麻烦。
1.4. Bpmn 2.0 执行
BPMN2 规范定义了非常丰富的语言,为建模和执行业务流程。 然而,也意味
着它非常困难总览 BPMN2 可能是怎样 为了简化这种情况,我们决定把 BPMN2 结
构分为三个等级。 区分的方式主要基于 Bruce Silver 写的 'BPMN method and
Style'这本书(http://www.bpmnstyle.com/), Dr. Jim Arlow 的培训资料(
http://www.slideshare.net/jimarlow/introductiontobpmn005),
'How
need'(
much
BPMN
do
you
http://www.bpm-research.com/2008/03/03/how-much-bpmn-do-you-need/) ,
和我们自己的经验。
我们定义了三种 BPMN2 结构分类:
·基本:这个分类的结构很直接 并且容易了解。这个分类的结构可以用来为 简
单的业务流程建模。
·高级:包含更强大或更复杂的结构, 这些都提高了建模和执行语法的学习曲
线。 业务流程的主要目标是使用这个 和之前的分类来实现结构。
·复杂:这个分类的结构用来实现罕见的情况, 或者它们的语法难以理解。
1.5. 配置
在你的应用中使用 BPMN 2.0 是很简单的:只要把下面一行 加入 jbpm.cfg.xml
文件。
这里的引用会启用 BPMN 2.0 的流程发布,通过把 BPMN 2.0 发布器安装到流程引
擎中。 注意流程引擎可以同时使用 jPDL 和 BPMN 2.0 流程。 这意味着在你的应
用里,一些流程可能是 jPDL, 其他的可能是 BPMN 2.0。
流程引擎是根据定义文件的后缀来区分流程定义的。 对于 BPMN 2.0,使用
*.bpmn.xml 后缀 (jPDL 使用*.jpdl.xml 后缀)。
1.6. 实例
发布中包含的例子也包含了下面章节中 讨论的每个结构的实例。查看 BPMN
2.0 的流程实例 和测试用例,在 org.jbpm.examples.bpmn.* 包下。
参考用户指南,第二章(安装),研究一下如何导入实例。查看章节'导入
实例'。
1.7. 流程根元素
一个 BPMN 2.0 XML 流程的根是 definitions 元素。 在命名状态,子元素会
包含真正的业务流程定义。 每个 process 子元素 可以拥有一个 id(必填)
和 name(可选)。一个空的 BPMN 2.0 业务流程 看起来像下面这样。也要注意
把 BPMN2.xsd 放在 classpath 下, 来启用 XML 自动补全。
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://schema.omg.org/spec/BPMN/2.0 BPMN20.xsd"
xmlns="http://schema.omg.org/spec/BPMN/2.0"
typeLanguage="http://www.w3.org/2001/XMLSchema"
expressionLanguage="http://www.w3.org/1999/XPath"
targetNamespace="http://jbpm.org/example/bpmn2">
...
如果为 process 元素定义了 name,它会被用做流程的 key。(比如,启动一个流
程可以通过调用 executionService.startProcessInstanceByKey("myBusiness
Process")。 如果没有指定 name,id 会被用做 key。所以只有 id 定义时, 会
允许通过 id 来启动一个流程实例。所以基本上 name 和 key 在使用上是等价的,
比如搜索流程定义。 注意 key 的规则与 jPDL 一样: 空格和非字母数字的字符
会被下划线代替。
1.8. 基本结构
1.8.1. 事件
与活动和网关一起,事件用来在实际的每个业务流程中。事件让业务建模工
具用很自然的方式描述业务流程,比如 '当我接收到客户的订单,这个流程就
启动','如果两天内任务没结束,就终止流程'或者'当我收到一封取消邮件,
当流程在运行时,使用子流程处理邮件'。注意典型的业务 通常使用这种事件驱
动的方式。人们不会硬编码顺序创建, 但是他们倾向于使用在他们的环境中发
生的事情(比如,事件)。在 BPMN 规范中,描述了很多事件类型,为了覆盖可
能的事情,在业务环境中可能出现的情况。
1.8.2. 事件:空启动事件
一个启动事件说明了流程的开始(或子流程)。图形形式,它看起来 是一
个圆(可能)内部有一个小图标。图标指定了事件的实际类型 会在流程实例创
建时被触发。
空启动事件画出来是一个圆,内部没有图标,意思是 这个触发器是未知或
者未指定的。jPDL 的开始活动基本是一样的语法。 流程实例的流程定义包含一
个空启动事件, 可以使用 executionService 的 API 调用创建。
一个空开始事件像下面这样定义。id 是必填的,name 是可选的。
1.8.3. 事件:空结束事件
结束事件指定了流程实例中一个流程路径的结束。图形上,它看起来就是一
个圆拥有厚边框(可能)内部有小图标。图标指定了结束的时候会执行哪种操作。
空结束事件画出来是一个圆,拥有厚边框,内部没有图标,这意味着当流程
到达事件时,不会抛出任何信号。jPDL 中的结束事件与空结束事件语义相同。
空结束事件可以像下面一样定义,id 是必填的,name 是可选的。
下面的例子显示了只使用空开始和结束事件的流程:
这个流程对应的可执行 XML 像这样 (忽略声明用的 definitions 根元素)
现在可以通过调用 startProcessInstanceXXX 操作, 创建一个流程实例。
ProcessInstance processInstance =
executionService.startProcessInstanceByKey("noneStartEndEvent");
1.8.4. 事件:终止结束事件
终止和空结束事件的区别是 实际中流程的路径是如何处理的(或者使用
BPMN 2.0 的术语叫做 token)。终止结束事件会结束整个流程实例,而空结束事
件只会结束当前流程路径。他们都不会抛出任何事情 当到达结束事件的时候。
一个终止结束事件可以像下面定义。id 是必填的,name 是可选的。
终止结束事件被描绘成结束事件一样(圆,厚边框),内部图标时一个完整
的圆。在下面的例子中,完成 task1 会结束流程实例,当完成 task2 时只会结
束到达结束事件 的流程路径,只剩下 task1 打开。
参考 jBPM 发布包中的实例, 单元测试和业务流程对应 XML。
1.8.5. 顺序流
顺序流是事件,活动和网关之间的连线,显示为一条实线 带有箭头,在 BPMN
图形中(jPDL 中等效的是 transition)。每个顺序流都有一个源头和一个目标
引用,包含了活动,事件或网关的 id。
与 jPDL 的一个重要区别是多外向顺序流的行为。在 jPDL 中,只有一个转移
会成为外向转移,除非活动是 fork (或自定义活动拥有 fork 行为)。然而,
在 BPMN 中,多外向顺序流的默认行为是切分进入的 token(jBPM 中术语叫做
execution)分成 token 集合,每个顺序流一个。在下面情况中,在完成第一个
任务,就会激活三个任务。
为了避免使用一个顺序流,必须添加 condition 条件到顺序流中。在运行时,
只有当 condition 条件结果为 true,顺序流才会被执行。
为了给顺序流添加 condition 条件,添加一个 conditionExpression 元素到
顺序流中。条件可以放在${}中。
${amount >=
500}
注意,当前必须把 xsi:type="tFormalExpression"添加到
conditionExpression 中。一个条件性的顺序流可以看到一个小菱形图片 在顺
序流的起点。记住表达式一直可以定义在顺序流上,但是一些结构不会解释它(比
如,并行网关)。
活动(比如用户任务)和网关(比如唯一网关)可以用户默认顺序流。默认
顺序流只会在活动或网关的 所有其他外向顺序流的 condition 条件为 false 时
才会使用。默认顺序流图形像是顺序流多了一个斜线标记。
默认顺序流通过指定活动或网关的'default' 属性来使用。也要注意,默认
顺序流上的表达式会被忽略。
1.8.6. 网关
BPMN 中的网关是用来控制流程中的流向的。更确切的是,当一个 token(BPMN
2.0 中 execution 的概念注解)到达一个网关, 它会根据网关的类型进行合并
或切分。
网关描绘成一个菱形,使用一个内部图标来指定类型 (唯一,广泛,其他)。
所有网关类型,都可以设置 gatewayDirection。下面的值可以使用:
·unspecificed (默认):网关可能拥有多个 进入和外出顺序流。
·mixed:网关必须拥有多个 进入和外出顺序流。
·converging:网关必须拥有多个进入顺序流, 但是只能有一个外出顺
序流。
·diverging:网关必须拥有一个进入顺序流, 和多个外出顺序流。
比如下面的例子:并行网关的 gatewayDirection 属性为'converging',会
拥有 json 行为。
注意:gatewayDirection 属性根据规范是可选的。 这意味着我们不能通过
这个属性来 在运行时知道一个网关的行为(比如,一个并行网关, 如果我们用
够切分和合并行为)。然而,gatewayDirection 属性用在解析时 作为约束条件
对进入、外出顺序流。所以使用这个属性 会减低出错的机会,当引用顺序流时,
但不是必填的。
1.8.7. 网关:唯一网关
唯一网关表达了一个流程中的唯一决策。会有一个外向顺序流被使用,根据
定义在顺序流中的条件。
对应的 jPDL 结构,相同的语法是 decision 活动。唯一网关的完全技术名称
是'基于数据的唯一网关',但是也经常称为 XOR 网关。XOR 网关被描绘为一个菱
形,内部有一个'X',一个空的菱形,没有网关也象征着唯一网关。
下面图形显示了唯一网关的用法:根据 amount 变量的值,会选择唯一网关
外向的三个外向顺序流中的一个。