jbpm4与bpmn
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的流程引擎中， 同时依然可以使用强大的图形注解。
历史和目标
jBPM BPMN2的实现是在jBPM 4.0发布之后 在2009年8月，在与社区进行了紧密协作之后启动的。 而后，我们决定了第一个发布版（比如，文档/QA） 涉及一部分BPMN2规范，将在jBPM 4.3发布。
我们的目标是建立一个原生BPMN2运行引擎 （或者说实现’可执行的BPMN2′）基于流程虚拟机 （Process Virtual Machine – PVM）。 注意，这个版本的主要目标是原生可执行， 不是图形注解 – 但是我们清楚 对于未来的版本是很重要的。
如果用户已经了解了jBPM，就会发现 所以，总体来说，我们的主要目标是保持所有在jBPM上好的事情， 加强它们，使用一个标准的流程语言。
■配置结构保持不变
■API与已经存在的完全一样或者很类似
■测试BPMN2流程也可以使用常用的java测试框架
■数据库表结构保持不变
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上， 作为一个扩展，不会出现很多麻烦。
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 much BPMN do you need’( http://www.bpm-research.com/2008/03/03/how-much-bpmn-do-you-need/)， 和我们自己的经验。
我们定义了三种BPMN2结构分类：
■基本：这个分类的结构很直接 并且容易了解。这个分类的结构可以用来为 简单的业务流程建模。
■高级：包含更强大或更复杂的结构， 这些都提高了建模和执行语法的学习曲线。 业务流程的主要目标是使用这个 和之前的分类来实现结构。
■复杂：这个分类的结构用来实现罕见的情况， 或者它们的语法难以理解。
配置
在你的应用中使用BPMN 2.0是很简单的：只要把下面一行 加入jbpm.cfg.xml文件。
<import resource="jbpm.bpmn.cfg.xml" />这里的引用会启用BPMN 2.0的流程发布，通过把BPMN 2.0发布器安装到流程引擎中。 注意流程引擎可以同时使用jPDL和BPMN 2.0流程。 这意味着在你的应用里，一些流程可能是jPDL， 其他的可能是BPMN 2.0。
流程引擎是根据定义文件的后缀来区分流程定义的。 对于BPMN 2.0，使用*.bpmn.xml后缀 （jPDL使用*.jpdl.xml后缀）。
实例
发布中包含的例子也包含了下面章节中 讨论的每个结构的实例。查看BPMN 2.0的流程实例 和测试用例， 在org.jbpm.examples.bpmn.* 包下。
参考用户指南，第二章（安装），研究一下如何导入实例。 查看章节‘导入实例’。
流程根元素
一个BPMN 2.0 XML流程的根是definitions元素。 在命名状态，子元素会包含真正的业务流程定义。 每个process子元素 可以拥有一个id和 name。一个空的BPMN 2.0业务流程 看起来像下面这样。也要注意把BPMN2.xsd放在classpath下， 来启用XML自动补全。
<definitions id="myProcesses"
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 id="myBusinessProcess" name="My business processs">
...
</process>
<definitions>如果一个process元素定义了id，它会作为业务流程的key使用 （比如，启动流程可以通过调用executionService.startProcessInstanceByKey(“myBusinessProcess”)， 否则jBPM引擎会创建一个唯一流程key（与jPDL相同）。
基本结构
1. 事件
与活动和网关一起，事件用来在实际的每个业务流程中。 事件让业务建模工具用很自然的方式描述业务流程，比如 ‘当我接收到客户的订单，这个流程就启动’， ‘如果两天内任务没结束，就终止流程’ 或者‘当我收到一封取消邮件，当流程在运行时， 使用子流程处理邮件’。注意典型的业务 通常使用这种事件驱动的方式。人们不会硬编码顺序创建， 但是他们倾向于使用在他们的环境中发生的事情（比如，事件）。 在BPMN规范中，描述了很多事件类型，为了覆盖可能的事情， 在业务环境中可能出现的情况。
2. 事件：空启动事件
一个启动事件说明了流程的开始（或子流程）。图形形式，它看起来 是一个圆（可能）内部有一个小图标。图标指定了事件的实际类型 会在流程实例创建时被触发。
空启动事件画出来是一个圆，内部没有图标，意思是 这个触发器是未知或者未指定的。jPDL的开始活动基本是一样的语法。 流程实例的流程定义包含一个空启动事件， 可以使用executionService的API调用创建。
一个空开始事件像下面这样定义。id是必填的，name是可选的。
<startEvent id="start" name="myStart" />
3. 事件：空结束事件
结束事件指定了流程实例中一个流程路径的结束。 图形上，它看起来就是一个圆 拥有厚边框（可能） 内部有小图标。 图标指定了结束的时候 会执行哪种操作。
空结束事件画出来是一个圆，拥有厚边框，内部没有图标， 这意味着当流程到达事件时，不会抛出任何信号。 jPDL中的结束事件与空结束事件语义相同。
空结束事件可以像下面一样定义，id是必填的，name是可选的。
<endEvent id="end" name="myEnd" />
下面的例子显示了只使用空开始和结束事件的流程：
这个流程对应的可执行XML像这样 （忽略声明用的definitions根元素）
<process id="noneStartEndEvent" name="BPMN2 Example none start and end event">
<startEvent id="start" />
<sequenceFlow id="flow1" name="fromStartToEnd"
sourceRef="start" targetRef="end" />
<endEvent id="end" name="End" />
</process>
现在可以通过调用startProcessInstanceXXX操作， 创建一个流程实例。
ProcessInstance processInstance = executionService.startProcessInstanceByKey("noneStartEndEvent");
4. 事件：终止结束事件
终止和空结束事件的区别是 实际中流程的路径是如何处理的（或者使用BPMN 2.0的术语叫做token）。 终止结束事件会结束整个流程实例，而空结束事件只会结束当前流程路径。 他们都不会抛出任何事情 当到达结束事件的时候。
一个终止结束事件可以像下面定义。id是必填的，name是可选的。
<endEvent id="terminateEnd" name="myTerminateEnd">
<terminateEventDefinition/>
</endEvent>
终止结束事件被描绘成结束事件一样（圆，厚边框）， 内部图标时一个完整的圆。在下面的例子中，完成task1 会结束流程实例，当完成task2时只会结束到达结束事件 的流程路径，只剩下task1打开。
参考jBPM发布包中的实例， 单元测试和业务流程对应XML。
5. 顺序流
顺序流是事件，活动和网关之间的连线，显示为一条实线 带有箭头，在BPMN图形中（jPDL中等效的是transition）。 每个顺序流都有一个源头和一个 目标引用，包含了 活动，事件或网关的id。
<sequenceFlow id="myFlow" name="My Flow"
sourceRef="sourceId" targetRef="targetId" />
与jPDL的一个重要区别是多外向顺序流的行为。 在jPDL中，只有一个转移会成为外向转移，除非活动是fork （或自定义活动拥有fork行为）。然而，在BPMN中， 多外向顺序流的默认行为是切分进入的token（jBPM中术语叫做execution） 分成token集合，每个顺序流一个。在下面情况中， 在完成第一个任务，就会激活三个任务。
为了避免使用一个顺序流，必须添加condition条件到顺序流中。 在运行时，只有当condition条件结果为true， 顺序流才会被执行。
为了给顺序流添加condition条件，添加一个conditionExpression 元素到顺序流中。条件可以放在 ${}中。
<sequenceFlow id=....>
<conditionExpression xsi:type="tFormalExpression">${amount >= 500}</conditionExpression>
</sequenceFlow>注意，当前必须把 xsi:type=”tFormalExpression”添加到 conditionExpression中。在未来的版本中可能会修改。
活动（比如用户任务）和网关（比如唯一网关）可以用户默认顺序流。 默认顺序流只会在活动或网关的 所有其他外向顺序流的condition条件为false时才会使用。 默认顺序流图形像是顺序流多了一个斜线标记。
默认顺序流通过指定活动或网关的 ‘default’ 属性 来使用。
也要注意，默认顺序流上的表达式会被忽略。
6. 网关
BPMN中的网关是用来控制流程中的流向的。更确切的是， 当一个token（BPMN 2.0中execution的概念注解）到达一个网关， 它会根据网关的类型进行合并或切分。
网关描绘成一个菱形，使用一个内部图标来指定类型 （唯一，广泛，其他）。
所有网关类型，都可以设置gatewayDirection。 下面的值可以使用：
■unspecificed (默认)：网关可能拥有多个 进入和外出顺序流。
■mixed：网关必须拥有多个 进入和外出顺序流。
■converging：网关必须拥有多个进入顺序流， 但是只能有一个外出顺序流。
■diverging：网关必须拥有一个进入顺序流， 和多个外出顺序流。
比如下面的例子：并行网关的gatewayDirection属性为’converging’， 会拥有json行为。
<parallelGateway id="myJoin" name="My synchronizing join" gatewayDirection="converging" />注意：gatewayDirection属性根据规范是可选的。 这意味着我们不能通过这个属性来 在运行时知道一个网关的行为（比如，一个并行网关， 如果我们用够切分和合并行为）。然而，gatewayDirection属性用在解析时 作为约束条件对进入、外出顺序流。所以使用这个属性 会减低出错的机会，当引用顺序流时， 但不是必填的。
7. 网关：唯一网关
唯一网关表达了一个流程中的唯一决策。 会有一个外向顺序流被使用，根据定义在 顺序流中的条件。
对应的jPDL结构，相同的语法是 decision活动。唯一网关的 完全技术名称是‘基于数据的唯一网关’， 但是也经常称为XOR 网关。 XOR网关被描绘为一个菱形，内部有一个’X'， 一个空的菱形，没有网关也象征着唯一网关。
下面图形显示了唯一网关的用法：根据amount变量的值， 会选择唯一网关外向的三个外向顺序流 中的一个。
这个流程对应的可执行XML看起来像下面这样。 注意定义在顺序流中的条件。唯一网关会选择一个顺序流， 如果条件执行为true。如果多个条件 执行为true，第一个遇到的就会被使用 （日志信息会显示这种情况）。
<process id="exclusiveGateway" name="BPMN2 Example exclusive gateway">
<startEvent id="start" />
<sequenceFlow id="flow1" name="fromStartToExclusiveGateway"
sourceRef="start" targetRef="decideBasedOnAmountGateway" />
<exclusiveGateway id="decideBasedOnAmountGateway" name="decideBasedOnAmount" />
<sequenceFlow id="flow2" name="fromGatewayToEndNotEnough"
sourceRef="decideBasedOnAmountGateway" targetRef="endNotEnough">
<conditionExpression xsi:type="tFormalExpression">
${amount < 100}
</conditionExpression>
</sequenceFlow>
<sequenceFlow id="flow3" name="fromGatewayToEnEnough"
sourceRef="decideBasedOnAmountGateway" targetRef="endEnough">
<conditionExpression xsi:type="tFormalExpression">
${amount <= 500 && amount >= 100}
</conditionExpression>
</sequenceFlow>
<sequenceFlow id="flow4" name="fromGatewayToMoreThanEnough"
sourceRef="decideBasedOnAmountGateway" targetRef="endMoreThanEnough">
<conditionExpression xsi:type="tFormalExpression">
${amount > 500}
</conditionExpression>
</sequenceFlow>
<endEvent id="endNotEnough" name="not enough" />
<endEvent id="endEnough" name="enough" />
<endEvent id="endMoreThanEnough" name="more than enough" />
</process>这个流程需要一个变量，这样表达式就可以在运行期间执行。 变量可以被提供，当流程实例执行的时候（类似jPDL）。
Map<String, Object> vars = new HashMap<String, Object>();
vars.put("amount", amount);
ProcessInstance processInstance = executionService.startProcessInstanceByKey("exclusiveGateway", vars);
唯一网关需要所有外向顺序流上都定义条件。 对这种规则一种例外是默认顺序流。 使用default 属性来引用一个已存在的 顺序流的id。这个顺序流会被使用 当其他外向顺序流的条件都执行为false时。
<exclusiveGateway id="decision" name="decideBasedOnAmountAndBankType" default="myFlow"/>
<sequenceFlow id="myFlow" name="fromGatewayToStandard"
sourceRef="decision" targetRef="standard">
</sequenceFlow>
8. 网关：并行网关
并行网关用来切分或同步相关的进入或外出 顺序流。
■并行网关拥有一个进入顺序流的和多于一个的外出顺序流 叫做‘并行切分或 ‘AND-split’。所有外出顺序流都会 被并行使用。注意：像规范中定义的那样， 外出顺序流中的条件都会被忽略。
■并行网关拥有多个进入顺序流和一个外出顺序流 叫做‘并行归并’或 AND-join。所有进入顺序流需要 到达这个并行归并，在外向顺序流使用之前。
并行网关像下面这样定义：
<parallelGateway id="myParallelGateway" name="My Parallel Gateway" />注意，gatewayDirection属性可以被使用， 已获得建模错误，在解析阶段（参考上面）。
下面的图形显示了一个并行网关可以如何使用。在流程启动后， ‘prepare shipment’ 和 ‘bill customer’用户任务都会被激活。 并行网关被描绘为一个菱形，内部图标是一个十字， 对切分和归并行为都是一样。
图形对应的XML如下所示：
<process id="parallelGateway" name="BPMN2 example parallel gatewar">
<startEvent id="Start" />
<sequenceFlow id="flow1" name="fromStartToSplit"
sourceRef="Start"
targetRef="parallelGatewaySplit" />
<parallelGateway id="parallelGatewaySplit" name="Split"
gatewayDirection="diverging"/>
<sequenceFlow id="flow2a" name="Leg 1"
sourceRef="parallelGatewaySplit"
targetRef="prepareShipment" />
<userTask id="prepareShipment" name="Prepare shipment"
implementation="other" />
<sequenceFlow id="flow2b" name="fromPrepareShipmentToJoin"
sourceRef="prepareShipment"
targetRef="parallelGatewayJoin" />
<sequenceFlow id="flow3a" name="Leg 2"
sourceRef="parallelGatewaySplit"
targetRef="billCustomer" />
<userTask id="billCustomer" name="Bill customer"
implementation="other" />
<sequenceFlow id="flow3b" name="fromLeg2ToJoin"
sourceRef="billCustomer"
targetRef="parallelGatewayJoin" />
<parallelGateway id="parallelGatewayJoin" name="Join"
gatewayDirection="converging"/>
<sequenceFlow id="flow4"
sourceRef="parallelGatewayJoin"
targetRef="End">
</sequenceFlow>
<endEvent id="End" name="End" />
</process>
9. 任务
一个任务表示工作需要被外部实体完成， 比如人工或自动服务。
重要的是注意BPMN语法的’task’与jPDL语法的区别。 在jPDL中，’task’的概念总是用在人工做一些事情的环境。 的那个流程引擎遇到jPDL中的task，它会创建一个task， 交给一些人的任务列表，然后它会进入等待状态。然而在BPMN 2.0中， 这里有很多任务类型，一些表示等待状态（比如，User Task 一些表示自动活动（比如，Service Task。 所以小心不要混淆了任务的概念，在切换语言的时候。
任务被描绘成一个圆角矩形，一般内部包含文字。 任务的类型（用户任务，服务任务，脚本任务，等等）显示在矩形的左上角，用小图标区别。 根据任务的类型， 引擎会执行不同的功能。
10. 任务：人工任务
user task是典型的’人工任务’， 实际中的每个workflow或BPMN软件中都可以找到。当流程执行到达这样一个user task时， 一个新人工任务就会被创建，交给用户的任务列表。
和manual task的主要区别是 （也与人工工作对应）是流程引擎了解任务。 引擎可以跟踪竞争，分配，时间，其他，这些不是manual task的情况。
user task描绘为一个圆角矩形，在左上角是一个小用户图标。
user task被定义为下面的BPMN 2.0 XML：
<userTask id="myTask" name="My task" />根据规范，可以使用多种实现（WebService, WS-humantask，等等）。 通过使用implementation属性。 当前，只有标准的jBPM任务机制才可以用，所以这里（还）没有 定义’implementation’属性的功能。
BPMN 2.0规范包含了一些方法把任务分配给用户，组，角色等等。 当前的BPMN 2.0 jBPM实现允许使用一个 resourceAssignmentExpression来分配任务， 结合humanPerformer or PotentialOwner结构。 这部分希望在未来的版本里能够进一步演化。
potentialOwner用来在你希望确定用户，组，角色的时候。 这是一个task的候选人。 参考下面的例子。这里的’My task’任务的候选人组是’management’用户组。 也要注意，需要在流程外部定义一个资源， 这样任务分配器可以引用到这个资源。 实际上，任何活动都可以引用一个或多个资源元素。 目前，只需要定义这个资源就可以了（因为它是规范中的一个必须的元素）， 但是在以后的发布中会进行加强（比如，资源可以拥有运行时参数）。
<resource id="manager" name="manager" />
<process ...>
...
<userTask id="myTask" name="My task">
<potentialOwner resourceRef="manager" jbpm:type="group">
<resourceAssignmentExpression>
<formalExpression>management</formalExpression>
</resourceAssignmentExpression>
</potentialOwner>
</userTask>注意，我们使用了一个特定的后缀 (jbpm:type=”group”)，来定义这是一个用户组的分配方式。 如果删除了这个属性，就会默认使用用户组的语法 （在这个例子中也是没问题的）。 现在假设Peter和Mary是management组的成员 (这里使用默认的身份服务)：
identityService.createGroup("management");
identityService.createUser("peter", "Peter", "Pan");
identityService.createMembership("peter", "management");
identityService.createUser("mary", "Mary", "Littlelamb");
identityService.createMembership("mary", "management"); Peter和Mary都可以在他们的任务列表中看到这条任务 （代码来自实例单元测试）：
// Peter and Mary are both part of management, so they both should see the task
List<Task> tasks = taskService.findGroupTasks("peter");
assertEquals(1, tasks.size());
tasks = taskService.findGroupTasks("mary");
assertEquals(1, tasks.size());
// Mary claims the task
Task task = tasks.get(0);
taskService.takeTask(task.getId(), "mary");
assertNull(taskService.createTaskQuery().candidate("peter").uniqueResult());
taskService.completeTask(task.getId());
assertProcessInstanceEnded(processInstance);当分配方式应该是候选用户时， 只需要使用jbpm:type=”user”属性。
<userTask id="myTask" name="My User task">
<potentialOwner resourceRef="employee" jbpm:type="user">
<resourceAssignmentExpression>
<formalExpression>peter</formalExpression>
</resourceAssignmentExpression>
</potentialOwner>
</userTask>在这个例子里，Peter将可以看到任务，因为他是这个任务的候选用户。
List<Task> tasks = taskService.createTaskQuery().candidate("peter").list();
human performer用来，当你想把一个任务直接分配给一个人， 组，角色时。这个方法的使用方式 看起来和potential owner很像。
<resource id="employee" name="employee" />
<process ...>
...
<userTask id="myTask" name="My User task">
<humanPerformer resourceRef="employee">
<resourceAssignmentExpression>
<formalExpression>mary</formalExpression>
</resourceAssignmentExpression>
</humanPerformer>
</userTask>在这个例子中，任务会直接分配给Mary。 她可以在自己的任务列表中看到这个任务：
List<Task> tasks = taskService.findPersonalTasks("mary");
因为任务分配已经完成，通过使用 formalExpression，它也可以定义表达式 在运行期解析。表达式本身需要放在 ${}中，这和jBPM一样。 比如，如果流程变量’user’被定义了，然后，它可以用在表达式中。 当然也可以使用更复杂的表达式。
<userTask id="myTask" name="My User task">
<humanPerformer resourceRef="employee">
<resourceAssignmentExpression>
<formalExpression>${user}</formalExpression>
</resourceAssignmentExpression>
</humanPerformer>
</userTask>注意不需要在humanPerformer元素中使用’jbpm:type’，因为只能进行 直接用户分配。如果任务需要被分配给一个角色或一个组， 使用potentialOwner和group类型（当你把任务分配给一个组时， 组中的所有成员都会成为候选用户 – 参考potentialOwner的用法）。
11. 任务：Java服务任务
Service Task是一个自动活动，它会调用一些服务， 比如web service，java service等等。当前jBPM引擎 只支持调用java service，但是web service的调用 已经在未来的版本中做了计划。
定义一个服务任务需要好几行XML（这里就可以看到BPEL的影响力）。 当然，在不久的未来，我们希望有工具可以把这部分大量的简化。 一个服务任务需要如下定义：
<serviceTask id="MyServiceTask" name="My service task"
implementation="Other" operationRef="myOperation" />服务任务需要一个必填的id和一个可选的 name。implementation元素 是用来表示调用服务的类型。可选值是WebService, Other或者Unspecified。 因为我们只实现了Java调用， 现在只能选择Other。
服务任务将调用一个操作，operation的id 会在operationRef属性中引用。 这样一个操作就是下面实例的 interface的一部分。每个操作都至少有一个 输入信息，并且 最多有一个输出信息。
<interface id="myInterface"
name="org.jbpm.MyJavaServicek">
<operation id="myOperation2" name="myMethod">
<inMessageRef>inputMessage</inMessageRef>
<outMessageRef>outputMessage</outMessageRef>
</bpmn:operation>
</interface>对于java服务，接口的名称用来 指定java类的全类名。操作的名称 用来指定将要调用方法名。 输入/输出信息表示着java方法的参数/返回值， 定义如下所示：
<message id="inputMessage" name="input message" structureRef="myItemDefinition1" />BPMN中很多元素叫做’item感知’，包括这个消息结构。 这意味着它们会在流程执行过程中保存或读取item。 负责这些元素的数据结构需要使用ItemDefinition。 在这个环境下，消息指定了它的数据结构， 通过引用 structureRef属性中定义的ItemDefinition。
<itemDefinition id="myItemDefinition1" >
<jbpm:arg>
<jbpm:object expr="#{var1}" />
</jbpm:arg>
</itemDefinition>
<itemDefinition id="myItemDefinition2">
<jbpm:var name="returnVar" />
</itemDefinition>注意，这写不是标准的BPMN 2.0标准（因此都有’jbpm’的前缀）。 实际上，根据标准，ItemDefinition不应该包含多余一个数据结构定义。 实际在输入参数的映射，使用一个数据结构， 在serviceTask的ioSpecification章节已经完成了。 然而，当前jBPM BPMN 2.0实现还没有实现那个结构。 所以，这意味着当前使用的上面这种方法， 很可能在不久的未来就会出现变化。
重要提醒：接口，ItemDefinitions和消息需要定义在 <process>外边。参考实例 ServiceTaskTest的实际流程和单元测试。
12. 任务：脚本任务
脚本任务时一个自动活动，当到达这个任务的时候 流程引擎会执行一个脚本。脚本任务使用方式如下：
<scriptTask id="scriptTask" name="Script Task" scriptLanguage="bsh">
<script><![CDATA[
for(int i=0; i < input.length; i++){
System.out.println(input[i] + " x 2 = " + (input[i]*2));
}]]>
</script>
</scriptTask>脚本任务，除了必填id和可选的 name之外，还允许指定 scriptLanguage和script。 因为我们使用了JSR-223（java平台的脚本语言），修改脚本语言就需要：
■把scriptLanguage 属性修改为JSR-223兼容的名称
■在classpath下添加JSR规范的ScriptEngine实现
上面的XML对应图形如下所示（添加了空开始和结束事件）。
像上面例子中显示的那样，可以在脚本中使用流程变量。 我们现在可以启动一个这个例子的流程，也要提供一些随机生成的输入变量：
Map<String, Object> variables = new HashMap<String, Object>();
Integer[] values = { 11, 23, 56, 980, 67543, 8762524 };
variables.put("input", values);
executionService.startProcessInstanceBykey("scriptTaskExample", variables);在输出控制台里，我们现在可以看到执行的执行的脚本：
11 x 2 = 22
23 x 2 = 46
56 x 2 = 112
980 x 2 = 1960
67543 x 2 = 135086
8762524 x 2 = 17525048
13. 任务：手工任务
手工任务时一个由外部人员执行的任务，但是没有指定是 一个BPM系统或是一个服务会被调用。在真实世界里，有很多例子： 安装一个电话系统，使用定期邮件发送一封信， 用电话联系客户，等等。
<manualTask id="myManualTask" name="Call customer" />
手工任务的目标更像 文档/建模提醒的，因为它 对流程引擎的运行没有任何意义，因此，当流程引擎遇到一个手工任务时 会简单略过。
14. 任务：java接收任务
receive task是一个任务会等到外部消息的到来。 除了广泛使用的web service用例，规范在其他环境中的使用也是一样的。 web service用例还没有实现， 但是receive task已经可以在java环境中使用了。
receive task显示为一个圆角矩形（和task图形一样） 在左上角有一个小信封的图标。
在java环境中，receive task没有其他属性，除了id和name（可选）， 行为就像是一个等待状态。为了在你的业务流程中使用等待状态， 只需要加入如下几行：
<receiveTask id="receiveTask" name="wait" />流程执行会在这样一个receive task中等待。流程会使用 熟悉的jBPM signal methods来继续执行。 注意，这些可能在未来改变，因为’signal’ 在BPMN 2.0中拥有完全不同的含义。
Execution execution = processInstance.findActiveExecutionIn("receiveTask");
executionService.signalExecutionById(execution.getId());
完全的实例（包括控制台任务表单）
前提条件：为了运行实例，我们假设 已经在JBoss server中安装了jBPM控制台。如果没有， 请先执行’demo.setup.jboss’安装脚本。
我们实现的业务流程实现起来像下面这样：
你可能已经看过这个例子了，因为我们也在发布包中的 实例中使用jPDL实现过它了。
业务流程很简单：一个员工可以启动一个新流程， 申请一定时间的假期。在请求任务完成之后， 经理会在任务列表中看到审核任务。 经理可以决定批准或驳回这个申请。 根据outcome（那是外向顺序流上的小菱形 – 这意味着在顺序流上有条件表达式）， 会发送一个驳回信息或者流程结束。注意，实际上我们这里使用了简写： 不是在’verify request’任务的外向顺序流上设置表达式， 我们可以在用户任务之后使用一个唯一网关来控制流程的流向。 也要注意，因为我们还没有实现泳道（可能在下一个版本会实现）， 所以很难看到谁在业务流程中。
流程的XML版本看起来像下面这样：
<process id="vacationRequestProcess" name="BPMN2 Example process using task forms">
<startEvent id="start" />
<sequenceFlow id="flow1" name="fromStartToRequestVacation"
sourceRef="start" targetRef="requestVacation" />
<userTask id="requestVacation" name="Request Vacation"
implementation="other">
<potentialOwner resourceRef="user" jbpm:type="group">
<resourceAssignmentExpression>
<formalExpression>user</formalExpression>
</resourceAssignmentExpression>
</potentialOwner>
<rendering id="requestForm">
<jbpm:form>org/jbpm/examples/bpmn/usertask/taskform/request_vacation.ftl</jbpm:form>
</rendering>
</userTask>
<sequenceFlow id="flow2"
name="fromRequestVacationToVerifyRequest" sourceRef="requestVacation"
targetRef="verifyRequest" />
<userTask id="verifyRequest" name="Verify Request"
implementation="other">
<potentialOwner resourceRef="user" jbpm:type="group">
<resourceAssignmentExpression>
<formalExpression>manager</formalExpression>
</resourceAssignmentExpression>
</potentialOwner>
<rendering id="verifyForm">
<jbpm:form>org/jbpm/examples/bpmn/usertask/taskform/verify_request.ftl</jbpm:form>
</rendering>
</userTask>
<sequenceFlow id="flow3" name="fromVerifyRequestToEnd"
sourceRef="verifyRequest" targetRef="theEnd">
<conditionExpression xsi:type="tFormalExpression">
${verificationResult == 'OK'}
</conditionExpression>
</sequenceFlow>
<sequenceFlow id="flow4"
name="fromVerifyRequestToSendRejectionMessage" sourceRef="verifyRequest"
targetRef="sendRejectionMessage">
<conditionExpression xsi:type="tFormalExpression">
${verificationResult == 'Not OK'}
</conditionExpression>
</sequenceFlow>
<scriptTask id="sendRejectionMessage" name="Send rejection Message"
scriptLanguage="bsh">
<script>
<![CDATA[System.out.println("Vacation request refused!");]]>
</script>
</scriptTask>
<sequenceFlow id="flow5"
name="fromSendRejectionMessageToEnd" sourceRef="sendRejectionMessage"
targetRef="theEnd" />
<endEvent id="theEnd" name="End" />
</process>注意：当你在安装demo时，自己都已经安装了。 也要注意，我们这里使用了脚本任务，为了快速的编写一些输出， 而不是发送真实的信息（图形显示了一个service task）。 也要注意，我们这里在任务分配中做了一些简略 （会在下一个版本进行修复）。
在这个实现使用的结构中覆盖了之前章节中的所有内容。 也要注意我们这里使用了任务表单功能， 这是一个自定义jBPM扩展， 可以为用户任务渲染元素。
<userTask id="verifyRequest" name="Verify Request"
implementation="other">
<potentialOwner resourceRef="user" jbpm:type="group">
<resourceAssignmentExpression>
<formalExpression>user</formalExpression>
</resourceAssignmentExpression>
</potentialOwner>
<rendering id="verifyForm">
<jbpm:form>org/jbpm/examples/bpmn/usertask/taskform/verify_request.ftl</jbpm:form>
</rendering>
</userTask>BPMN 2.0里任务表单的机制与jPDL里完全一样。 表单自身是一个Freemarker模板文件， 需要放在发布中。比如，这个 ‘verify_request.ftl’ 看起来像下面这样：
<html>
<body>
<form action="${form.action}" method="POST" enctype="multipart/form-data">
<h3>Your employee, ${employee_name} would like to go on vacation</h3>
Number of days: ${number_of_days}<br/>
<hr>
In case you reject, please provide a reason:<br/>
<input type="textarea" name="reason"/><br/>
<input type="submit" name="verificationResult" value="OK">
<input type="submit" name="verificationResult" value="Not OK">
</form>
</body>
</html>注意，流程变量可以使用 ${my_process_variable}来访问。也要注意输入控件的名称。 （比如，输入文本框，提交表单）可以用来 定义新流程变量。 比如，下面的输入文本会被保存为 流程变量’reason’。
<input type="textarea" name="reason"/>注意这里有两个提交按钮（这是当然的，如果你看到’OK’和’Not OK’两个顺序流 从’request vacation’任务里出去了。通过点击其中一个按钮， 流程变量’verificationResult’会被保存起来。 它可以用来执行外出的顺序流：
<sequenceFlow id="flow3" name="fromVerifyRequestToEnd"
sourceRef="verifyRequest" targetRef="theEnd">
<conditionExpression xsi:type="tFormalExpression">
${verificationResult == 'OK'}
</conditionExpression>
</sequenceFlow>
流程现在可以发布了。你可以使用ant的发布任务来做这些事情（参考实例）， 或者你可以指定你的jBPM配置到控制台的数据库。 为了用编程的方式发布你的流程，你需要把任务表单添加到你的发布中：
NewDeployment deployment = repositoryService.createDeployment();
deployment.addResourceFromClasspath("org/jbpm/examples/bpmn/usertask/taskform/vacationrequest.bpmn.xml");
deployment.addResourceFromClasspath("org/jbpm/examples/bpmn/usertask/taskform/request_vacation.ftl");
deployment.addResourceFromClasspath("org/jbpm/examples/bpmn/usertask/taskform/verify_request.ftl");
deployment.deploy();你现在可以嵌入（或在单独的服务器中）这个业务流程，使用熟悉的jBPM API操作。 比如，流程实例现在可以使用 key来启动（比如，BPMN 2.0的流程id）：
ProcessInstance pi = executionService.startProcessInstanceByKey("vacationRequestProcess");任务列表可以这样获得：
Task requestTasktask = taskService.createTaskQuery().candidate("peter").uniqueResult();
当像jBPM控制器数据库发布时，你应该看到我们的新业务流程了。
在你启动一个新流程后，一个新任务应该在员工的任务列表中了。 当点击’view’以后，任务表单会被显示出来， 在这里填写未来会在流程中使用的变量。
在任务结束之后，经理会在他的任务列表中看到新的审核任务。 他现在可以通过或驳回请假申请，基于员工的输入。
因为数据库表结构没有变化，我们只是把BPMN 2.0添加到了jBPM PVM上面， 所有已存的报表都可以用于我们的新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的流程引擎中， 同时依然可以使用强大的图形注解。
历史和目标
jBPM BPMN2的实现是在jBPM 4.0发布之后 在2009年8月，在与社区进行了紧密协作之后启动的。 而后，我们决定了第一个发布版（比如，文档/QA） 涉及一部分BPMN2规范，将在jBPM 4.3发布。
我们的目标是建立一个原生BPMN2运行引擎 （或者说实现’可执行的BPMN2′）基于流程虚拟机 （Process Virtual Machine – PVM）。 注意，这个版本的主要目标是原生可执行， 不是图形注解 – 但是我们清楚 对于未来的版本是很重要的。
如果用户已经了解了jBPM，就会发现 所以，总体来说，我们的主要目标是保持所有在jBPM上好的事情， 加强它们，使用一个标准的流程语言。
■配置结构保持不变
■API与已经存在的完全一样或者很类似
■测试BPMN2流程也可以使用常用的java测试框架
■数据库表结构保持不变
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上， 作为一个扩展，不会出现很多麻烦。
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 much BPMN do you need’( http://www.bpm-research.com/2008/03/03/how-much-bpmn-do-you-need/)， 和我们自己的经验。
我们定义了三种BPMN2结构分类：
■基本：这个分类的结构很直接 并且容易了解。这个分类的结构可以用来为 简单的业务流程建模。
■高级：包含更强大或更复杂的结构， 这些都提高了建模和执行语法的学习曲线。 业务流程的主要目标是使用这个 和之前的分类来实现结构。
■复杂：这个分类的结构用来实现罕见的情况， 或者它们的语法难以理解。
配置
在你的应用中使用BPMN 2.0是很简单的：只要把下面一行 加入jbpm.cfg.xml文件。
<import resource="jbpm.bpmn.cfg.xml" />这里的引用会启用BPMN 2.0的流程发布，通过把BPMN 2.0发布器安装到流程引擎中。 注意流程引擎可以同时使用jPDL和BPMN 2.0流程。 这意味着在你的应用里，一些流程可能是jPDL， 其他的可能是BPMN 2.0。
流程引擎是根据定义文件的后缀来区分流程定义的。 对于BPMN 2.0，使用*.bpmn.xml后缀 （jPDL使用*.jpdl.xml后缀）。
实例
发布中包含的例子也包含了下面章节中 讨论的每个结构的实例。查看BPMN 2.0的流程实例 和测试用例， 在org.jbpm.examples.bpmn.* 包下。
参考用户指南，第二章（安装），研究一下如何导入实例。 查看章节‘导入实例’。
流程根元素
一个BPMN 2.0 XML流程的根是definitions元素。 在命名状态，子元素会包含真正的业务流程定义。 每个process子元素 可以拥有一个id和 name。一个空的BPMN 2.0业务流程 看起来像下面这样。也要注意把BPMN2.xsd放在classpath下， 来启用XML自动补全。
<definitions id="myProcesses"
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 id="myBusinessProcess" name="My business processs">
...
</process>
<definitions>如果一个process元素定义了id，它会作为业务流程的key使用 （比如，启动流程可以通过调用executionService.startProcessInstanceByKey(“myBusinessProcess”)， 否则jBPM引擎会创建一个唯一流程key（与jPDL相同）。
基本结构
1. 事件
与活动和网关一起，事件用来在实际的每个业务流程中。 事件让业务建模工具用很自然的方式描述业务流程，比如 ‘当我接收到客户的订单，这个流程就启动’， ‘如果两天内任务没结束，就终止流程’ 或者‘当我收到一封取消邮件，当流程在运行时， 使用子流程处理邮件’。注意典型的业务 通常使用这种事件驱动的方式。人们不会硬编码顺序创建， 但是他们倾向于使用在他们的环境中发生的事情（比如，事件）。 在BPMN规范中，描述了很多事件类型，为了覆盖可能的事情， 在业务环境中可能出现的情况。
2. 事件：空启动事件
一个启动事件说明了流程的开始（或子流程）。图形形式，它看起来 是一个圆（可能）内部有一个小图标。图标指定了事件的实际类型 会在流程实例创建时被触发。
空启动事件画出来是一个圆，内部没有图标，意思是 这个触发器是未知或者未指定的。jPDL的开始活动基本是一样的语法。 流程实例的流程定义包含一个空启动事件， 可以使用executionService的API调用创建。
一个空开始事件像下面这样定义。id是必填的，name是可选的。
<startEvent id="start" name="myStart" />
3. 事件：空结束事件
结束事件指定了流程实例中一个流程路径的结束。 图形上，它看起来就是一个圆 拥有厚边框（可能） 内部有小图标。 图标指定了结束的时候 会执行哪种操作。
空结束事件画出来是一个圆，拥有厚边框，内部没有图标， 这意味着当流程到达事件时，不会抛出任何信号。 jPDL中的结束事件与空结束事件语义相同。
空结束事件可以像下面一样定义，id是必填的，name是可选的。
<endEvent id="end" name="myEnd" />
下面的例子显示了只使用空开始和结束事件的流程：
这个流程对应的可执行XML像这样 （忽略声明用的definitions根元素）
<process id="noneStartEndEvent" name="BPMN2 Example none start and end event">
<startEvent id="start" />
<sequenceFlow id="flow1" name="fromStartToEnd"
sourceRef="start" targetRef="end" />
<endEvent id="end" name="End" />
</process>
现在可以通过调用startProcessInstanceXXX操作， 创建一个流程实例。
ProcessInstance processInstance = executionService.startProcessInstanceByKey("noneStartEndEvent");
4. 事件：终止结束事件
终止和空结束事件的区别是 实际中流程的路径是如何处理的（或者使用BPMN 2.0的术语叫做token）。 终止结束事件会结束整个流程实例，而空结束事件只会结束当前流程路径。 他们都不会抛出任何事情 当到达结束事件的时候。
一个终止结束事件可以像下面定义。id是必填的，name是可选的。
<endEvent id="terminateEnd" name="myTerminateEnd">
<terminateEventDefinition/>
</endEvent>
终止结束事件被描绘成结束事件一样（圆，厚边框）， 内部图标时一个完整的圆。在下面的例子中，完成task1 会结束流程实例，当完成task2时只会结束到达结束事件 的流程路径，只剩下task1打开。
参考jBPM发布包中的实例， 单元测试和业务流程对应XML。
5. 顺序流
顺序流是事件，活动和网关之间的连线，显示为一条实线 带有箭头，在BPMN图形中（jPDL中等效的是transition）。 每个顺序流都有一个源头和一个 目标引用，包含了 活动，事件或网关的id。
<sequenceFlow id="myFlow" name="My Flow"
sourceRef="sourceId" targetRef="targetId" />
与jPDL的一个重要区别是多外向顺序流的行为。 在jPDL中，只有一个转移会成为外向转移，除非活动是fork （或自定义活动拥有fork行为）。然而，在BPMN中， 多外向顺序流的默认行为是切分进入的token（jBPM中术语叫做execution） 分成token集合，每个顺序流一个。在下面情况中， 在完成第一个任务，就会激活三个任务。
为了避免使用一个顺序流，必须添加condition条件到顺序流中。 在运行时，只有当condition条件结果为true， 顺序流才会被执行。
为了给顺序流添加condition条件，添加一个conditionExpression 元素到顺序流中。条件可以放在 ${}中。
<sequenceFlow id=....>
<conditionExpression xsi:type="tFormalExpression">${amount >= 500}</conditionExpression>
</sequenceFlow>注意，当前必须把 xsi:type=”tFormalExpression”添加到 conditionExpression中。在未来的版本中可能会修改。
活动（比如用户任务）和网关（比如唯一网关）可以用户默认顺序流。 默认顺序流只会在活动或网关的 所有其他外向顺序流的condition条件为false时才会使用。 默认顺序流图形像是顺序流多了一个斜线标记。
默认顺序流通过指定活动或网关的 ‘default’ 属性 来使用。
也要注意，默认顺序流上的表达式会被忽略。
6. 网关
BPMN中的网关是用来控制流程中的流向的。更确切的是， 当一个token（BPMN 2.0中execution的概念注解）到达一个网关， 它会根据网关的类型进行合并或切分。
网关描绘成一个菱形，使用一个内部图标来指定类型 （唯一，广泛，其他）。
所有网关类型，都可以设置gatewayDirection。 下面的值可以使用：
■unspecificed (默认)：网关可能拥有多个 进入和外出顺序流。
■mixed：网关必须拥有多个 进入和外出顺序流。
■converging：网关必须拥有多个进入顺序流， 但是只能有一个外出顺序流。
■diverging：网关必须拥有一个进入顺序流， 和多个外出顺序流。
比如下面的例子：并行网关的gatewayDirection属性为’converging’， 会拥有json行为。
<parallelGateway id="myJoin" name="My synchronizing join" gatewayDirection="converging" />注意：gatewayDirection属性根据规范是可选的。 这意味着我们不能通过这个属性来 在运行时知道一个网关的行为（比如，一个并行网关， 如果我们用够切分和合并行为）。然而，gatewayDirection属性用在解析时 作为约束条件对进入、外出顺序流。所以使用这个属性 会减低出错的机会，当引用顺序流时， 但不是必填的。
7. 网关：唯一网关
唯一网关表达了一个流程中的唯一决策。 会有一个外向顺序流被使用，根据定义在 顺序流中的条件。
对应的jPDL结构，相同的语法是 decision活动。唯一网关的 完全技术名称是‘基于数据的唯一网关’， 但是也经常称为XOR 网关。 XOR网关被描绘为一个菱形，内部有一个’X'， 一个空的菱形，没有网关也象征着唯一网关。
下面图形显示了唯一网关的用法：根据amount变量的值， 会选择唯一网关外向的三个外向顺序流 中的一个。
这个流程对应的可执行XML看起来像下面这样。 注意定义在顺序流中的条件。唯一网关会选择一个顺序流， 如果条件执行为true。如果多个条件 执行为true，第一个遇到的就会被使用 （日志信息会显示这种情况）。
<process id="exclusiveGateway" name="BPMN2 Example exclusive gateway">
<startEvent id="start" />
<sequenceFlow id="flow1" name="fromStartToExclusiveGateway"
sourceRef="start" targetRef="decideBasedOnAmountGateway" />
<exclusiveGateway id="decideBasedOnAmountGateway" name="decideBasedOnAmount" />
<sequenceFlow id="flow2" name="fromGatewayToEndNotEnough"
sourceRef="decideBasedOnAmountGateway" targetRef="endNotEnough">
<conditionExpression xsi:type="tFormalExpression">
${amount < 100}
</conditionExpression>
</sequenceFlow>
<sequenceFlow id="flow3" name="fromGatewayToEnEnough"
sourceRef="decideBasedOnAmountGateway" targetRef="endEnough">
<conditionExpression xsi:type="tFormalExpression">
${amount <= 500 && amount >= 100}
</conditionExpression>
</sequenceFlow>
<sequenceFlow id="flow4" name="fromGatewayToMoreThanEnough"
sourceRef="decideBasedOnAmountGateway" targetRef="endMoreThanEnough">
<conditionExpression xsi:type="tFormalExpression">
${amount > 500}
</conditionExpression>
</sequenceFlow>
<endEvent id="endNotEnough" name="not enough" />
<endEvent id="endEnough" name="enough" />
<endEvent id="endMoreThanEnough" name="more than enough" />
</process>这个流程需要一个变量，这样表达式就可以在运行期间执行。 变量可以被提供，当流程实例执行的时候（类似jPDL）。
Map<String, Object> vars = new HashMap<String, Object>();
vars.put("amount", amount);
ProcessInstance processInstance = executionService.startProcessInstanceByKey("exclusiveGateway", vars);
唯一网关需要所有外向顺序流上都定义条件。 对这种规则一种例外是默认顺序流。 使用default 属性来引用一个已存在的 顺序流的id。这个顺序流会被使用 当其他外向顺序流的条件都执行为false时。
<exclusiveGateway id="decision" name="decideBasedOnAmountAndBankType" default="myFlow"/>
<sequenceFlow id="myFlow" name="fromGatewayToStandard"
sourceRef="decision" targetRef="standard">
</sequenceFlow>
8. 网关：并行网关
并行网关用来切分或同步相关的进入或外出 顺序流。
■并行网关拥有一个进入顺序流的和多于一个的外出顺序流 叫做‘并行切分或 ‘AND-split’。所有外出顺序流都会 被并行使用。注意：像规范中定义的那样， 外出顺序流中的条件都会被忽略。
■并行网关拥有多个进入顺序流和一个外出顺序流 叫做‘并行归并’或 AND-join。所有进入顺序流需要 到达这个并行归并，在外向顺序流使用之前。
并行网关像下面这样定义：
<parallelGateway id="myParallelGateway" name="My Parallel Gateway" />注意，gatewayDirection属性可以被使用， 已获得建模错误，在解析阶段（参考上面）。
下面的图形显示了一个并行网关可以如何使用。在流程启动后， ‘prepare shipment’ 和 ‘bill customer’用户任务都会被激活。 并行网关被描绘为一个菱形，内部图标是一个十字， 对切分和归并行为都是一样。
图形对应的XML如下所示：
<process id="parallelGateway" name="BPMN2 example parallel gatewar">
<startEvent id="Start" />
<sequenceFlow id="flow1" name="fromStartToSplit"
sourceRef="Start"
targetRef="parallelGatewaySplit" />
<parallelGateway id="parallelGatewaySplit" name="Split"
gatewayDirection="diverging"/>
<sequenceFlow id="flow2a" name="Leg 1"
sourceRef="parallelGatewaySplit"
targetRef="prepareShipment" />
<userTask id="prepareShipment" name="Prepare shipment"
implementation="other" />
<sequenceFlow id="flow2b" name="fromPrepareShipmentToJoin"
sourceRef="prepareShipment"
targetRef="parallelGatewayJoin" />
<sequenceFlow id="flow3a" name="Leg 2"
sourceRef="parallelGatewaySplit"
targetRef="billCustomer" />
<userTask id="billCustomer" name="Bill customer"
implementation="other" />
<sequenceFlow id="flow3b" name="fromLeg2ToJoin"
sourceRef="billCustomer"
targetRef="parallelGatewayJoin" />
<parallelGateway id="parallelGatewayJoin" name="Join"
gatewayDirection="converging"/>
<sequenceFlow id="flow4"
sourceRef="parallelGatewayJoin"
targetRef="End">
</sequenceFlow>
<endEvent id="End" name="End" />
</process>
9. 任务
一个任务表示工作需要被外部实体完成， 比如人工或自动服务。
重要的是注意BPMN语法的’task’与jPDL语法的区别。 在jPDL中，’task’的概念总是用在人工做一些事情的环境。 的那个流程引擎遇到jPDL中的task，它会创建一个task， 交给一些人的任务列表，然后它会进入等待状态。然而在BPMN 2.0中， 这里有很多任务类型，一些表示等待状态（比如，User Task 一些表示自动活动（比如，Service Task。 所以小心不要混淆了任务的概念，在切换语言的时候。
任务被描绘成一个圆角矩形，一般内部包含文字。 任务的类型（用户任务，服务任务，脚本任务，等等）显示在矩形的左上角，用小图标区别。 根据任务的类型， 引擎会执行不同的功能。
10. 任务：人工任务
user task是典型的’人工任务’， 实际中的每个workflow或BPMN软件中都可以找到。当流程执行到达这样一个user task时， 一个新人工任务就会被创建，交给用户的任务列表。
和manual task的主要区别是 （也与人工工作对应）是流程引擎了解任务。 引擎可以跟踪竞争，分配，时间，其他，这些不是manual task的情况。
user task描绘为一个圆角矩形，在左上角是一个小用户图标。
user task被定义为下面的BPMN 2.0 XML：
<userTask id="myTask" name="My task" />根据规范，可以使用多种实现（WebService, WS-humantask，等等）。 通过使用implementation属性。 当前，只有标准的jBPM任务机制才可以用，所以这里（还）没有 定义’implementation’属性的功能。
BPMN 2.0规范包含了一些方法把任务分配给用户，组，角色等等。 当前的BPMN 2.0 jBPM实现允许使用一个 resourceAssignmentExpression来分配任务， 结合humanPerformer or PotentialOwner结构。 这部分希望在未来的版本里能够进一步演化。
potentialOwner用来在你希望确定用户，组，角色的时候。 这是一个task的候选人。 参考下面的例子。这里的’My task’任务的候选人组是’management’用户组。 也要注意，需要在流程外部定义一个资源， 这样任务分配器可以引用到这个资源。 实际上，任何活动都可以引用一个或多个资源元素。 目前，只需要定义这个资源就可以了（因为它是规范中的一个必须的元素）， 但是在以后的发布中会进行加强（比如，资源可以拥有运行时参数）。
<resource id="manager" name="manager" />
<process ...>
...
<userTask id="myTask" name="My task">
<potentialOwner resourceRef="manager" jbpm:type="group">
<resourceAssignmentExpression>
<formalExpression>management</formalExpression>
</resourceAssignmentExpression>
</potentialOwner>
</userTask>注意，我们使用了一个特定的后缀 (jbpm:type=”group”)，来定义这是一个用户组的分配方式。 如果删除了这个属性，就会默认使用用户组的语法 （在这个例子中也是没问题的）。 现在假设Peter和Mary是management组的成员 (这里使用默认的身份服务)：
identityService.createGroup("management");
identityService.createUser("peter", "Peter", "Pan");
identityService.createMembership("peter", "management");
identityService.createUser("mary", "Mary", "Littlelamb");
identityService.createMembership("mary", "management"); Peter和Mary都可以在他们的任务列表中看到这条任务 （代码来自实例单元测试）：
// Peter and Mary are both part of management, so they both should see the task
List<Task> tasks = taskService.findGroupTasks("peter");
assertEquals(1, tasks.size());
tasks = taskService.findGroupTasks("mary");
assertEquals(1, tasks.size());
// Mary claims the task
Task task = tasks.get(0);
taskService.takeTask(task.getId(), "mary");
assertNull(taskService.createTaskQuery().candidate("peter").uniqueResult());
taskService.completeTask(task.getId());
assertProcessInstanceEnded(processInstance);当分配方式应该是候选用户时， 只需要使用jbpm:type=”user”属性。
<userTask id="myTask" name="My User task">
<potentialOwner resourceRef="employee" jbpm:type="user">
<resourceAssignmentExpression>
<formalExpression>peter</formalExpression>
</resourceAssignmentExpression>
</potentialOwner>
</userTask>在这个例子里，Peter将可以看到任务，因为他是这个任务的候选用户。
List<Task> tasks = taskService.createTaskQuery().candidate("peter").list();
human performer用来，当你想把一个任务直接分配给一个人， 组，角色时。这个方法的使用方式 看起来和potential owner很像。
<resource id="employee" name="employee" />
<process ...>
...
<userTask id="myTask" name="My User task">
<humanPerformer resourceRef="employee">
<resourceAssignmentExpression>
<formalExpression>mary</formalExpression>
</resourceAssignmentExpression>
</humanPerformer>
</userTask>在这个例子中，任务会直接分配给Mary。 她可以在自己的任务列表中看到这个任务：
List<Task> tasks = taskService.findPersonalTasks("mary");
因为任务分配已经完成，通过使用 formalExpression，它也可以定义表达式 在运行期解析。表达式本身需要放在 ${}中，这和jBPM一样。 比如，如果流程变量’user’被定义了，然后，它可以用在表达式中。 当然也可以使用更复杂的表达式。
<userTask id="myTask" name="My User task">
<humanPerformer resourceRef="employee">
<resourceAssignmentExpression>
<formalExpression>${user}</formalExpression>
</resourceAssignmentExpression>
</humanPerformer>
</userTask>注意不需要在humanPerformer元素中使用’jbpm:type’，因为只能进行 直接用户分配。如果任务需要被分配给一个角色或一个组， 使用potentialOwner和group类型（当你把任务分配给一个组时， 组中的所有成员都会成为候选用户 – 参考potentialOwner的用法）。
11. 任务：Java服务任务
Service Task是一个自动活动，它会调用一些服务， 比如web service，java service等等。当前jBPM引擎 只支持调用java service，但是web service的调用 已经在未来的版本中做了计划。
定义一个服务任务需要好几行XML（这里就可以看到BPEL的影响力）。 当然，在不久的未来，我们希望有工具可以把这部分大量的简化。 一个服务任务需要如下定义：
<serviceTask id="MyServiceTask" name="My service task"
implementation="Other" operationRef="myOperation" />服务任务需要一个必填的id和一个可选的 name。implementation元素 是用来表示调用服务的类型。可选值是WebService, Other或者Unspecified。 因为我们只实现了Java调用， 现在只能选择Other。
服务任务将调用一个操作，operation的id 会在operationRef属性中引用。 这样一个操作就是下面实例的 interface的一部分。每个操作都至少有一个 输入信息，并且 最多有一个输出信息。
<interface id="myInterface"
name="org.jbpm.MyJavaServicek">
<operation id="myOperation2" name="myMethod">
<inMessageRef>inputMessage</inMessageRef>
<outMessageRef>outputMessage</outMessageRef>
</bpmn:operation>
</interface>对于java服务，接口的名称用来 指定java类的全类名。操作的名称 用来指定将要调用方法名。 输入/输出信息表示着java方法的参数/返回值， 定义如下所示：
<message id="inputMessage" name="input message" structureRef="myItemDefinition1" />BPMN中很多元素叫做’item感知’，包括这个消息结构。 这意味着它们会在流程执行过程中保存或读取item。 负责这些元素的数据结构需要使用ItemDefinition。 在这个环境下，消息指定了它的数据结构， 通过引用 structureRef属性中定义的ItemDefinition。
<itemDefinition id="myItemDefinition1" >
<jbpm:arg>
<jbpm:object expr="#{var1}" />
</jbpm:arg>
</itemDefinition>
<itemDefinition id="myItemDefinition2">
<jbpm:var name="returnVar" />
</itemDefinition>注意，这写不是标准的BPMN 2.0标准（因此都有’jbpm’的前缀）。 实际上，根据标准，ItemDefinition不应该包含多余一个数据结构定义。 实际在输入参数的映射，使用一个数据结构， 在serviceTask的ioSpecification章节已经完成了。 然而，当前jBPM BPMN 2.0实现还没有实现那个结构。 所以，这意味着当前使用的上面这种方法， 很可能在不久的未来就会出现变化。
重要提醒：接口，ItemDefinitions和消息需要定义在 <process>外边。参考实例 ServiceTaskTest的实际流程和单元测试。
12. 任务：脚本任务
脚本任务时一个自动活动，当到达这个任务的时候 流程引擎会执行一个脚本。脚本任务使用方式如下：
<scriptTask id="scriptTask" name="Script Task" scriptLanguage="bsh">
<script><![CDATA[
for(int i=0; i < input.length; i++){
System.out.println(input[i] + " x 2 = " + (input[i]*2));
}]]>
</script>
</scriptTask>脚本任务，除了必填id和可选的 name之外，还允许指定 scriptLanguage和script。 因为我们使用了JSR-223（java平台的脚本语言），修改脚本语言就需要：
■把scriptLanguage 属性修改为JSR-223兼容的名称
■在classpath下添加JSR规范的ScriptEngine实现
上面的XML对应图形如下所示（添加了空开始和结束事件）。
像上面例子中显示的那样，可以在脚本中使用流程变量。 我们现在可以启动一个这个例子的流程，也要提供一些随机生成的输入变量：
Map<String, Object> variables = new HashMap<String, Object>();
Integer[] values = { 11, 23, 56, 980, 67543, 8762524 };
variables.put("input", values);
executionService.startProcessInstanceBykey("scriptTaskExample", variables);在输出控制台里，我们现在可以看到执行的执行的脚本：
11 x 2 = 22
23 x 2 = 46
56 x 2 = 112
980 x 2 = 1960
67543 x 2 = 135086
8762524 x 2 = 17525048
13. 任务：手工任务
手工任务时一个由外部人员执行的任务，但是没有指定是 一个BPM系统或是一个服务会被调用。在真实世界里，有很多例子： 安装一个电话系统，使用定期邮件发送一封信， 用电话联系客户，等等。
<manualTask id="myManualTask" name="Call customer" />
手工任务的目标更像 文档/建模提醒的，因为它 对流程引擎的运行没有任何意义，因此，当流程引擎遇到一个手工任务时 会简单略过。
14. 任务：java接收任务
receive task是一个任务会等到外部消息的到来。 除了广泛使用的web service用例，规范在其他环境中的使用也是一样的。 web service用例还没有实现， 但是receive task已经可以在java环境中使用了。
receive task显示为一个圆角矩形（和task图形一样） 在左上角有一个小信封的图标。
在java环境中，receive task没有其他属性，除了id和name（可选）， 行为就像是一个等待状态。为了在你的业务流程中使用等待状态， 只需要加入如下几行：
<receiveTask id="receiveTask" name="wait" />流程执行会在这样一个receive task中等待。流程会使用 熟悉的jBPM signal methods来继续执行。 注意，这些可能在未来改变，因为’signal’ 在BPMN 2.0中拥有完全不同的含义。
Execution execution = processInstance.findActiveExecutionIn("receiveTask");
executionService.signalExecutionById(execution.getId());
完全的实例（包括控制台任务表单）
前提条件：为了运行实例，我们假设 已经在JBoss server中安装了jBPM控制台。如果没有， 请先执行’demo.setup.jboss’安装脚本。
我们实现的业务流程实现起来像下面这样：
你可能已经看过这个例子了，因为我们也在发布包中的 实例中使用jPDL实现过它了。
业务流程很简单：一个员工可以启动一个新流程， 申请一定时间的假期。在请求任务完成之后， 经理会在任务列表中看到审核任务。 经理可以决定批准或驳回这个申请。 根据outcome（那是外向顺序流上的小菱形 – 这意味着在顺序流上有条件表达式）， 会发送一个驳回信息或者流程结束。注意，实际上我们这里使用了简写： 不是在’verify request’任务的外向顺序流上设置表达式， 我们可以在用户任务之后使用一个唯一网关来控制流程的流向。 也要注意，因为我们还没有实现泳道（可能在下一个版本会实现）， 所以很难看到谁在业务流程中。
流程的XML版本看起来像下面这样：
<process id="vacationRequestProcess" name="BPMN2 Example process using task forms">
<startEvent id="start" />
<sequenceFlow id="flow1" name="fromStartToRequestVacation"
sourceRef="start" targetRef="requestVacation" />
<userTask id="requestVacation" name="Request Vacation"
implementation="other">
<potentialOwner resourceRef="user" jbpm:type="group">
<resourceAssignmentExpression>
<formalExpression>user</formalExpression>
</resourceAssignmentExpression>
</potentialOwner>
<rendering id="requestForm">
<jbpm:form>org/jbpm/examples/bpmn/usertask/taskform/request_vacation.ftl</jbpm:form>
</rendering>
</userTask>
<sequenceFlow id="flow2"
name="fromRequestVacationToVerifyRequest" sourceRef="requestVacation"
targetRef="verifyRequest" />
<userTask id="verifyRequest" name="Verify Request"
implementation="other">
<potentialOwner resourceRef="user" jbpm:type="group">
<resourceAssignmentExpression>
<formalExpression>manager</formalExpression>
</resourceAssignmentExpression>
</potentialOwner>
<rendering id="verifyForm">
<jbpm:form>org/jbpm/examples/bpmn/usertask/taskform/verify_request.ftl</jbpm:form>
</rendering>
</userTask>
<sequenceFlow id="flow3" name="fromVerifyRequestToEnd"
sourceRef="verifyRequest" targetRef="theEnd">
<conditionExpression xsi:type="tFormalExpression">
${verificationResult == 'OK'}
</conditionExpression>
</sequenceFlow>
<sequenceFlow id="flow4"
name="fromVerifyRequestToSendRejectionMessage" sourceRef="verifyRequest"
targetRef="sendRejectionMessage">
<conditionExpression xsi:type="tFormalExpression">
${verificationResult == 'Not OK'}
</conditionExpression>
</sequenceFlow>
<scriptTask id="sendRejectionMessage" name="Send rejection Message"
scriptLanguage="bsh">
<script>
<![CDATA[System.out.println("Vacation request refused!");]]>
</script>
</scriptTask>
<sequenceFlow id="flow5"
name="fromSendRejectionMessageToEnd" sourceRef="sendRejectionMessage"
targetRef="theEnd" />
<endEvent id="theEnd" name="End" />
</process>注意：当你在安装demo时，自己都已经安装了。 也要注意，我们这里使用了脚本任务，为了快速的编写一些输出， 而不是发送真实的信息（图形显示了一个service task）。 也要注意，我们这里在任务分配中做了一些简略 （会在下一个版本进行修复）。
在这个实现使用的结构中覆盖了之前章节中的所有内容。 也要注意我们这里使用了任务表单功能， 这是一个自定义jBPM扩展， 可以为用户任务渲染元素。
<userTask id="verifyRequest" name="Verify Request"
implementation="other">
<potentialOwner resourceRef="user" jbpm:type="group">
<resourceAssignmentExpression>
<formalExpression>user</formalExpression>
</resourceAssignmentExpression>
</potentialOwner>
<rendering id="verifyForm">
<jbpm:form>org/jbpm/examples/bpmn/usertask/taskform/verify_request.ftl</jbpm:form>
</rendering>
</userTask>BPMN 2.0里任务表单的机制与jPDL里完全一样。 表单自身是一个Freemarker模板文件， 需要放在发布中。比如，这个 ‘verify_request.ftl’ 看起来像下面这样：
<html>
<body>
<form action="${form.action}" method="POST" enctype="multipart/form-data">
<h3>Your employee, ${employee_name} would like to go on vacation</h3>
Number of days: ${number_of_days}<br/>
<hr>
In case you reject, please provide a reason:<br/>
<input type="textarea" name="reason"/><br/>
<input type="submit" name="verificationResult" value="OK">
<input type="submit" name="verificationResult" value="Not OK">
</form>
</body>
</html>注意，流程变量可以使用 ${my_process_variable}来访问。也要注意输入控件的名称。 （比如，输入文本框，提交表单）可以用来 定义新流程变量。 比如，下面的输入文本会被保存为 流程变量’reason’。
<input type="textarea" name="reason"/>注意这里有两个提交按钮（这是当然的，如果你看到’OK’和’Not OK’两个顺序流 从’request vacation’任务里出去了。通过点击其中一个按钮， 流程变量’verificationResult’会被保存起来。 它可以用来执行外出的顺序流：
<sequenceFlow id="flow3" name="fromVerifyRequestToEnd"
sourceRef="verifyRequest" targetRef="theEnd">
<conditionExpression xsi:type="tFormalExpression">
${verificationResult == 'OK'}
</conditionExpression>
</sequenceFlow>
流程现在可以发布了。你可以使用ant的发布任务来做这些事情（参考实例）， 或者你可以指定你的jBPM配置到控制台的数据库。 为了用编程的方式发布你的流程，你需要把任务表单添加到你的发布中：
NewDeployment deployment = repositoryService.createDeployment();
deployment.addResourceFromClasspath("org/jbpm/examples/bpmn/usertask/taskform/vacationrequest.bpmn.xml");
deployment.addResourceFromClasspath("org/jbpm/examples/bpmn/usertask/taskform/request_vacation.ftl");
deployment.addResourceFromClasspath("org/jbpm/examples/bpmn/usertask/taskform/verify_request.ftl");
deployment.deploy();你现在可以嵌入（或在单独的服务器中）这个业务流程，使用熟悉的jBPM API操作。 比如，流程实例现在可以使用 key来启动（比如，BPMN 2.0的流程id）：
ProcessInstance pi = executionService.startProcessInstanceByKey("vacationRequestProcess");任务列表可以这样获得：
Task requestTasktask = taskService.createTaskQuery().candidate("peter").uniqueResult();
当像jBPM控制器数据库发布时，你应该看到我们的新业务流程了。
在你启动一个新流程后，一个新任务应该在员工的任务列表中了。 当点击’view’以后，任务表单会被显示出来， 在这里填写未来会在流程中使用的变量。
在任务结束之后，经理会在他的任务列表中看到新的审核任务。 他现在可以通过或驳回请假申请，基于员工的输入。
因为数据库表结构没有变化，我们只是把BPMN 2.0添加到了jBPM PVM上面， 所有已存的报表都可以用于我们的新BPMN 2.0流程中。