Chapter 1. 简介

Chapter 2. 开始学习

Chapter 3. 配置

• org.activiti.engine.delegate.event.BaseEntityEventListener：   这个事件监听器的基类可以用来监听实体相关的事件，可以针对某一类型实体，也可以是全部实体。   它隐藏了类型检测，并提供了三个需要重写的方法：onCreate(..), onUpdate(..) 和 onDelete(..)，当实体创建，更新，或删除时调用。对于其他实体相关的事件，会调用    onEntityEvent(..)。

下面代码为一个流程定义添加了两个监听器。第一个监听器会接收所有类型的事件，它是通过全类名定义的。 第二个监听器只接收作业成功或失败的事件，它使用了定义在流程引擎配置中的beans属性中的一个bean。

<processid="testEventListeners">   <extensionElements>     <activiti:eventListenerclass="org.activiti.engine.test.MyEventListener"/>     <activiti:eventListenerdelegateExpression="${testEventListener}"events="JOB_EXECUTION_SUCCESS,JOB_EXECUTION_FAILURE"/>   </extensionElements>
  ...
</process>

对于实体相关的事件，也可以设置为针对某个流程定义的监听器，实现只监听发生在某个流程定义上的某个类型实体事件。   下面的代码演示了如何实现这种功能。可以用于所有实体事件（第一个例子），也可以只监听特定类型的事件（第二个例子）。

<processid="testEventListeners">   <extensionElements>     <activiti:eventListenerclass="org.activiti.engine.test.MyEventListener"entityType="task"/>     <activiti:eventListenerdelegateExpression="${testEventListener}"events="ENTITY_CREATED"entityType="task"/>   </extensionElements>
  ...
</process>

entityType支持的值有：attachment, comment, execution,identity-link, job, process-instance, process-definition, task。

[试验阶段]

另一种处理事件的方法是抛出一个BPMN事件。请注意它只针对与抛出一个activiti事件类型的BPMN事件。 比如，抛出一个BPMN事件，在流程实例删除时，会导致一个错误。 下面的代码演示了如何在流程实例中抛出一个signal，把signal抛出到外部流程（全局），在流程实例中抛出一个消息事件， 在流程实例中抛出一个错误事件。除了使用class或delegateExpression， 还使用了throwEvent属性，通过额外属性，指定了抛出事件的类型。

<processid="testEventListeners">   <extensionElements>     <activiti:eventListenerthrowEvent="signal"signalName="My signal"events="TASK_ASSIGNED"/>   </extensionElements></process>

<processid="testEventListeners">   <extensionElements>     <activiti:eventListenerthrowEvent="globalSignal"signalName="My signal"events="TASK_ASSIGNED"/>   </extensionElements></process>

<processid="testEventListeners">   <extensionElements>     <activiti:eventListenerthrowEvent="message"messageName="My message"events="TASK_ASSIGNED"/>   </extensionElements></process>

<processid="testEventListeners">   <extensionElements>     <activiti:eventListenerthrowEvent="error"errorCode="123"events="TASK_ASSIGNED"/>   </extensionElements></process>

如果需要声明额外的逻辑，是否抛出BPMN事件，可以扩展activiti提供的监听器类。在子类中重写isValidEvent(ActivitiEvent event)， 可以防止抛出BPMN事件。对应的类是org.activiti.engine.test.api.event.SignalThrowingEventListenerTest, org.activiti.engine.impl.bpmn.helper.MessageThrowingEventListener 和 org.activiti.engine.impl.bpmn.helper.ErrorThrowingEventListener.

Table 3.2. 支持的事件

• ENTITY_CREATED, ENTITY_INITIALIZED, ENTITY_DELETED: Attachment, Comment, Deployment, Execution, Group, IdentityLink, Job, Model, ProcessDefinition, ProcessInstance, Task, User.

• ENTITY_UPDATED: Attachment, Deployment, Execution, Group, IdentityLink, Job, Model, ProcessDefinition, ProcessInstance, Task, User.

• ENTITY_SUSPENDED, ENTITY_ACTIVATED: ProcessDefinition, ProcessInstance/Execution, Task.

Chapter 4. Activiti API

Chapter 5. Spring集成

Chapter 6. 部署

Chapter 7. BPMN 2.0介绍

• （空）开始事件   是我们流程的入口。

• 用户任务是流程中与操作者相关的任务声明。   注意第一个任务分配给accountancy组，   第二个任务分配给management组。   参考用户任务分配章节   了解更多关于用户任务分配人员和群组的问题。

• 当流程达到空结束事件就会结束。

• 这些元素都使用连线连接。   这些连线拥有source 和 target属性，   定义了连线的方向。

• 流程定义会保存到持久化的数据存储里，   是为你的Activiti引擎特别配置。所以部署好你的业务流程，   我们就能确认引擎重启后还能找到流程定义。

• BPMN 2.0流程文件会解析成内存对象模型，   可以通过Activiti API操作。

• 定义网关来实现决策环节。   这样，经理可以驳回财报，   重新给会计创建一个任务。

• 考虑使用变量，   这样我们可以保存或引用报告，   把它显示到表单中。

• 在流程最后加入服务任务，   把报告发给每个领导。

• 其他

Chapter 8. BPMN 2.0结构

• timeDate。使用 ISO 8601 格式指定一个确定的时间，触发事件的时间。示例：

  <timerEventDefinition>     <timeDate>2011-03-11T12:13:14</timeDate></timerEventDefinition>

• timeDuration。指定定时器之前要等待多长时间， timeDuration可以设置为timerEventDefinition的子元素。 使用ISO 8601规定的格式 （由BPMN 2.0规定）。示例（等待10天）。

  <timerEventDefinition>     <timeDuration>P10D</timeDuration></timerEventDefinition>

• timeCycle。指定重复执行的间隔，   可以用来定期启动流程实例，或为超时时间发送多个提醒。    timeCycle元素可以使用两种格式。第一种是    ISO 8601    标准的格式。示例（重复3次，每次间隔10小时）：

  <timerEventDefinition>     <timeCycle>R3/PT10H</timeCycle></timerEventDefinition>

  另外，你可以使用cron表达式指定timeCycle，下面的例子是从整点开始，每5分钟执行一次：

  00/5***?

  请参考教程   来了解如何使用cron表达式。

  注意： 第一个数字表示秒，而不是像通常Unix cron中那样表示分钟。

  重复的时间周期能更好的处理相对时间，它可以计算一些特定的时间点   （比如，用户任务的开始时间），而cron表达式可以处理绝对时间 -    这对定时启动事件特别有用。

既可以通过bpmn节点由流程实例触发一个信号，也可以通过API触发。 下面的org.activiti.engine.RuntimeService中的方法 可以用来手工触发一个信号。

RuntimeService.signalEventReceived(String signalName);RuntimeService.signalEventReceived(String signalName,String executionId);                                 

signalEventReceived(String signalName);和 signalEventReceived(String signalName, String executionId);之间的区别是 第一个方法会把信号发送给全局所有订阅的处理器（广播语义）， 第二个方法只把信息发送给指定的执行。

信号事件可以被中间捕获信号事件或边界信息事件捕获。

可以查询所有订阅了特定信号事件的执行：

 List<Execution> executions = runtimeService.createExecutionQuery()       .signalEventSubscriptionName("alert")       .list();                 

我们可以使用signalEventReceived(String signalName, String executionId)方法 吧信号发送给这些执行。

默认，信号会在流程引擎范围内进行广播。就是说，    你可以在一个流程实例中抛出一个信号事件，其他不同流程定义的流程实例    都可以监听到这个事件。

然而，有时只希望在同一个流程实例中响应这个信号事件。 比如一个场景是，流程实例中的同步机制，如果两个或更多活动是互斥的。

如果想要限制信号事件的范围，可以使用信号事件定义的scope 属性    （不是BPMN2.0的标准属性）：

<signalid="alertSignal"name="alert"activiti:scope"processInstance"/>

The default value for this is attribute is "global".

下面是两个不同流程使用信号交互的例子。第一个流程在保险规则更新或改变时启动。 在修改被参与者处理时，会触发一个信息，通知规则改变：

这个时间会被所有感兴趣的流程实例捕获。下面是一个订阅这个事件的流程实例。

注意：要了解信号事件是广播给所有 激活的处理器的。 这意味着在上面的例子中，所有流程实例都会接收到这个事件。 这就是我们想要的。然而，有的情况下并不想要这种广播行为。 考虑下面的流程：

上述流程描述的模式activiti并不支持。这种想法是执行“do something”任务时出现的错误，会被边界错误事件捕获， 然后使用信号传播给并发路径上的分支，进而中断"do something inparallel"任务。 目前，activiti实际运行的结果与期望一致。信号会传播给边界事件并中断任务。 但是，根据信号的广播含义，它也会传播给所有其他订阅了信号事件的流程实例。 所以，这就不是我们想要的结果。

注意： 信号事件不会执行任何与特定流程实例的联系。 如果你只想把一个信息发给指定的流程实例，需要手工关联，再使用 signalEventReceived(String signalName, String executionId)和对应的 查询机制。

作为一个嵌入式的流程引擎，activiti不能真正接收一个消息。这些环境相关，与平台相关的活动 比如连接到JMS（Java消息服务）队列或主题或执行WebService或REST请求。 这个消息的接收是你要在应用或架构的一层实现的，流程引擎则内嵌其中。

在你的应用接收一个消息之后，你必须决定如何处理它。 如果消息应该触发启动一个新流程实例， 在下面的RuntimeService的两个方法中选择一个执行：

ProcessInstance startProcessInstanceByMessage(String messageName);ProcessInstance startProcessInstanceByMessage(String messageName,Map<String,Object> processVariables);ProcessInstance startProcessInstanceByMessage(String messageName,String businessKey,Map<String,Object> processVariables);            

这些方法允许使用对应的消息系统流程实例。

如果消息需要被运行中的流程实例处理，首先要根据消息找到对应的流程实例 （参考下一节）然后触发这个等待中的流程。 RuntimeService提供了如下方法可以基于消息事件的订阅来触发流程继续执行：

void messageEventReceived(String messageName,String executionId);void messageEventReceived(String messageName,String executionId,HashMap<String,Object> processVariables);    

Activiti支持消息开始事件和中间消息事件。

下面是一个使用两个不同消息启动的流程实例：

可以用在，流程需要不同的方式来区分开始事件，而后最终会进入同样的路径。

• initiator：当流程启动时，把当前登录的用户保存到哪个变量名中。    示例如下：

  <startEventid="request"activiti:initiator="initiator"/>

  登录的用户必须使用IdentityService.setAuthenticatedUserId(String)方法设置，    并像这样包含在try-finally代码中：

  try{   identityService.setAuthenticatedUserId("bono");   runtimeService.startProcessInstanceByKey("someProcessKey");}finally{   identityService.setAuthenticatedUserId(null);}

  这段代码来自Activiti Explorer，所以它可以和    Chapter 9, 表单一起结合使用。

空开始事件技术上意味着没有指定启动流程实例的触发条件。   这就是说引擎不能预计什么时候流程实例会启动。   空开始事件用于，当流程实例要通过API启动的场景，   通过调用startProcessInstanceByXXX方法。

ProcessInstance processInstance = runtimeService.startProcessInstanceByXXX();

注意： 子流程都有一个空开始事件。

空开始事件显示成一个圆圈，没有内部图表（没有触发类型）

空开始事件的XML结构是普通的开始事件定义，没有任何子元素   （其他开始事件类型都有一个子元素来声明自己的类型）

<startEventid="start"name="my start event"/>

formKey：引用用户在启动新流程实例时需要填写的表单模板，    更多信息可以参考表单章节。 实例：

<startEventid="request"activiti:formKey="org/activiti/examples/taskforms/request.form"/>

定时开始事件用来在指定的时间创建流程实例。 它可以同时用于只启动一次的流程 和应该在特定时间间隔启动多次的流程。

注意：子流程不能使用定时开始事件。

注意：定时开始事件在流程发布后就会开始计算时间。   不需要调用startProcessInstanceByXXX，虽然也而已调用启动流程的方法，   但是那会导致调用startProcessInstanceByXXX时启动过多的流程。

注意：当包含定时开始事件的新版本流程部署时，    对应的上一个定时器就会被删除。这是因为通常不希望自动启动旧版本流程的流程实例。

定时开始事件显示为了一个圆圈，内部是一个表。

定时开始事件的XML内容是普通开始事件的声明，包含一个定时定义子元素。   请参考定时定义   查看配合细节。

示例：流程会启动4次，每次间隔5分钟，从2011年3月11日，12:13开始计时。

        <startEventid="theStart">             <timerEventDefinition>                 <timeCycle>R4/2011-03-11T12:13/PT5M</timeCycle>             </timerEventDefinition>         </startEvent>            

示例：流程会根据选中的时间启动一次。

        <startEventid="theStart">             <timerEventDefinition>                 <timeDate>2011-03-11T12:13:14</timeDate>             </timerEventDefinition>         </startEvent>            

消息开始事件可以用其使用一个命名的消息来启动流程实例。 这样可以帮助我们使用消息名称来选择正确的开始事件。

在发布包含一个或多个消息开始事件的流程定义时，需要考虑下面的条件：

启动流程实例，消息开始事件可以使用 下列RuntimeService中的方法来触发：

ProcessInstance startProcessInstanceByMessage(String messageName);ProcessInstance startProcessInstanceByMessage(String messageName,Map<String,Object> processVariables);ProcessInstance startProcessInstanceByMessage(String messageName,String businessKey,Map<String,Object< processVariables);                                 

这里的messageName是messageEventDefinition的messageRef属性引用的message元素的name属性。 启动流程实例时，要考虑一下因素：

消息开始事件是一个圆圈，中间是一个消息事件图标。图标是白色未填充的，来表示捕获（接收）行为。

消息开始事件的XML内容时在普通开始事件申请中包含一个    messageEventDefinition子元素：

<definitionsid="definitions"   xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"   xmlns:activiti="http://activiti.org/bpmn"   targetNamespace="Examples"   xmlns:tns="Examples">
  <messageid="newInvoice"name="newInvoiceMessage"/>
  <processid="invoiceProcess">
    <startEventid="messageStart">         <messageEventDefinitionmessageRef="tns:newInvoice"/>     </startEvent>     ...   </process>
</definitions>

signal开始事件，可以用来通过一个已命名的信号（signal）来启动一个流程实例。 信号可以在流程实例内部使用“中间信号抛出事务”触发， 也可以通过API(runtimService.signalEventReceivedXXX 方法)触发。两种情况下， 所有流程实例中拥有相同名称的signalStartEvent都会启动。

注意，在两种情况下，都可以选择同步或异步的方式启动流程实例。

必须向API传入signalName， 这是signal元素的name属性值， 它会被signalEventDefinition的signalRef属性引用。

信号开始事件显示为一个中间包含信号事件图标的圆圈。标记是无填充的，表示捕获（接收）行为。

signalStartEvent的XML格式是标准的startEvent声明，其中包含一个signalEventDefinition子元素：

    <signalid="theSignal"name="The Signal"/>
    <processid="processWithSignalStart1">         <startEventid="theStart">           <signalEventDefinitionid="theSignalEventDefinition"signalRef="theSignal"  />         </startEvent>         <sequenceFlowid="flow1"sourceRef="theStart"targetRef="theTask"/>         <userTaskid="theTask"name="Task in process A"/>         <sequenceFlowid="flow2"sourceRef="theTask"targetRef="theEnd"/>         <endEventid="theEnd"/>     </process>

错误开始事件可以用来触发一个事件子流程。              错误开始事件不能用来启动流程实例。

错误开始事件都是中断事件。

错误开始事件是一个圆圈，包含一个错误事件标记。标记是白色未填充的，来表示捕获（接收）行为。

错误开始事件的XML内容是普通开始事件定义中，包含一个    errorEventDefinition子元素。

<startEventid="messageStart">         <errorEventDefinitionerrorRef="someError"/></startEvent>

空结束事件意味着到达事件时不会指定抛出的结果。   这样，引擎会直接结束当前执行的分支，不会做其他事情。

空结束事件是一个粗边圆圈，内部没有小图表（无结果类型）

空结束事件的XML内容是普通结束事件定义，不包含子元素   （其他结束事件类型都会包含声明类型的子元素）。

<endEventid="end"name="my end event"/>

当流程执行到错误结束事件，   流程的当前分支就会结束，并抛出一个错误。   这个错误可以被对应的中间边界错误事件捕获。   如果找不到匹配的边界错误事件，就会抛出一个异常。

错误结束事件是一个标准的结束事件（粗边圆圈），内部有错误图标。   错误图表是全黑的，表示触发语法。

错误结束事件的内容是一个错误事件，   子元素为errorEventDefinition。

<endEventid="myErrorEndEvent">   <errorEventDefinitionerrorRef="myError"/></endEvent>           

errorRef属性引用定义在流程外部的error元素：

<errorid="myError"errorCode="123"/> ... <processid="myProcess"> ...           

error的errorCode用来查找   匹配的捕获边界错误事件。   如果errorRef与任何error都不匹配，   就会使用errorRef来作为errorCode的缩写。   这是activiti特定的缩写。   更具体的说，见如下代码：

<errorid="myError"errorCode="error123"/> ... <processid="myProcess"> ...   <endEventid="myErrorEndEvent">     <errorEventDefinitionerrorRef="myError"/>   </endEvent>           

等同于

<endEventid="myErrorEndEvent">   <errorEventDefinitionerrorRef="error123"/></endEvent>           

注意errorRef必须与BPMN 2.0格式相符， 必须是一个合法的QName。      

取消结束事件只能与BPMN事务子流程结合使用。 当到达取消结束事件时，会抛出取消事件，它必须被取消边界事件捕获。 取消边界事件会取消事务，并触发补偿机制。

取消结束事件显示为标准的结束事件（粗边圆圈），包含一个取消图标。   取消图标是全黑的，表示触发语法。

取消结束事件内容是一个结束事件，   包含cancelEventDefinition子元素。

<endEventid="myCancelEndEvent">   <cancelEventDefinition/></endEvent>           

• 唯一标识（流程范围）

• 使用caught属性   引用事件衣服的节点。   注意边界事件和它们附加的节点在同一级别上。   （比如，边界事件不是包含在节点内的）。

• 格式为XXXEventDefinition的XML子元素   （比如，TimerEventDefinition，ErrorEventDefinition，等等）   定义了边界事件的类型。参考对应的边界事件类型，   获得更多细节。

定时边界事件就是一个暂停等待警告的时钟。当流程执行到绑定了边界事件的环节，   会启动一个定时器。   当定时器触发时（比如，一定时间之后），环节就会中断，   并沿着定时边界事件的外出连线继续执行。

定时边界事件是一个标准的边界事件（边界上的一个圆圈），   内部是一个定时器小图标。

定时器边界任务定义是一个正规的边界事件。          指定类型的子元素是timerEventDefinition元素。

<boundaryEventid="escalationTimer"cancelActivity="true"attachedToRef="firstLineSupport">    <timerEventDefinition>     <timeDuration>PT4H</timeDuration>   </timerEventDefinition></boundaryEvent>

请参考定时事件定义获得更多定时其配置的细节。

在流程图中，可以看到上述例子中的圆圈边线是虚线：

经典场景是发送一个升级邮件，但是不打断正常流程的执行。

因为BPMN 2.0中，中断和非中断的事件还是有区别的。默认是中断事件。   非中断事件的情况，不会中断原始环节，那个环节还停留在原地。   对应的，会创建一个新分支，并沿着事件的流向继续执行。   在XML内容中，要把cancelActivity属性设置为false：

<boundaryEventid="escalationTimer"cancelActivity="false"attachedToRef="firstLineSupport"/>

注意：边界定时事件只能在job执行器启用时使用。   （比如，把activiti.cfg.xml中的jobExecutorActivate    设置为true，因为默认job执行器默认是禁用的）。

使用边界事件有一个已知的同步问题。 目前，不能边界事件后面不能有多条外出连线 （参考ACT-47）。 解决这个问题的方法是在一个连线后使用并发网关。

节点边界上的中间捕获错误事件，   或简写成边界错误事件，   它会捕获节点范围内抛出的错误。

定义一个边界错误事件，大多用于内嵌子流程，   或调用节点，对于子流程的情况，它会为所有内部的节点创建一个作用范围。   错误是由错误结束事件抛出的。   这个错误会传递给上层作用域，直到找到一个错误事件定义向匹配的边界错误事件。

当捕获了错误事件时，边界任务绑定的节点就会销毁，   也会销毁内部所有的执行分支   （比如，同步节点，内嵌子流程，等等）。   流程执行会继续沿着边界事件的外出连线继续执行。

边界错误事件显示成一个普通的中间事件（圆圈内部有一个小圆圈）   放在节点的标记上，内部有一个错误小图标。错误小图标是白色的，   表示它是一个捕获事件。

边界错误事件定义为普通的边界事件：

<boundaryEventid="catchError"attachedToRef="mySubProcess">   <errorEventDefinitionerrorRef="myError"/></boundaryEvent>           

和错误结束事件一样，    errorRef引用了process元素外部的一个错误定义：

<errorid="myError"errorCode="123"/> ... <processid="myProcess"> ...           

errorCode用来匹配捕获的错误：

下面的流程实例演示了如何使用错误结束事件。   当完成'审核盈利'这个用户任务是，如果没有提供足够的信息，   就会抛出错误，错误会被子流程的边界任务捕获，   所有'回顾销售'子流程中的所有节点都会销毁。   （即使'审核客户比率'还没有完成），   并创建一个'提供更多信息'的用户任务。

这个流程也放在demo中了。流程XML和单元测试可以在    org.activiti.examples.bpmn.event.error包下找到。

节点边界的中间捕获信号，   或简称为边界信号事件，   它会捕获信号定义引用的相同信号名的信号。

注意：与其他事件（比如边界错误事件）不同，边界信号事件不只捕获 它绑定方位的信号。信号事件是一个全局的范围（广播语义），就是说信号可以在任何地方触发， 即便是不同的流程实例。

注意：和其他事件（比如边界错误事件）不同，捕获信号后，不会停止信号的传播。 如果你有两个信号边界事件，它们捕获相同的信号事件，两个边界事件都会被触发， 即使它们在不同的流程实例中。

边界信号事件显示为普通的中间事件（圆圈里有个小圆圈），位置在节点的边缘，   内部有一个信号小图标。信号图标是白色的（未填充），   来表示捕获的意思。

边界信号事件定义为普通的边界事件：

<boundaryEventid="boundary"attachedToRef="task"cancelActivity="true">           <signalEventDefinitionsignalRef="alertSignal"/></boundaryEvent>                         

参考信号事件定义章节。

节点边界上的中间捕获消息，   或简称边界消息事件，根据引用的消息定义捕获相同消息名称的消息。

边界消息事件显示成一个普通的中间事件（圆圈里有个小圆圈），位于节点边缘，   内部是一个消息小图标。消息图标是白色（无填充），   表示捕获语义。

注意，边界消息事件可能是中断（右侧）或非中断（左侧）的。

边界消息事件定义为标准的边界事件：

<boundaryEventid="boundary"attachedToRef="task"cancelActivity="true">           <messageEventDefinitionmessageRef="newCustomerMessage"/></boundaryEvent>                         

参考消息事件定义章节。

在事务性子流程的边界上的中间捕获取消，   或简称为边界取消事件 cancel event，   当事务取消时触发。当取消边界事件触发时，首先中断当前作用域的所有执行。   然后开始补偿事务内的所有激活的补偿边界事件。   补偿是同步执行的。例如，离开事务钱，边界事务会等待补偿执行完毕。   当补偿完成后，事务子流程会沿着取消边界事务的外出连线继续执行。

注意：每个事务子流程只能有一个取消边界事件。

注意：如果事务子流程包含内嵌子流程，补偿只会触发已经成功完成的子流程。

注意：如果取消边界子流程对应的事务子流程配置为多实例， 如果一个实例触发了取消，就会取消所有实例。     instances.

取消边界事件显示为了一个普通的中间事件（圆圈里套小圆圈），在节点的边缘，   内部是一个取消小图标。取消图标是白色（无填充），   表明是捕获语义。

取消边界事件定义为普通边界事件：

<boundaryEventid="boundary"attachedToRef="transaction">           <cancelEventDefinition/></boundaryEvent>                         

因为取消边界事件都是中断的，所以不需要使用cancelActivity属性。

节点边界的中间捕获补偿，   或简称为补偿边界事件，   可以用来设置一个节点的补偿处理器。

补偿边界事件必须使用直接引用设置唯一的补偿处理器。

补偿边界事件与其他边界事件的策略不同。 其他边界事件（比如信号边界事件）当到达关联的节点就会被激活。 离开节点时，就会挂起，对应的事件订阅也会取消。 补偿边界事件则不同。补偿边界事件在关联的节点成功完成时激活。 当补偿事件触发或对应流程实例结束时，事件订阅才会删除。 它遵循如下规则：

注意：补偿边界事件不支持内嵌子流程。

补偿边界事件显示为标准中间事件（圆圈里套圆圈），位于节点边缘，   内部有一个补偿小图标。补偿图标是白色的（无填充），   表示捕获语义。另外，下面的图形演示了使用无方向的关联，   为边界事件设置补偿处理器。

补偿边界事件定义为标准边界事件：

<boundaryEventid="compensateBookHotelEvt"attachedToRef="bookHotel">           <compensateEventDefinition/></boundaryEvent>
<associationassociationDirection="One"id="a1"  sourceRef="compensateBookHotelEvt"targetRef="undoBookHotel"/>
<serviceTaskid="undoBookHotel"isForCompensation="true"activiti:class="..."/>

因为补偿边界事件在节点成功完成后激活， 所以不支持cancelActivity属性。

• 唯一标识（流程范围内）

• 一个结构为XXXEventDefinition的XML子元素   （比如TimerEventDefinition等）   定义了中间捕获事件的类型。参考特定的捕获事件类型，   获得更多详情。

定时中间事件作为一个监听器。当执行到达捕获事件节点，   就会启动一个定时器。   当定时器触发（比如，一段时间之后），流程就会沿着定时中间事件的外出节点继续执行。

定时器中间事件显示成标准中间捕获事件，内部是一个定时器小图标。

定时器中间事件定义为标准中间捕获事件。   指定类型的子元素为timerEventDefinition元素。

        <intermediateCatchEventid="timer">             <timerEventDefinition>                 <timeDuration>PT5M</timeDuration>             </timerEventDefinition>         </intermediateCatchEvent>                  

参考定时器事件定义了解配置信息。

中间捕获信号事件   通过引用信号定义来捕获相同信号名称的信号。

注意：与其他事件（比如错误事件）不同，信号不会在捕获之后被消费。 如果你有两个激活的信号边界事件捕获相同的信号事件，两个边界事件都会被触发， 即便它们在不同的流程实例中。

中间信号捕获事件显示为一个普通的中间事件（圆圈套圆圈），   内部有一个信号小图标。信号小图标是白色的（无填充），   表示捕获语义。

信号中间事件定义为普通的中间捕获事件。 对应类型的子元素是signalEventDefinition元素。

<intermediateCatchEventid="signal">         <signalEventDefinitionsignalRef="newCustomerSignal"/></intermediateCatchEvent>                  

参考信号事件定义章节。

一个中间捕获消息事件，捕获特定名称的消息。

中间捕获消息事件显示为普通中间事件（圆圈套圆圈），   内部是一个消息小图标。消息图标是白色的（无填充），   表示捕获语义。

消息中间事件定义为标准中间捕获事件。 指定类型的子元素是messageEventDefinition元素。

<intermediateCatchEventid="message">         <messageEventDefinitionsignalRef="newCustomerMessage"/></intermediateCatchEvent>                  

参考消息事件定义章节。

• 唯一标识（流程范围）

• 使用格式为XXXEventDefinition的XML子元素   （比如signalEventDefinition等）   定义中间触发事件的类型。   参考对应触发事件的类型，了解更多信息。

中间触发信号事件为定义的信号抛出一个信号事件。

在activiti中，信号会广播到所有激活的处理器中（比如，所以捕获信号事件）。 信号可以通过同步和异步方式发布。

中间信号触发事件显示为普通中间事件（圆圈套圆圈），   内部又一个信号小图标。信号图标是黑色的（有填充），   表示触发语义。

消息中间事件定义为标准中间触发事件。 指定类型的子元素是signalEventDefinition元素。

<intermediateThrowEventid="signal">         <signalEventDefinitionsignalRef="newCustomerSignal"/></intermediateThrowEvent>                  

异步信号事件如下所示：

<intermediateThrowEventid="signal">         <signalEventDefinitionsignalRef="newCustomerSignal"activiti:async="true"/></intermediateThrowEvent>                  

参考信号事件定义章节。

中间触发补偿事件   可以用来触发补偿。

触发补偿： 补偿可以由特定节点或包含补偿事件的作用域触发。 补偿是通过分配给节点的补偿处理器来完成的。

注意： 如果补偿被一个包含子流程的作用域触发，子流程还包含了关联补偿处理器的节点， 补偿只会传播到子流程，如果它已经成功完成了。 如果子流程中的节点也完成了，并关联了补偿处理器， 如果子流程包含的这些节点还没有完成，就不会执行补偿处理器。 参考下面实例：

这个流程中，我们有两个并发分支，一些分支时内嵌子流程，一个是“使用信用卡”节点。 假设两个分支都启动了，第一个分支等待用户完成“审核预定”任务。第二个分支执行“使用信用卡”节点， 并发生了一个错误，这导致“取消预定”事件，并触发补偿。 这时，并发子流程还没有结束，意味着补偿事件不会传播给子流程， 所以“取消旅店预定”这个补偿处理器不会执行。 如果用户任务（就是内嵌子流程）在“取消预定”之前完成了， 补偿就会传播给内嵌子流程。

流程变量： 当补偿内嵌子流程时，用来执行补偿处理器的分支可以访问子流程的本地流程实例， 因为这时它是子流程完成的分支。 为了实现这个功能，流程变量的快照会分配给分支（为执行子流程而创建的分支）。 为此，有以下限制条件：

已知限制：

中间补偿触发事件显示为标准中间事件（圆圈套圆圈），   内部是一个补偿小图标。补偿图标是黑色的（有填充），   表示触发语义。

补偿中间事件定义为普通的中间触发事件。 对应类型的子元素是compensateEventDefinition元素。

<intermediateThrowEventid="throwCompensation">         <compensateEventDefinition/></intermediateThrowEvent>

另外，可选参数activityRef可以用来触发特定作用域/节点的补偿：

<intermediateThrowEventid="throwCompensation">         <compensateEventDefinitionactivityRef="bookHotel"/></intermediateThrowEvent>

可以为顺序流定义一个条件。离开一个BPMN 2.0节点时，   默认会计算外出顺序流的条件。   如果条件结果为true,    就会选择外出顺序流继续执行。当多条顺序流被选中时，   就会创建多条分支，   流程会继续以并行方式继续执行。

注意：上面的讨论仅涉及BPMN 2.0节点（和事件），   不包括网关。网关会用特定的方式处理顺序流中的条件，   这与网关类型相关。

条件顺序流显示为一个正常的顺序流，不过在起点有一个菱形。   条件表达式也会显示在顺序流上。

条件顺序流定义为一个正常的顺序流，   包含conditionExpression子元素。   注意目前只支持tFormalExpressions，   如果没有设置xsi:type="",    就会默认值支持目前支持的表达式类型。

<sequenceFlowid="flow"sourceRef="theStart"targetRef="theTask">   <conditionExpressionxsi:type="tFormalExpression">     <![CDATA[${order.price > 100 && order.price < 250}]]>   </conditionExpression></sequenceFlow>

当前条件表达式只能使用UEL，   可以参考表达式章节获取更多信息。   使用的表达式需要返回boolean值，否则会在解析表达式时抛出异常。

在activiti发布包中，包含以下流程实例，使用了值和方法表达式   （参考org.activiti.examples.bpmn.expression)包）：

所有的BPMN 2.0任务和网关都可以设置一个默认顺序流。   只有在节点的其他外出顺序流不能被选中是，才会使用它作为外出顺序流继续执行。   默认顺序流的条件设置不会生效。

默认顺序流显示为了普通顺序流，起点有一个“斜线”标记。

默认顺序流通过对应节点的default属性定义。   下面的XML代码演示了排他网关设置了默认顺序流flow 2。   只有当conditionA和conditionB都返回false时，   才会选择它作为外出连线继续执行。

<exclusiveGatewayid="exclusiveGw"name="Exclusive Gateway"default="flow2"/><sequenceFlowid="flow1"sourceRef="exclusiveGw"targetRef="task1">   <conditionExpressionxsi:type="tFormalExpression">${conditionA}</conditionExpression></sequenceFlow><sequenceFlowid="flow2"sourceRef="exclusiveGw"targetRef="task2"/><sequenceFlowid="flow3"sourceRef="exclusiveGw"targetRef="task3">   <conditionExpressionxsi:type="tFormalExpression">${conditionB}</conditionExpression></sequenceFlow>           

对应下面的图形显示：

排他网关（也叫异或（XOR）网关，或更技术性的叫法    基于数据的排他网关），   用来在流程中实现决策。   当流程执行到这个网关，所有外出顺序流都会被处理一遍。   其中条件解析为true的顺序流（或者没有设置条件，概念上在顺序流上定义了一个'true'）   会被选中，让流程继续运行。

注意这里的外出顺序流   与BPMN 2.0通常的概念是不同的。通常情况下，所有条件结果为true的顺序流   都会被选中，以并行方式执行，但排他网关只会选择一条顺序流执行。   就是说，虽然多个顺序流的条件结果为true，   那么XML中的第一个顺序流（也只有这一条）会被选中，并用来继续运行流程。   如果没有选中任何顺序流，会抛出一个异常。

排他网关显示成一个普通网关（比如，菱形图形），   内部是一个“X”图标，表示异或（XOR）语义。   注意，没有内部图标的网关，默认为排他网关。    BPMN 2.0规范不允许在同一个流程定义中同时使用没有X和有X的菱形图形。

排他网关的XML内容是很直接的：用一行定义了网关，   条件表达式定义在外出顺序流中。   参考条件顺序流   获得这些表达式的可用配置。

参考下面模型实例：

它对应的XML内容如下：

<exclusiveGatewayid="exclusiveGw"name="Exclusive Gateway"/>
<sequenceFlowid="flow2"sourceRef="exclusiveGw"targetRef="theTask1">   <conditionExpressionxsi:type="tFormalExpression">${input == 1}</conditionExpression></sequenceFlow>
<sequenceFlowid="flow3"sourceRef="exclusiveGw"targetRef="theTask2">   <conditionExpressionxsi:type="tFormalExpression">${input == 2}</conditionExpression></sequenceFlow>
<sequenceFlowid="flow4"sourceRef="exclusiveGw"targetRef="theTask3">   <conditionExpressionxsi:type="tFormalExpression">${input == 3}</conditionExpression></sequenceFlow>

网关也可以表示流程中的并行情况。最简单的并行网关是    并行网关，它允许将流程    分成多条分支，也可以把多条分支    汇聚到一起。           of execution.

并行网关的功能是基于进入和外出的顺序流的：

注意，如果同一个并行网关有多个进入和多个外出顺序流，   它就同时具有分支和汇聚功能。   这时，网关会先汇聚所有进入的顺序流，然后再切分成多个并行分支。

与其他网关的主要区别是，并行网关不会解析条件。   即使顺序流中定义了条件，也会被忽略。

并行网关显示成一个普通网关（菱形）内部是一个“加号”图标，   表示“与（AND）”语义。

定义并行网关只需要一行XML：

<parallelGatewayid="myParallelGateway"/>

实际发生的行为（分支，聚合，同时分支聚合），   要根据并行网关的顺序流来决定。

参考如下代码：

    <startEventid="theStart"/>     <sequenceFlowid="flow1"sourceRef="theStart"targetRef="fork"/>
    <parallelGatewayid="fork"/>     <sequenceFlowsourceRef="fork"targetRef="receivePayment"/>     <sequenceFlowsourceRef="fork"targetRef="shipOrder"/>
    <userTaskid="receivePayment"name="Receive Payment"/>     <sequenceFlowsourceRef="receivePayment"targetRef="join"/>
    <userTaskid="shipOrder"name="Ship Order"/>     <sequenceFlowsourceRef="shipOrder"targetRef="join"/>
    <parallelGatewayid="join"/>     <sequenceFlowsourceRef="join"targetRef="archiveOrder"/>
    <userTaskid="archiveOrder"name="Archive Order"/>     <sequenceFlowsourceRef="archiveOrder"targetRef="theEnd"/>
    <endEventid="theEnd"/>

上面例子中，流程启动之后，会创建两个任务：

ProcessInstance pi = runtimeService.startProcessInstanceByKey("forkJoin");TaskQuery query = taskService.createTaskQuery()                          .processInstanceId(pi.getId())                          .orderByTaskName()                          .asc();
List<Task> tasks = query.list(); assertEquals(2, tasks.size());
Task task1 = tasks.get(0); assertEquals("Receive Payment", task1.getName());Task task2 = tasks.get(1); assertEquals("Ship Order", task2.getName());

当两个任务都完成时，第二个并行网关会汇聚两个分支，因为它只有一条外出连线，   不会创建并行分支，   只会创建归档订单任务。

注意并行网关不需要是“平衡的”（比如，   对应并行网关的进入和外出节点数目相等）。   并行网关只是等待所有进入顺序流，并为每个外出顺序流创建并发分支，   不会受到其他流程节点的影响。   所以下面的流程在BPMN 2.0中是合法的：

包含网关可以看做是排他网关和并行网关的结合体。   和排他网关一样，你可以在外出顺序流上定义条件，包含网关会解析它们。   但是主要的区别是包含网关可以选择多于一条顺序流，这和并行网关一样。

包含网关的功能是基于进入和外出顺序流的：

注意，如果同一个包含节点拥有多个进入和外出顺序流，   它就会同时含有分支和汇聚功能。   这时，网关会先汇聚所有拥有流程token的进入顺序流，   再根据条件判断结果为true的外出顺序流，为它们生成多条并行分支。

并行网关显示为一个普通网关（菱形），内部包含一个圆圈图标。

定义一个包含网关需要一行XML：

<inclusiveGatewayid="myInclusiveGateway"/>

实际的行为（分支，汇聚或同时分支汇聚），   是由连接在包含网关的顺序流决定的。

参考如下代码：

    <startEventid="theStart"/>     <sequenceFlowid="flow1"sourceRef="theStart"targetRef="fork"/>
    <inclusiveGatewayid="fork"/>     <sequenceFlowsourceRef="fork"targetRef="receivePayment">     <conditionExpressionxsi:type="tFormalExpression">${paymentReceived == false}</conditionExpression>     </sequenceFlow>     <sequenceFlowsourceRef="fork"targetRef="shipOrder">     <conditionExpressionxsi:type="tFormalExpression">${shipOrder == true}</conditionExpression>     </sequenceFlow>
    <userTaskid="receivePayment"name="Receive Payment"/>     <sequenceFlowsourceRef="receivePayment"targetRef="join"/>
    <userTaskid="shipOrder"name="Ship Order"/>     <sequenceFlowsourceRef="shipOrder"targetRef="join"/>
    <inclusiveGatewayid="join"/>     <sequenceFlowsourceRef="join"targetRef="archiveOrder"/>
    <userTaskid="archiveOrder"name="Archive Order"/>     <sequenceFlowsourceRef="archiveOrder"targetRef="theEnd"/>
    <endEventid="theEnd"/>

在上面的例子中，流程开始之后，如果流程变量为paymentReceived == false和shipOrder == true，   就会创建两个任务。如果，只有一个流程变量为true，就会只创建一个任务。   如果没有条件为true，就会抛出一个异常。   如果想避免异常，可以定义一个默认顺序流。下面的例子中，会创建一个任务，发货任务：

HashMap<String,Object> variableMap =newHashMap<String,Object>();           variableMap.put("receivedPayment",true);           variableMap.put("shipOrder",true);           ProcessInstance pi = runtimeService.startProcessInstanceByKey("forkJoin");TaskQuery query = taskService.createTaskQuery()                          .processInstanceId(pi.getId())                          .orderByTaskName()                          .asc();
List<Task> tasks = query.list(); assertEquals(1, tasks.size());
Task task = tasks.get(0); assertEquals("Ship Order", task.getName());

当任务完成后，第二个包含网关会汇聚两个分支，   因为只有一个外出顺序流，所以不会创建并行分支，   只有归档订单任务会被激活。

注意，包含网关不需要“平衡”（比如，   对应包含网关的进入和外出数目需要相等）。   包含网关会等待所有进入顺序流完成，   并为每个外出顺序流创建并行分支，   不会受到流程中其他元素的影响。

基于事件网关允许根据事件判断流向。网关的每个外出顺序流都要连接到一个中间捕获事件。 当流程到达一个基于事件网关，网关会进入等待状态：会暂停执行。 与此同时，会为每个外出顺序流创建相对的事件订阅。

注意基于事件网关的外出顺序流和普通顺序流不同。这些顺序流不会真的"执行"。 相反，它们让流程引擎去决定执行到基于事件网关的流程需要订阅哪些事件。 要考虑以下条件：

基于事件网关和其他BPMN网关一样显示成一个菱形，   内部包含指定图标。

用来定义基于事件网关的XML元素是eventBasedGateway。

下面的流程是一个使用基于事件网关的例子。当流程执行到基于事件网关时， 流程会暂停执行。与此同时，流程实例会订阅警告信号事件，并创建一个10分钟后触发的定时器。 这会产生流程引擎为一个信号事件等待10分钟的效果。如果10分钟内发出信号，定时器就会取消，流程会沿着信号执行。 如果信号没有出现，流程会沿着定时器的方向前进，信号订阅会被取消。

<definitionsid="definitions"         xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"         xmlns:activiti="http://activiti.org/bpmn"         targetNamespace="Examples">
        <signalid="alertSignal"name="alert"/>
        <processid="catchSignal">
                <startEventid="start"/>
                <sequenceFlowsourceRef="start"targetRef="gw1"/>
                <eventBasedGatewayid="gw1"/>
                <sequenceFlowsourceRef="gw1"targetRef="signalEvent"/>                 <sequenceFlowsourceRef="gw1"targetRef="timerEvent"/>
                <intermediateCatchEventid="signalEvent"name="Alert">                         <signalEventDefinitionsignalRef="alertSignal"/>                 </intermediateCatchEvent>
                <intermediateCatchEventid="timerEvent"name="Alert">                         <timerEventDefinition>                                 <timeDuration>PT10M</timeDuration>                         </timerEventDefinition>                 </intermediateCatchEvent>
                <sequenceFlowsourceRef="timerEvent"targetRef="exGw1"/>                 <sequenceFlowsourceRef="signalEvent"targetRef="task"/>
                <userTaskid="task"name="Handle alert"/>
                <exclusiveGatewayid="exGw1"/>
                <sequenceFlowsourceRef="task"targetRef="exGw1"/>                 <sequenceFlowsourceRef="exGw1"targetRef="end"/>
                <endEventid="end"/></process></definitions>

用户任务用来设置必须由人员完成的工作。    当流程执行到用户任务，会创建一个新任务，    并把这个新任务加入到分配人或群组的任务列表中。

用户任务显示成一个普通任务（圆角矩形），左上角有一个小用户图标。

XML中的用户任务定义如下。id属性是必须的。    name属性是可选的。

<userTaskid="theTask"name="Important task"/>                                   

用户任务也可以设置描述。实际上所有BPMN 2.0元素都可以设置描述。 添加documentation元素可以定义描述。

<userTaskid="theTask"name="Schedule meeting">   <documentation>           Schedule an engineering meeting for next week with the new hire.   </documentation>

描述文本可以通过标准的java方法来获得：

task.getDescription()

任务可以用一个字段来描述任务的持续时间。可以使用查询API来对持续时间进行搜索， 根据在时间之前或之后进行搜索。

我们提供了一个节点扩展，在任务定义中设置一个表达式， 这样在任务创建时就可以为它设置初始持续时间。表达式应该是java.util.Date， java.util.String (ISO8601格式)，ISO8601 持续时间 (比如PT50M)或null。 例如：你可以在流程中使用上述格式输入日期，或在前一个服务任务中计算一个时间。 这里使用了持续时间，持续时间会基于当前时间进行计算，再通过给定的时间段累加。 比如，使用"PT30M"作为持续时间，任务就会从现在开始持续30分钟。

<userTaskid="theTask"name="Important task"activiti:dueDate="${dateVariable}"/>

用户任务可以直接分配给一个用户。   这可以通过humanPerformer元素定义。    humanPerformer定义需要一个    resourceAssignmentExpression来实际定义用户。   当前，只支持formalExpressions。

<process ... >
  ...
  <userTaskid='theTask'name='important task'>     <humanPerformer>       <resourceAssignmentExpression>         <formalExpression>kermit</formalExpression>       </resourceAssignmentExpression>     </humanPerformer>   </userTask>

只有一个用户可以坐拥任务的执行者分配给用户。   在activiti中，用户叫做执行者。   拥有执行者的用户不会出现在其他人的任务列表中，   只能出现执行者的个人任务列表中。

直接分配给用户的任务可以通过TaskService像下面这样获取：

List<Task> tasks = taskService.createTaskQuery().taskAssignee("kermit").list();

任务也可以加入到人员的候选任务列表中。   这时，需要使用potentialOwner元素。   用法和humanPerformer元素类似。注意它需要指定表达式中的每个项目是人员还是群组   （引擎猜不出来）。

<process ... >
  ...
  <userTaskid='theTask'name='important task'>     <potentialOwner>       <resourceAssignmentExpression>         <formalExpression>user(kermit), group(management)</formalExpression>       </resourceAssignmentExpression>     </potentialOwner>   </userTask>

使用potentialOwner元素定义的任务，可以像下面这样获取   （使用TaskQuery的发那个发与查询设置了执行者的任务类似）：

 List<Task> tasks = taskService.createTaskQuery().taskCandidateUser("kermit");

这会获取所有kermit为候选人的任务，   例如：表达式中包含user(kermit)。   这也会获得所有分配包含kermit这个成员的群组   （比如，group(management)，前提是kermit是这个组的成员，   并且使用了activiti的账号组件）。   用户所在的群组是在运行阶段获取的，它们可以通过    IdentityService进行管理。

如果没有显示指定设置的是用户还是群组，   引擎会默认当做群组处理。所以下面的设置与使用group(accountancy)效果一样。

<formalExpression>accountancy</formalExpression>

当分配不复杂时，用户和组的设置非常麻烦。 为避免复杂性，可以使用用户任务的自定义扩展。

注意：虽然activiti提供了一个账号管理组件， 也提供了IdentityService， 但是账号组件不会检测设置的用户是否村爱。 它嵌入到应用中，也允许activiti与其他已存的账户管理方案集成。

如果上面的方式还不满足需求，还可以使用创建事件的任务监听器 来实现自定义的分配逻辑：

<userTaskid="task1"name="My task">   <extensionElements>     <activiti:taskListenerevent="create"class="org.activiti.MyAssignmentHandler"/>   </extensionElements></userTask>

DelegateTask会传递给TaskListener的实现， 通过它可以设置执行人，候选人和候选组：

publicclassMyAssignmentHandlerimplementsTaskListener{
  publicvoid notify(DelegateTask delegateTask){     // Execute custom identity lookups here
    // and then for example call following methods:     delegateTask.setAssignee("kermit");     delegateTask.addCandidateUser("fozzie");     delegateTask.addCandidateGroup("management");     ...   }
}

使用spring时，可以使用向上面章节中介绍的自定义分配属性， 使用表达式 把任务监听器设置为spring代理的bean， 让这个监听器监听任务的创建事件。 下面的例子中，执行者会通过调用ldapService这个spring bean的findManagerOfEmployee方法获得。 流程变量emp会作为参数传递给bean。

<userTaskid="task"name="My Task"activiti:assignee="${ldapService.findManagerForEmployee(emp)}"/>

也可以用来设置候选人和候选组：

<userTaskid="task"name="My Task"activiti:candidateUsers="${ldapService.findAllSales()}"/>

注意方法返回类型只能为String或Collection<String> （对应候选人和候选组）：

publicclassFakeLdapService{
  publicString findManagerForEmployee(String employee){     return"Kermit The Frog";   }
  publicList<String> findAllSales(){     returnArrays.asList("kermit","gonzo","fozzie");   }
}

脚本任务时一个自动节点。当流程到达脚本任务，   会执行对应的脚本。

脚本任务显示为标准BPMN 2.0任务（圆角矩形），   左上角有一个脚本小图标。

脚本任务定义需要指定script        和scriptFormat。

<scriptTaskid="theScriptTask"name="Execute script"scriptFormat="groovy">   <script>     sum =0     for( i in inputArray ){       sum += i     }   </script></scriptTask>

scriptFormat的值必须兼容    JSR-223。   （java平台的脚本语言）。默认Javascript会包含在JDK中，不需要额外的依赖。   如果你想使用其他（JSR-223兼容）的脚本引擎，   需要把对应的jar添加到classpath下，并使用合适的名称。   比如，activiti单元测试经常使用groovy，   因为语法比java简单太多。

注意，groovy脚本引擎放在groovy-all.jar中。在2.0版本之前，   脚本引擎是groovy jar的一部分。这样，需要添加如下依赖：

<dependency>       <groupId>org.codehaus.groovy</groupId>       <artifactId>groovy-all</artifactId>       <version>2.x.x<version></dependency>

到达脚本任务的流程可以访问的所有流程变量，都可以在脚本中使用。   实例中，脚本变量'inputArray'其实是流程变量   （整数数组）。

<script>     sum =0     for( i in inputArray){       sum += i     }</script>

也可以在脚本中设置流程变量，直接调用        execution.setVariable("variableName", variableValue)。   默认，不会自动保存变量（注意：activiti 5.12之前存在这个问题）。   可以在脚本中自动保存任何变量。   （比如上例中的sum），只要把scriptTask    的autoStoreVariables属性设置为true。   然而，最佳实践是不要用它，而是显示调用execution.setVariable()，   因为一些当前版本的JDK对于一些脚本语言，无法实现自动保存变量。       参考这里获得更多信息。

<scriptTaskid="script"scriptFormat="JavaScript"activiti:autoStoreVariables="false">

参数默认为false，意思是如果没有为脚本任务定义设置参数，   所有声明的变量将只存在于脚本执行的阶段。

如何在脚本中设置变量的例子：

<script>     def scriptVar ="test123"     execution.setVariable("myVar", scriptVar)</script>

注意：下面这些命名已被占用，不能用作变量名：    out, out:print, lang:import, context, elcontext。

脚本任务的返回值可以通过制定流程变量的名称，分配给已存或一个新流程变量，   使用脚本任务定义的'activiti:resultVariable'属性。   任何已存的流程变量都会被脚本执行的结果覆盖。   如果没有指定返回变量名，脚本的返回值会被忽略。

<scriptTaskid="theScriptTask"name="Execute script"scriptFormat="juel"activiti:resultVariable="myVar">   <script>#{echo}</script></scriptTask>

上例中，脚本的结果（表达式'#{echo}'的值）   在脚本完成后，会设置到'myVar'变量中。

java服务任务用来调用外部java类。

服务任务显示为圆角矩形，左上角有一个齿轮小图标。

有4钟方法来声明java调用逻辑：

执行一个在流程执行中调用的类， 需要在'activiti:class'属性中设置全类名。

<serviceTaskid="javaService"              name="My Java Service Task"              activiti:class="org.activiti.MyJavaDelegate"/>

参考实现章节 了解更多使用类的信息。

也可以使用表达式调用一个对象。对象必须遵循一些规则， 并使用activiti:class属性进行创建。 （了解更多）。

 <serviceTaskid="serviceTask"activiti:delegateExpression="${delegateExpressionBean}"/>

这里，delegateExpressionBean是一个实现了JavaDelegate接口的bean， 它定义在实例的spring容器中。

要指定执行的UEL方法表达式， 需要使用activiti:expression。

<serviceTaskid="javaService"              name="My Java Service Task"              activiti:expression="#{printer.printMessage()}"/>

方法printMessage（无参数）会调用 名为printer对象的方法。

也可以为表达式中的方法传递参数。

<serviceTaskid="javaService"              name="My Java Service Task"              activiti:expression="#{printer.printMessage(execution, myVar)}"/>

这会调用名为printer对象上的方法printMessage。 第一个参数是DelegateExecution，在表达式环境中默认名称为execution。 第二个参数传递的是当前流程的名为myVar的变量。

要指定执行的UEL值表达式， 需要使用activiti:expression属性。

<serviceTaskid="javaService"              name="My Java Service Task"              activiti:expression="#{split.ready}"/>

ready属性的getter方法，getReady（无参数）， 会作用于名为split的bean上。 这个对象会被解析为流程对象和 （如果合适）spring环境中的对象。

要在流程执行中实现一个调用的类，这个类需要实现org.activiti.engine.delegate.JavaDelegate接口， 并在execute方法中提供对应的业务逻辑。 当流程执行到特定阶段，它会指定方法中定义好的业务逻辑， 并按照默认BPMN 2.0中的方式离开节点。

让我们创建一个java类的例子，它可以流程变量中字符串转换为大写。 这个类需要实现org.activiti.engine.delegate.JavaDelegate接口， 这要求我们实现execute(DelegateExecution)方法。 它包含的业务逻辑会被引擎调用。流程实例信息，如流程变量和其他信息， 可以通过 DelegateExecution 接口访问和操作（点击对应操作的javadoc的链接，获得更多信息）。

publicclassToUppercaseimplementsJavaDelegate{
  publicvoid execute(DelegateExecution execution)throwsException{     Stringvar=(String) execution.getVariable("input");     var=var.toUpperCase();     execution.setVariable("input",var);   }
}

注意：serviceTask定义的class只会创建一个java类的实例。 所有流程实例都会共享相同的类实例，并调用execute(DelegateExecution)。 这意味着，类不能使用任何成员变量，必须是线程安全的，它必须能模拟在不同线程中执行。 这也影响着属性注入的处理方式。

流程定义中引用的类（比如，使用activiti:class）不会        在部署时实例化。只有当流程第一次执行到使用类的时候， 类的实例才会被创建。如果找不到类，会抛出一个ActivitiException。 这个原因是部署环境（更确切是的classpath）和真实环境往往是不同的。 比如当使用ant或业务归档上传到Activiti Explorer来发布流程 classpath没有包含引用的类。

[内部：非公共实现类]      也可以提供实现         org.activiti.engine.impl.pvm.delegate.ActivityBehavior接口的类。 实现可以访问更强大的ActivityExecution, 它可以影响流程的流向。注意，这不是一个很好的实践， 应该尽量避免。所以，建议只有在高级情况下并且你确切知道你要做什么的情况下， 再使用ActivityBehavior接口。

可以为代理类的属性注入数据。支持如下类型的注入：

如果有效的话，数值会通过代理类的setter方法注入，遵循java bean的命名规范（比如fistName属性对应setFirstName(...)方法）。   如果属性没有对应的setter方法，数值会直接注入到私有属性中。   一些环境的SecurityManager不允许修改私有属性，所以最好还是把你想注入的属性暴露出对应的setter方法来。    无论流程定义中的数据是什么类型，注入目标的属性类型都应该是    org.activiti.engine.delegate.Expression。

下面代码演示了如何把一个常量注入到属性中。   属性注入可以使用'class'属性。   注意我们需要定义一个'extensionElements' XML元素，   在声明实际的属性注入之前，这是BPMN 2.0 XML格式要求的。

<serviceTaskid="javaService"     name="Java service invocation"     activiti:class="org.activiti.examples.bpmn.servicetask.ToUpperCaseFieldInjected">     <extensionElements>       <activiti:fieldname="text"stringValue="Hello World"/>   </extensionElements></serviceTask>           

ToUpperCaseFieldInjected类有一个text属性，   类型是org.activiti.engine.delegate.Expression。   调用text.getValue(execution)时，会返回定义的字符串Hello World。

也可以使用长文字（比如，内嵌的email），可以使用'activiti:string'子元素：

<serviceTaskid="javaService"     name="Java service invocation"     activiti:class="org.activiti.examples.bpmn.servicetask.ToUpperCaseFieldInjected">   <extensionElements>     <activiti:fieldname="text">         <activiti:string>           Hello World       </activiti:string>     </activiti:field>   </extensionElements></serviceTask>           

可以使用表达式，实现在运行期动态解析注入的值。这些表达式可以使用流程变量或spring定义的bean（如果使用了spring）。 像服务任务实现里说的那样，服务任务中的java类实例会在所有流程实例*享。 为了动态注入属性的值，我们可以在org.activiti.engine.delegate.Expression中使用值和方法表达式， 它会使用传递给execute方法的DelegateExecution参数进行解析。

<serviceTaskid="javaService"name="Java service invocation"   activiti:class="org.activiti.examples.bpmn.servicetask.ReverseStringsFieldInjected">
  <extensionElements>     <activiti:fieldname="text1">       <activiti:expression>${genderBean.getGenderString(gender)}</activiti:expression>     </activiti:field>     <activiti:fieldname="text2">        <activiti:expression>Hello ${gender == 'male' ? 'Mr.' : 'Mrs.'} ${name}</activiti:expression>     </activiti:field>   </ extensionElements> </ serviceTask>

下面的例子中，注入了表达式，并使用在传入的当前DelegateExecution解析它们。  完整代码可以参考org.activiti.examples.bpmn.servicetask.JavaServiceTaskTest.testExpressionFieldInjection。

publicclassReverseStringsFieldInjectedimplementsJavaDelegate{
  privateExpression text1;   privateExpression text2;
  publicvoid execute(DelegateExecution execution){     String value1 =(String) text1.getValue(execution);     execution.setVariable("var1",newStringBuffer(value1).reverse().toString());
    String value2 =(String) text2.getValue(execution);     execution.setVariable("var2",newStringBuffer(value2).reverse().toString());   }}

另外，你也可以把表达式设置成一个属性，而不是字元素，让XML更简单一些。

<activiti:fieldname="text1"expression="${genderBean.getGenderString(gender)}"/><activiti:fieldname="text1"expression="Hello ${gender == 'male' ? 'Mr.' : 'Mrs.'} ${name}"/>

因为java类实例会被重用，注入只会发生一次，当服务任务调用第一次的时候。 当你的代码中的属性改变了，值也不会重新注入， 所以你应该把它们看做是不变的，不用修改它们。          

服务流程返回的结果（使用表达式的服务任务）可以分配给已经存在的或新的流程变量，    可以通过指定服务任务定义的'activiti:resultVariable'属性来实现。    指定的路程比那两的值会被服务流程的返回结果覆盖。    如果没有指定返回变量名，就会忽略返回结果。

<serviceTaskid="aMethodExpressionServiceTask"     activiti:expression="#{myService.doSomething()}"     activiti:resultVariable="myVar"/>

在上面的例子中，服务流程的返回值（在'myService'上调用'doSomething()'方法的返回值，     myService可能是流程变量，也可能是spring的bean），会设置到名为'myVar'的流程变量里，    在服务执行完成之后。

执行自定义逻辑时，常常需要捕获对应的业务异常，在流程内部进行处理。 activiti提供了不同的方式来处理这个问题。

publicclassThrowBpmnErrorDelegateimplementsJavaDelegate{
  publicvoid execute(DelegateExecution execution)throwsException{     try{       executeBusinessLogic();     }catch(BusinessException e){       thrownewBpmnError("BusinessExceptionOccured");     }   }
}

<serviceTaskid="javaService"   name="Java service invocation"   activiti:class="org.activiti.ThrowsExceptionBehavior"></serviceTask>
<sequenceFlowid="no-exception"sourceRef="javaService"targetRef="theEnd"/><sequenceFlowid="exception"sourceRef="javaService"targetRef="fixException"/>

publicclassThrowsExceptionBehaviorimplementsActivityBehavior{
  publicvoid execute(ActivityExecution execution)throwsException{     Stringvar=(String) execution.getVariable("var");
    PvmTransition transition =null;     try{       executeLogic(var);       transition = execution.getActivity().findOutgoingTransition("no-exception");     }catch(Exception e){       transition = execution.getActivity().findOutgoingTransition("exception");     }     execution.take(transition);   }
}

一些场景下，需要在java服务任务中使用activiti服务 （比如，通过RuntimeService启动流程实例，而callActivity不满足你的需求）。 org.activiti.engine.delegate.DelegateExecution允许通过 org.activiti.engine.EngineServices接口直接获得这些服务：

publicclassStartProcessInstanceTestDelegateimplementsJavaDelegate{
  publicvoid execute(DelegateExecution execution)throwsException{     RuntimeService runtimeService = execution.getEngineServices().getRuntimeService();     runtimeService.startProcessInstanceByKey("myProcess");   }
}             

所有activiti服务的API都可以通过这个接口获得。

使用这些API调用出现的所有数据改变，都是在当前事务中的。 在像spring和CDI这样的依赖注入环境也会起作用，无论是否启用了JTA数据源。 比如，下面的代码功能与上面的代码一致， 这是RuntimeService是通过依赖注入获得的，而不是通过org.activiti.engine.EngineServices接口。

@Component("startProcessInstanceDelegate")publicclassStartProcessInstanceTestDelegateWithInjection{
    @Autowired     privateRuntimeService runtimeService;
    publicvoid startProcess(){       runtimeService.startProcessInstanceByKey("oneTaskProcess");     }
}             

重要技术提示：因为服务调用是在当前事务里， 数据的产生或改变，在服务任务执行完之前，还没有提交到数据库。 所有API对于数据库数据的操作，意味着未提交的操作在服务任务的API调用中都是不可见的。

Web Service任务可以用来同步调用一个外部的Web service。

Web Service任务与Java服务任务显示效果一样。

要使用Web Service我们需要导入它的操作和类型。 可以自动使用import标签来指定Web Service的WSDL：

<importimportType="http://schemas.xmlsoap.org/wsdl/"         location="http://localhost:63081/counter?wsdl"         namespace="http://webservice.activiti.org/"/>

上面的声明告诉activiti导入WSDL定义，但没有创建item定义和消息。 假设我们想调用一个名为'prettyPrint'的方法， 我们必须创建为请求和响应信息对应的消息和item定义：

<messageid="prettyPrintCountRequestMessage"itemRef="tns:prettyPrintCountRequestItem"/><messageid="prettyPrintCountResponseMessage"itemRef="tns:prettyPrintCountResponseItem"/>
<itemDefinitionid="prettyPrintCountRequestItem"structureRef="counter:prettyPrintCount"/><itemDefinitionid="prettyPrintCountResponseItem"structureRef="counter:prettyPrintCountResponse"/>

在申请服务任务之前，我们必须定义实际引用Web Service的BPMN接口和操作。 基本上，我们定义接口和必要的操作。对每个奥做我们都会重用上面定义的信息作为输入和输出。 比如，下面定义了'counter'接口和'prettyPrintCountOperation'操作：

<interfacename="Counter Interface"implementationRef="counter:Counter">         <operationid="prettyPrintCountOperation"name="prettyPrintCount Operation"                         implementationRef="counter:prettyPrintCount">                 <inMessageRef>tns:prettyPrintCountRequestMessage</inMessageRef>                 <outMessageRef>tns:prettyPrintCountResponseMessage</outMessageRef>         </operation></interface>

然后我们可以定义Web Service任务使用##WebService实现， 并引用Web Service操作。

<serviceTaskid="webService"         name="Web service invocation"         implementation="##WebService"         operationRef="tns:prettyPrintCountOperation">

除非我们使用简化方式处理数据输入和输出关联（如下所示），每个Web Service任务可以定义任务的输入输出IO规范。 配置方式与BPMN 2.0完全兼容，下面格式化后的例子，我们根据之前定义item定义，定义了输入和输出。

<ioSpecification>         <dataInputitemSubjectRef="tns:prettyPrintCountRequestItem"id="dataInputOfServiceTask"/>         <dataOutputitemSubjectRef="tns:prettyPrintCountResponseItem"id="dataOutputOfServiceTask"/>         <inputSet>                 <dataInputRefs>dataInputOfServiceTask</dataInputRefs>         </inputSet>         <outputSet>                 <dataOutputRefs>dataOutputOfServiceTask</dataOutputRefs>         </outputSet></ioSpecification>

有两种方式指定数据输入关联：

要使用表达式指定数据输入关联，我们需要定义来源和目的item，并指定每个item属性之间的对应关系。 下面的例子中我们分配了这些item的前缀和后缀：

<dataInputAssociation>         <sourceRef>dataInputOfProcess</sourceRef>         <targetRef>dataInputOfServiceTask</targetRef>         <assignment>                 <from>${dataInputOfProcess.prefix}</from>                 <to>${dataInputOfServiceTask.prefix}</to>         </assignment>         <assignment>                 <from>${dataInputOfProcess.suffix}</from>                 <to>${dataInputOfServiceTask.suffix}</to>         </assignment></dataInputAssociation>

另外，我们可以使用更简单的简化方式。'sourceRef'元素是activiti的变量名， 'targetRef'元素是item定义的一个属性。在下面的例子中，我们把'PrefixVariable'变量的值分配给'field'属性， 把'SuffixVariable'变量的值分配给'suffix'属性。

<dataInputAssociation>         <sourceRef>PrefixVariable</sourceRef>         <targetRef>prefix</targetRef></dataInputAssociation><dataInputAssociation>         <sourceRef>SuffixVariable</sourceRef>         <targetRef>suffix</targetRef></dataInputAssociation>

有两种方式指定数据输出关联：

要使用表达式指定数据输出关联，我们需要定义目的变量和来源表达式。 方法和数据输入关联完全一样：

<dataOutputAssociation>         <targetRef>dataOutputOfProcess</targetRef>         <transformation>${dataOutputOfServiceTask.prettyPrint}</transformation></dataOutputAssociation>

另外，我们可以使用更简单的简化方式。'sourceRef'元素是item定义的一个属性， 'targetRef'元素是activiti的变量名。 方法和数据输入关联完全一样：

<dataOutputAssociation>         <sourceRef>prettyPrint</sourceRef>         <targetRef>OutputVariable</targetRef></dataOutputAssociation>

业务规则用户用来同步执行一个或多个规则。activiti使用drools规则引擎执行业务规则。 目前，包含业务规则的.drl文件必须和流程定义一起发布，流程定义里包含了执行这些规则的业务规则任务。 意味着流程使用的所有.drl文件都必须打包在流程BAR文件里，比如任务表单。 更多使用Drools Expert创建业务规则的信息，请参考JBoss Drools的文档。

如果想要使用你的规则任务的实现，比如，因为你想用不同方式使用drools，或你想使用完全不同的规则引擎，   你可以使用BusinessRuleTask上的class或表达式属性，它用起来就和    ServiceTask一样。

业务规则任务使用一个表格小图标进行显示。

要执行部署流程定义的BAR文件中的一个或多个业务规则，我们需要定义输入和输出变量。 对于输入变量定义，可以使用逗号分隔的一些流程变量。 输出变量定义智能包含一个变量名，，它会把执行业务规则后返回的对象保存到对应的流程变量中。 注意，结果变量会包含一个对象列表。如果没有指定输出变量名称，默认会使用 org.activiti.engine.rules.OUTPUT。

下面的业务规则任务会执行和流程定义一起部署的素有业务规则：

<processid="simpleBusinessRuleProcess">
  <startEventid="theStart"/>   <sequenceFlowsourceRef="theStart"targetRef="businessRuleTask"/>
  <businessRuleTaskid="businessRuleTask"activiti:ruleVariablesInput="${order}"       activiti:resultVariable="rulesOutput"/>
  <sequenceFlowsourceRef="businessRuleTask"targetRef="theEnd"/>
  <endEventid="theEnd"/>
</process>                           

业务规则任务也可以配置成只执行部署的.drl文件中的一些规则。 这时要设置逗号分隔的规则名。

<businessRuleTaskid="businessRuleTask"activiti:ruleVariablesInput="${order}"       activiti:rules="rule1, rule2"/>                           

这时，只会执行rule1和rule2。

你也可以定义哪些规则不用执行。

<businessRuleTaskid="businessRuleTask"activiti:ruleVariablesInput="${order}"       activiti:rules="rule1, rule2"exclude="true"/>                           

这时除了rule1和rule2以外，所有部署到流程定义同一个BAR文件中的规则都会执行。

像之前提到的，可以用一个选项修改BusinessRuleTask的实现：

<businessRuleTaskid="businessRuleTask"activiti:class="${MyRuleServiceDelegate}"/>                           

注意BusinessRuleTask的功能和ServiceTask一样，但是我们使用BusinessRuleTask的图标来表示   我们在这里要执行业务规则。

activiti引擎要通过支持SMTP功能的外部邮件服务器发送邮件。   为了实际发送邮件，引擎穾知道如何访问邮件服务器。   下面的配置可以设置到activiti.cfg.xml配置文件中：

邮件任务是一个专用的服务任务，   这个服务任务的type设置为'mail'。

<serviceTaskid="sendMail"activiti:type="mail">                       

邮件任务是通过属性注入进行配置的。   所有这些属性都可以使用EL表达式，可以在流程执行中解析。   下面的属性都可以设置：

下面的XML演示了使用邮件任务的例子。

<serviceTaskid="sendMail"activiti:type="mail">   <extensionElements>     <activiti:fieldname="from"stringValue="order-shipping@thecompany.com"/>     <activiti:fieldname="to"expression="${recipient}"/>     <activiti:fieldname="subject"expression="Your order ${orderId} has been shipped"/>     <activiti:fieldname="html">       <activiti:expression>         <![CDATA[           <html>             <body>               Hello ${male ? 'Mr.' : 'Mrs.' } ${recipientName},<br/><br/>
              As of ${now}, your order has been <b>processed and shipped</b>.<br/><br/>
              Kind regards,<br/>
              TheCompany.             </body>           </html>         ]]>       </activiti:expression>     </activiti:field>   </extensionElements></serviceTask>                       

结果如下：

mule任务是一个专用的服务任务，   这个服务任务的type设置为'mule'。

<serviceTaskid="sendMule"activiti:type="mule">                       

mule任务是通过属性注入进行配置的。   所有这些属性都可以使用EL表达式，可以在流程执行中解析。   下面的属性都可以设置：

下面是一个使用mule任务的例子。

  <extensionElements>     <activiti:fieldname="endpointUrl">       <activiti:string>vm://in</activiti:string>     </activiti:field>     <activiti:fieldname="language">       <activiti:string>juel</activiti:string>     </activiti:field>     <activiti:fieldname="payloadExpression">       <activiti:string>"hi"</activiti:string>     </activiti:field>     <activiti:fieldname="resultVariable">       <activiti:string>theVariable</activiti:string>     </activiti:field>   </extensionElements>                       

camel任务是一个专用的服务任务，   这个服务任务的type设置为'camel'。

<serviceTaskid="sendCamel"activiti:type="camel">           

流程定义只需要在服务任务中定义camel类型。   集成逻辑都会代理给camel容器。默认activiti引擎会在spring容器中查找camelContext bean。    camelContext定义了camel容器加载的路由规则。下面的例子中路由规则是从指定的java包下加载的。   但是你也可以通过spring配置直接定义路由规则。

<camelContextid="camelContext"xmlns="http://camel.apache.org/schema/spring">   <packageScan>     <package>org.activiti.camel.route</package>   </packageScan></camelContext>

如果想了解更多关于camel路由的信息，可以访问Camel的网站。   在这里只通过很小的例子演示了基础的概念。   在第一个例子中，我们会通过activiti工作流实现最简单的Camel调用。我们称其为SimpleCamelCall。

如果想定义多个Camel环境bean，并且（或者）想使用不同的bean名称，可以重载CamelTask的定义，如下所示：

<serviceTaskid="serviceTask1"activiti:type="camel">         <extensionElements>                 <activiti:fieldname="camelContext"stringValue="customCamelContext"/>         </extensionElements></serviceTask>                 

这个例子对应的文件都可以在activiti camel模块的org.activiti.camel.examples.simpleCamelCall包下找到。我们的目标是简单激活一个特定的camel路由。 首先，我们需要一个Spring环境，它要包含之前介绍的路由。这些文件的目的如下：

<camelContextid="camelContext"xmlns="http://camel.apache.org/schema/spring">         <packageScan>                 <package>org.activiti.camel.examples.simpleCamelCall</package>         </packageScan></camelContext>          

包含名为SimpleCamelCallRoute的路由的类文件，放在PackageScan标签的扫描目录下。    下面就是路由的定义：

publicclassSimpleCamelCallRouteextendsRouteBuilder{
  @Override   publicvoid configure()throwsException{
          from("activiti:SimpleCamelCallProcess:simpleCall").to("log: org.activiti.camel.examples.SimpleCamelCall");   }}

这个规则仅仅打印消息体，不会做其他事情。注意终端的格式。它包含三部分：

OK，我们的规则已经配置好，也可以让Camel使用了。 现在看工作流部分。工作流看起来像这样：

<processid="SimpleCamelCallProcess">         <startEventid="start"/>         <sequenceFlowid="flow1"sourceRef="start"targetRef="simpleCall"/>                          <serviceTaskid="simpleCall"activiti:type="camel"/>                          <sequenceFlowid="flow2"sourceRef="simpleCall"targetRef="end"/>         <endEventid="end"/></process>           

在serviceTask部分，它只注明服务的类型是Camel，目标规则名为simpleCall。这与上面的activiti终端相匹配。初始化流程后，我们会看到一个空的日志。 好，我们已经完成了这个最简单的例子了。

我们的例子成功执行了，但是Camel和Activiti之间没有任何交互，而且这样做也没有任何优势。在这个例子里，我们尝试向Camel发送和接收数据。 我们发送一个字符串，camel进行一些处理，然后返回结果。 发送部分很简单，我们把变量里的消息发送给camel。这里是我们的调用代码：

@Deploymentpublicvoid testPingPong(){   Map<String,Object> variables =newHashMap<String,Object>();
  variables.put("input","Hello");   Map<String,String> outputMap =newHashMap<String,String>();   variables.put("outputMap", outputMap);
  runtimeService.startProcessInstanceByKey("PingPongProcess", variables);   assertEquals(1, outputMap.size());   assertNotNull(outputMap.get("outputValue"));   assertEquals("Hello World", outputMap.get("outputValue"));}         

变量"input"是Camel规则的实际输入，outputMap会记录camel返回的结果。流程应该像是这样：

<processid="PingPongProcess">   <startEventid="start"/>   <sequenceFlowid="flow1"sourceRef="start"targetRef="ping"/>   <serviceTaskid="ping"activiti:type="camel"/>   <sequenceFlowid="flow2"sourceRef="ping"targetRef="saveOutput"/>   <serviceTaskid="saveOutput"  activiti:class="org.activiti.camel.examples.pingPong.SaveOutput"/>   <sequenceFlowid="flow3"sourceRef="saveOutput"targetRef="end"/>   <endEventid="end"/></process>     

注意，SaveOuput这个serviceTask，会把"Output"变量的值从上下文保存到上面提到的OutputMap中。 现在，我们必须了解变量是如何发送给Camel，再返回的。这里就要涉及到camel实际执行的行为了。 变量提交给camel的方法是由CamelBehavior控制的。这里我们使用默认的配置，其他的会在后面提及。 使用这些代码，我们就可以配置一个期望的camel行为：

<serviceTaskid="serviceTask1"activiti:type="camel">   <extensionElements>     <activiti:fieldname="camelBehaviorClass"stringValue="org.activiti.camel.impl.CamelBehaviorCamelBodyImpl"/>   </extensionElements></serviceTask>         

如果你没有特别指定一个行为，就会使用org.activiti.camel.impl.CamelBehaviorDefaultImpl。 这个行为会把变量复制成名称相同的Camel属性。 在返回时，无论选择什么行为，如果camel消息体是一个map，每个元素都会复制成一个变量， 否则整个对象会复制到指定名称为"camelBody"的变量中。 了解这些后，就可以看看我们第二个例子的camel规则了：

@Overridepublicvoid configure()throwsException{   from("activiti:PingPongProcess:ping").transform().simple("${property.input} World");}         

在这个规则中，字符串"world"会被添加到"input"属性的后面，结果会写入消息体。 这时可以检查javaServiceTask中的"camelBody"变量，复制到"outputMap"中，并在testcase进行判断。 现在这个例子是在默认的行为下运行的，然后我们看一起其他的方案。 在启动的所有camel规则中，流程实例id会复制到camel的名为"PROCESS_ID_PROPERTY"的属性中。 后续可以用它关联流程实例和camel规则。他也可以在camel规则中直接使用。

Activiti中可以使用三种不同的行为。这些行为可以通过在规则URL中指定对应的环节来实现覆盖。 这里有一个在URL中覆盖现存行为的例子：

from("activiti:asyncCamelProcess:serviceTaskAsync2?copyVariablesToProperties=true").                 

下面的表格提供了三种camel行为的概述：

上面的表格解释和activiti变量如何传递给camel。下面的表格解释和camel的变量如何返回给activiti。 它只能配置在规则URL中。

例子的源码放在activiti-camel模块的org.activiti.camel.examples.pingPong包下。

之前的例子都是同步的。流程会等到camel规则返回之后才会停止。 一些情况下，我们需要activiti工作流继续运行。这时camelServiceTask的异步功能就特别有用。 你可以通过设置camelServiceTask的async属性来启用这个功能。

<serviceTaskid="serviceAsyncPing"activiti:type="camel"activiti:async="true"/>                 

通过设置这个功能，camel规则会被activiti的jobExecutor异步执行。 当你在camel规则中定义了一个队列，activiti流程会在camelServiceTask执行时继续运行。 camel规则会以完全异步的方式执行。 如果你想在什么地方等待camelServiceTask的返回值，你可以使用一个receiveTask。

<receiveTaskid="receiveAsyncPing"name="Wait State"/>                 

流程实例会等到接收一个signal，比如来自camel。在camel中你可以发送一个signal给流程实例，通过对应的activiti终端发送消息。

 from("activiti:asyncPingProcess:serviceAsyncPing").to("activiti:asyncPingProcess:receiveAsyncPing");                 

对于一个常用的终端，会使用冒号分隔的三个部分：

之前的所有例子中，activiti工作流会先启动，然后在流程中启动camel规则。 也可以使用另外一种方法。在已经启动的camel规则中启动一个工作流。 这会触发一个receiveTask十分类似，除了最后的部分。这是一个实例规则：

from("direct:start").to("activiti:camelProcess");         

我们看到url有两个部分，第一个部分是常量字符串"activiti"，第二部分是流程的名称。 很明显，流程应该已经部署完成，并且是可以启动的。

手工任务定义了BPM引擎外部的任务。   用来表示工作需要某人完成，而引擎不需要知道，也没有对应的系统和UI接口。   对于引擎，手工任务是直接通过的活动，   流程到达它之后会自动向下执行。

手工任务显示为一个圆角矩形，左上角是一个手型小图标。

<manualTaskid="myManualTask"name="Call client for more information"/>

接收任务是一个简单任务，它会等待对应消息的到达。   当前，我们只实现了这个任务的java语义。   当流程达到接收任务，流程状态会保存到存储里。   意味着流程会等待在这个等待状态，   直到引擎接收了一个特定的消息，   这会触发流程穿过接收任务继续执行。

接收任务显示为一个任务（圆角矩形），右上角有一个消息小标记。   消息是白色的（黑色图标表示发送语义）

<receiveTaskid="waitState"name="wait"/>    

要在接收任务等待的流程实例继续执行，   可以调用runtimeService.signal(executionId)，传递接收任务上流程的id。   下面的代码演示了实际是如何工作的：

ProcessInstance pi = runtimeService.startProcessInstanceByKey("receiveTask");Execution execution = runtimeService.createExecutionQuery()   .processInstanceId(pi.getId())   .activityId("waitState")   .singleResult(); assertNotNull(execution);
runtimeService.signal(execution.getId());           

shell任务可以执行shell脚本和命令。 注意shell任务不是BPMN 2.0规范定义的官方任务。 （它也没有对应的图标）。

shell任务是一个专用的服务任务， 这个服务任务的type设置为'shell'。

<serviceTaskid="shellEcho"activiti:type="shell">                       

shell任务使用属性注入进行配置。   所有属性都可以包含EL表达式，会在流程执行过程中解析。   可以配置以下属性：

下面的代码演示了使用shell任务的实例。它会执行shell脚本"cmd /c echo EchoTest"，等到它结束，再把输出结果保存到resultVar中。

<serviceTaskid="shellEcho"activiti:type="shell">   <extensionElements>     <activiti:fieldname="command"stringValue="cmd"/>     <activiti:fieldname="arg1"stringValue="/c"/>     <activiti:fieldname="arg2"stringValue="echo"/>     <activiti:fieldname="arg3"stringValue="EchoTest"/>     <activiti:fieldname="wait"stringValue="true"/>     <activiti:fieldname="outputVariable"stringValue="resultVar"/>   </extensionElements></serviceTask>                       

• 流程实例的启动和结束。

• 选中一条连线。

• 节点的开始和结束。

• 网关的开始和结束。

• 中间事件的开始和结束。

• 开始时间结束或结束事件开始。

使用流程监听器时，可以配置class属性，可以使用属性注入。 这和使用服务任务属性注入相同， 参考它可以获得属性注入的很多信息。

下面的代码演示了使用了属性注入的流程监听器的流程的简单例子。

 <processid="executionListenersProcess">     <extensionElements>       <activiti:executionListenerclass="org.activiti.examples.bpmn.executionListener.ExampleFieldInjectedExecutionListener"event="start">         <activiti:fieldname="fixedValue"stringValue="Yes, I am "/>         <activiti:fieldname="dynamicValue"expression="${myVar}"/>       </activiti:executionListener>     </extensionElements>
    <startEventid="theStart"/>     <sequenceFlowsourceRef="theStart"targetRef="firstTask"/>
    <userTaskid="firstTask"/>     <sequenceFlowsourceRef="firstTask"targetRef="theEnd"/>
    <endEventid="theEnd"/>   </process>         

publicclassExampleFieldInjectedExecutionListenerimplementsExecutionListener{
  privateExpression fixedValue;
  privateExpression dynamicValue;
  publicvoid notify(ExecutionListenerExecution execution)throwsException{     execution.setVariable("var",fixedValue.getValue(execution).toString()+dynamicValue.getValue(execution).toString());   }}           

ExampleFieldInjectedExecutionListener类串联了两个注入的属性。   （一个是固定的，一个是动态的），把他们保存到流程变量'var'中。

@Deployment(resources ={"org/activiti/examples/bpmn/executionListener/ExecutionListenersFieldInjectionProcess.bpmn20.xml"})publicvoid testExecutionListenerFieldInjection(){   Map<String,Object> variables =newHashMap<String,Object>();   variables.put("myVar","listening!");
  ProcessInstance processInstance = runtimeService.startProcessInstanceByKey("executionListenersProcess", variables);
  Object varSetByListener = runtimeService.getVariable(processInstance.getId(),"var");   assertNotNull(varSetByListener);   assertTrue(varSetByListener instanceofString);
  // Result is a concatenation of fixed injected field and injected expression   assertEquals("Yes, I am listening!", varSetByListener);}         

• event（必选）：任务监听器会被调用的任务类型。 可能的类型为：

  • create：任务创建并设置所有属性后触发。

  • assignment：任务分配给一些人时触发。   当流程到达userTask， assignment事件   会在create事件之前发生。   这样的顺序似乎不自然，但是原因很简单：当获得create时间时，   我们想获得任务的所有属性，包括执行人。

  • complete：当任务完成，并尚未从运行数据中删除时触发。

  • delete：只在任务删除之前发生。   注意在通过completeTask正常完成时，也会执行。

• class：必须调用的代理类。 这个类必须实现org.activiti.engine.impl.pvm.delegate.TaskListener接口。

  publicclassMyTaskCreateListenerimplementsTaskListener{
    publicvoid notify(DelegateTask delegateTask){     // Custom logic goes here   }
  }

  可以使用属性注入把流程变量或执行传递给代理类。 注意代理类的实例是在部署时创建的 （和activiti中其他类代理的情况一样），这意味着所有流程实例都会共享同一个实例。

• expression：（无法同时与class属性一起使用）： 指定事件发生时执行的表达式。 可以把DelegateTask对象和事件名称（使用task.eventName） 作为参数传递给调用的对象。

  <activiti:taskListenerevent="create"expression="${myObject.callMethod(task, task.eventName)}"/>

• delegateExpression可以指定一个表达式，解析一个实现了TaskListener接口的对象， 这与服务任务一致。

  <activiti:taskListenerevent="create"delegateExpression="${myTaskListenerBean}"/>

• 在activiti 5.12中，我们也介绍了新的任务监听器，org.activiti.engine.impl.bpmn.listener.ScriptTaskListener。   脚本任务监听器可以为任务监听器事件执行脚本。

  <activiti:taskListenerevent="complete"class="org.activiti.engine.impl.bpmn.listener.ScriptTaskListener">   <activiti:fieldname="script">     <activiti:string>       def bar = "BAR";  // local variable       foo = "FOO"; // pushes variable to execution context       task.setOwner("kermit"); // test access to task instance       bar // implicit return value     </activiti:string>   </activiti:field>   <activiti:fieldname="language"stringValue="groovy"/>   <activiti:fieldname="resultVariable"stringValue="myVar"/><activiti:taskListener>

多实例节点是在业务流程中定义重复环节的一个方法。   从开发角度讲，多实例和循环是一样的：   它可以根据给定的集合，为每个元素执行一个环节甚至一个完整的子流程，    既可以顺序依次执行也可以并发同步执行。

多实例是在一个普通的节点上添加了额外的属性定义   （所以叫做'多实例特性'），这样运行时节点就会执行多次。   下面的节点都可以成为一个多实例节点：

网关和事件    不能设置多实例。

根据规范的要求，每个上级流程为每个实例创建分支时都要提供如下变量：

可以通过execution.getVariable(x)方法获得这些变量。

另外，每个创建的分支都会有分支级别的本地变量（比如，其他实例不可见，   不会保存到流程实例级别）：

如果节点是多实例的，会在节点底部显示三条短线。   三条竖线表示实例会并行执行。   三条横线表示顺序执行。

要把一个节点设置为多实例，节点xml元素必须设置一个multiInstanceLoopCharacteristics子元素。

<multiInstanceLoopCharacteristicsisSequential="false|true">  ... </multiInstanceLoopCharacteristics>

isSequential属性表示节点是进行 顺序执行还是并行执行。

实例的数量会在进入节点时计算一次。   有一些方法配置它。一种方法是使用loopCardinality子元素直接指定一个数字。

<multiInstanceLoopCharacteristicsisSequential="false|true">   <loopCardinality>5</loopCardinality></multiInstanceLoopCharacteristics>

也可以使用结果为整数的表达式：

<multiInstanceLoopCharacteristicsisSequential="false|true">   <loopCardinality>${nrOfOrders-nrOfCancellations}</loopCardinality></multiInstanceLoopCharacteristics>

另一个定义实例数目的方法是，通过loopDataInputRef子元素，设置一个类型为集合的流程变量名。   对于集合中的每个元素，都会创建一个实例。   也可以通过inputDataItem子元素指定集合。   下面的代码演示了这些配置：

<userTaskid="miTasks"name="My Task ${loopCounter}"activiti:assignee="${assignee}">   <multiInstanceLoopCharacteristicsisSequential="false">     <loopDataInputRef>assigneeList</loopDataInputRef>     <inputDataItemname="assignee"/>   </multiInstanceLoopCharacteristics></userTask>

假设assigneeList变量包含这些值[kermit, gonzo, foziee]。   在上面代码中，三个用户任务会同时创建。每个分支都会拥有一个用名为assignee的流程变量，   这个变量会包含集合中的对应元素，在例子中会用来设置用户任务的分配者。

loopDataInputRef和inputDataItem的缺点是1）名字不好记，    2）根据BPMN 2.0格式定义，它们不能包含表达式。activiti通过在    multiInstanceCharacteristics中设置    collection和    elementVariable属性解决了这个问题：

<userTaskid="miTasks"name="My Task"activiti:assignee="${assignee}">   <multiInstanceLoopCharacteristicsisSequential="true"      activiti:collection="${myService.resolveUsersForTask()}"activiti:elementVariable="assignee">   </multiInstanceLoopCharacteristics></userTask>

多实例节点在所有实例都完成时才会结束。也可以指定一个表达式在每个实例结束时执行。   如果表达式返回true，所有其他的实例都会销毁，多实例节点也会结束，流程会继续执行。   这个表达式必须定义在completionCondition子元素中。

<userTaskid="miTasks"name="My Task"activiti:assignee="${assignee}">   <multiInstanceLoopCharacteristicsisSequential="false"      activiti:collection="assigneeList"activiti:elementVariable="assignee">     <completionCondition>${nrOfCompletedInstances/nrOfInstances >= 0.6 }</completionCondition>   </multiInstanceLoopCharacteristics></userTask>

在这里例子中，会为assigneeList集合的每个元素创建一个并行的实例。   当60%的任务完成时，其他任务就会删除，流程继续执行。

因为多实例是一个普通节点，它也可以在边缘使用边界事件。   对于中断型边界事件，当捕获事件时，所有激活的实例都会销毁。   参考以下多实例子流程：

这里，子流程的所有实例都会在定时器触发时销毁，无论有多少实例，   也不管内部哪个节点没有完成。

[EXPERIMENTAL]

如果一个节点用来补偿另一个节点的业务，它可以声明为一个补偿处理器。 补偿处理器不包含普通的流，只在补偿事件触发时执行。

补偿处理器不能包含进入和外出顺序流。

补偿处理器必须使用直接关联分配给一个补偿边界事件。

如果节点是补偿处理器，补偿事件图标会显示在中间底部区域。下面的流程图显示了一个服务任务，附加了一个补偿边界事件，   并分配了一个补偿处理器。   注意"cancel hotel reservation"服务任务中间底部区域显示的补偿处理器图标。

为了声明作为补偿处理器的节点，我们需要把isForCompensation设置为true：

<serviceTaskid="undoBookHotel"isForCompensation="true"activiti:class="..."></serviceTask>

子流程（Sub-process）是一个包含其他节点，网关，事件等等的节点。   它自己就是一个流程，同时是更大流程的一部分。    子流程是完全定义在父流程里的   （这就是为什么叫做内嵌子流程）。

子流程有两种主要场景：

使用子流程要考虑如下限制：

子流程显示为标准的节点，圆角矩形。   这时子流程是折叠的，只显示名称和一个加号标记，   展示了高级别的流程总览：

这时子流程是展开的，子流程的步骤都显示在子流程边界内：

使用子流程的主要原因，是定义对应事件的作用域。   下面流程模型演示了这个功能：调查软件/调查引荐任务需要同步执行，   两个任务需要在同时完成，在二线支持解决之前。   这里，定时器的作用域（比如，节点需要及时完成）是由子流程限制的。

子流程定义为subprocess元素。   所有节点，网关，事件，等等。它是子流程的一部分，需要放在这个元素里。

<subProcessid="subProcess">
  <startEventid="subProcessStart"/>
  ... other Sub-Process elements ...
  <endEventid="subProcessEnd"/>
 </subProcess>           

事件子流程是BPMN 2.0中的新元素。事件子流程是由事件触发的子流程。   事件子流程可以添加到流程级别或任意子流程级别。用于触发事件子流程的事件是使用开始事件配置的。   为此，事件子流程是不支持空开始事件的。   事件子流程可以被消息事件，错误事件，信号事件，定时器事件，或补偿事件触发。   开始事件的订阅在包含事件子流程的作用域（流程实例或子流程）创建时就会创建。   当作用域销毁也会删除订阅。

事件子流程可以是中断的或非中断的。一个中断的子流程会取消当前作用域内的所有流程。 非中断事件子流程会创建那一个新的同步分支。中断事件子流程只会被每个激活状态的宿主触发一次， 非中断事件子流程可以触发多次。子流程是否是终端的，配置使用事件子流程的开始事件配置。

事件子流程不能有任何进入和外出流程。当事件触发一个事件子流程时，输入顺序流是没有意义的。 当事件子流程结束时，无论当前作用域已经结束了（中断事件子流程的情况）， 或为非中断子流程生成同步分支会结束。

当前的限制：

事件子流程可以显示为边框为虚线的内嵌子流程。

事件子流程的XML内容与内嵌子流程是一样的。 另外，要把triggeredByEvent属性设置为true：

<subProcessid="eventSubProcess"triggeredByEvent="true">         ... </subProcess>

下面是一个使用错误开始事件触发的事件子流程的实例。事件子流程是放在“流程级别”的， 意思是，作用于流程实例：

事件子流程的XML如下所示：

<subProcessid="eventSubProcess"triggeredByEvent="true">         <startEventid="catchError">                 <errorEventDefinitionerrorRef="error"/>         </startEvent>         <sequenceFlowid="flow2"sourceRef="catchError"targetRef="taskAfterErrorCatch"/>         <userTaskid="taskAfterErrorCatch"name="Provide additional data"/></subProcess>

如上面所述，事件子流程也可以添加成内嵌子流程。如果添加为内嵌子流程，它其实是边界事件的一种替代方案。 考虑下面两个流程图。两种情况内嵌子流程会抛出一个错误事件。两种情况错误都会被捕获并使用一个用户任务处理。

相对于：

两种场景都会执行相同的任务。然而，两种建模的方式是不同的：

这两个不同点可以帮助我们决定是使用边界事件还是内嵌事件子流程来解决特定的流程建模/实现问题。

事务子流程是内嵌子流程，可以用来把多个流程放到一个事务里。   事务是一个逻辑单元，可以把一些单独的节点放在一起，这样它们就可以一起成功或一起失败。

事务可能的结果：     事务可以有三种可能的结果：

下面的图形演示了三种不同的结果：

与ACID事务的关系：一定不要吧bpmn事务子流程与技术（ACID）事务相混淆。 bpmn事务子流程不是技术事务领域的东西。要理解activiti中的事务管理，请参考 并发与事务。 bpmn事务和技术事务有以下不同点：

因为bpmn事务实际上运行时间很长，缺乏隔离性和回滚机制都需要被区别对待。 实际上，这里也没有更好的办法在特定领域处理这些问题：

综上所述：ACID处理的是通常问题（回滚，隔离级别和启发式结果）， 在实现业务事务时，我们需要找到特定领域的解决方案来处理这些问题。

目前的限制：

ACID事务顶层的一致性和优化并发： bpmn事务保证一致性，要么所有节点都成功，或者一些节点成功，对其他成功的节点进行补偿。 无论哪种方式，都会有一致性的结果。不过要讨论一些activiti内部的情况，bpmn事务的一致性模型是叠加在流程的一致性模型之上的。 activiti执行流程是事务性的。并发使用了乐观锁。在activiti中，bpmn错误，取消和补偿事件都建立在同样的acid事务与乐观锁之上。 比如，取消结束事件只能触发它实际到达的补偿。如果之前服务任务抛出了未声明的异常。或者， 补偿处理器的效果无法提交，如果底层的acid事务的参与者把事务设置成必须回滚。 或者当两个并发流程到达了取消结束事件，可能会触发两次补偿，并因为乐观锁异常失败。 所有这些都说明activiti中实现bpmn事务时，相同的规则也作用域普通的流程和子流程。 所以为了保证一致性，重要的是使用一种方式考虑实现乐观事务性的执行模型。

事务子流程显示为内嵌子流程，使用双线边框。

事务子流程使用transaction标签：

<transactionid="myTransaction">         ... </transaction>

下面是事务子流程的实例：

bpmn 2.0区分了普通子流程，   也叫做内嵌子流程，和调用节点，看起来很相似。   上概念上讲，当流程抵达及诶单时，两者都会调用子流程。

不同点是调用节点引用流程定义外部的一个流程，子流程   会内嵌到原始的流程定义中。使用调用节点的主要场景是需要重用流程定义，   这个流程定义需要被很多其他流程定义调用的时候。

当流程执行到调用节点，会创建一个新分支，它是到达调用节点的流程的分支。   这个分支会用来执行子流程，默认创建并行子流程，就像一个普通的流程。   上级流程会等待子流程完成，然后才会继续向下执行。

调用节点显示与子流程相同，   不过是粗边框（无论是折叠和展开的）。   根据不同的建模工具，调用节点也可以展开，但是显示为折叠的子流程。

A call activity is a regular activity, that requires a calledElement          that references a process definition by its key.          In practice, this means that the id of the process is          used in the calledElement.

<callActivityid="callCheckCreditProcess"name="Check credit"calledElement="checkCreditProcess"/>

注意，子流程的流程定义是在执行阶段解析的。   就是说子流程可以与调用的流程分开部署，如果需要的话。

可以把流程变量传递给子流程，反之亦然。数据会复制给子流程，当它启动的时候，   并在它结束的时候复制回主流程。

<callActivityid="callSubProcess"calledElement="checkCreditProcess">   <extensionElements>           <activiti:insource="someVariableInMainProcess"target="nameOfVariableInSubProcess"/>           <activiti:outsource="someVariableInSubProcss"target="nameOfVariableInMainProcess"/>   </extensionElements></callActivity>

我们使用activiti扩展来简化BPMN标准元素调用dataInputAssociation和    dataOutputAssociation，这只在你使用BPMN 2.0标准方式声明流程变量才管用。

这里也可以使用表达式：

<callActivityid="callSubProcess"calledElement="checkCreditProcess">         <extensionElements>           <activiti:insourceExpression="${x+5}"" target="y" />           <activiti:outsource="${y+5}"target="z"/>         </extensionElements></callActivity>

最后z = y + 5 = x + 5 + 5

下面的流程图演示了简单订单处理。先判断客户端信用，这可能与很多其他流程相同。    检查信用阶段这里设计成调用节点。

流程看起来像下面这样：

<startEventid="theStart"/><sequenceFlowid="flow1"sourceRef="theStart"targetRef="receiveOrder"/>
<manualTaskid="receiveOrder"name="Receive Order"/><sequenceFlowid="flow2"sourceRef="receiveOrder"targetRef="callCheckCreditProcess"/>
<callActivityid="callCheckCreditProcess"name="Check credit"calledElement="checkCreditProcess"/><sequenceFlowid="flow3"sourceRef="callCheckCreditProcess"targetRef="prepareAndShipTask"/>
<userTaskid="prepareAndShipTask"name="Prepare and Ship"/><sequenceFlowid="flow4"sourceRef="prepareAndShipTask"targetRef="end"/>
<endEventid="end"/>

子流程看起来像下面这样：

子流程的流程定义没有什么特别的。   它也可以单独使用，不用其他流程调用。

参考如下流程定义：

我们有一个并行网关，后面有三个服务任务，它们都设置为异步执行。这样会添加三个job到数据库里。 一旦job进入数据库，它就可以被jobExecutor执行了。JobExecutor会获取job，把它们代理到工作线程的线程池中，会在那里真正执行job。 就是说，使用异步执行，你可以吧任务分配给这个线程池（在集群环境，可能会使用多个线程池）。这通常是个好事情。 然而它也会产生问题：一致性。考虑一下服务任务后的汇聚。 当服务任务完成后，我们到达并发汇聚节点，需要决定是等待其他分支，还是继续向下执行。 就是说，对每个到达并行汇聚的分支，我们都需要判断是继续还是等待其他分支的一个或多个分支。

为什么这就是问题了呢？因为服务任务配置成使用异步执行，可能相关的job都在同一时间被获取，被JobExecutor分配给不同的工作线程执行。 结果是三个单独的服务执行使用的事务在到达并发汇聚时可能重叠。如果出现了这个问题，这些事务是互相不可见的， 其他事务同时到达了相同的并发汇聚，假设它们都在等待其他分支。然而，每个事务都假设它们在等待其他分支， 所以没有分支会越过并发汇聚继续执行，流程实例会一直在等待状态，无法继续执行。

activiti是如何解决这个问题的？activiti使用了乐观锁。当我们基于判断的数据看起来不是最新的时 （因为其他事务可能在我们提交之前进行了修改，我们会在每个事务里增加数据库同一行的版本）。这时，第一个提交的事务会成功， 其他会因为乐观锁异常导致失败。这就解决了我们上面讨论的流程的问题：如果多个分支同步到达并行汇聚， 它们会假设它们都在登录，并增加它们父流程的版本号（流程实例）然后尝试提交。 第一个分支会成功提交，其他分支会因为乐观锁导致失败。因为流程是被job触发的，   activiti会尝试在等待一段时间后尝试执行同一个job，想这段时间可以同步网关的状态。

这是一个很好的解决方案吗？像我们看到的一样，乐观锁允许activiti避免非一致性。它确定我们不会“堵在汇聚网关”， 意思是：或者所有分支都通过网关，或者数据库中的job正在尝试通过。然而，虽然这是一个对于持久性和一致性的完美解决方案， 但对于上层来说不一定是期望的行为：

在activiti中，我们推荐了新的概念，并已经在jbpm4中实现了，叫做“排他job”。

对于一个流程实例，排他任务不能同时执行两个。考虑上面的流程： 如果我们把服务任务申请为排他任务，JobExecutor会保证对应的job不会并发执行。 相反，它会保证无论什么时候获取一个流程实例的排他任务，都会把同一个流程实例的其他任务都取出来，放在同一个工作线程中执行。 它保证job是顺序执行的。

如何启用这个特性？从activiti 5.9开始，排他任务已经是默认配置了。所以异步执行和定时器事件默认都是排他任务。 另外，如果你想把job设置为非塔牌，可以使用activiti:exclusive="false"进行配置。 比如，下面的服务任务就是异步但是非排他的。

<serviceTaskid="service"activiti:expression="${myService.performBooking(hotel, dates)}"activiti:async="true"activiti:exclusive="false"/>                         

这是一个好方案吗？ 有一些人文我们这是否是一个好方案。他们的结论会帮你在并发和性能问题方面节省时间。 这个问题上需要考虑两件事情：

Chapter 9. 表单

Chapter 10. JPA

• 已经存在了一个使用JPA实体的Spring-bean，它用来存储贷款申请。

• 使用Activiti，我们可以通过已经存在的bean获取已经使用的实体，并使用它作为变量用于我们的流程中。

  按照下面的步骤定义流程：

  • 服务任务，创建一个新的贷款申请，使用已经存在的LoanRequestBean 接受启动流程时候的变量（例如 可以来自流程启动时候的表单）。   使用activiti:resultVariable（它作为一个变量对表达式返回的结果进行存储）将创建出来的实体作为变量进行存储。

  • 用户任务，允许经理查看贷款申请，并填入审批意见(同意/不同意)，审批意见将作为一个boolean变量approvedByManager进行存储

  • 服务任务，更新贷款申请实体因此该实体与流程保持同步

  • 根据贷款申请实体变量approved的值，将利用唯一网关（BPMN2规范）自动决定下一步该选择那一条路径：当申请批准，流程结束。否则，一个额外的任务将会使用   （发送拒绝信），所以这样就是可以让拒绝信手动通知客户。

Chapter 11. 历史

Chapter 12. Eclipse Designer

• 将你自己的形状/节点添加到现有的或新的抽屉内.

• 禁用Activiti Designer提供的任何或所有的默认BPMN 2.0的形状,除了连接工具和选择工具.

Note

可以使用你所偏爱的工具来设置你的项目,然后使用你选择的构建工具来构建JAR文件.    下面的说明,设置假设使用的是Eclipse Helios ，Maven（3.x）作为构建构建工具, 但任何其   它的设置也都能让你创建同样的结果.

下载并解压 Eclipse          (使用最新版本) 和最新版本(3.x)的Apache Maven. 如果你使用2.x版本          的Maven, 在构建项目时会运行出错, 所以确保你的版本是最新的. 我们假设你能熟练使用基   本特性和Eclipse的Java编辑器. 由你决定是使用Eclipse 的Maven 特性还是在命令行上运行    Maven 命令.

在Eclipse里创建一个新项目.这是一个普通的项目类型.在项目的根路径下创建 pom.xml文件用来包含Maven 项目的设置. 同时创建 src/main/java 和src/main/resources文件, 这是Maven 对于Java 源文件和资源的约定. 打开pom.xml 文件并添加下列代码:

<project   xmlns="http://maven.apache.org/POM/4.0.0"   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.acme</groupId>   <artifactId>money-tasks</artifactId>   <version>1.0.0</version>   <packaging>jar</packaging>   <name>Acme Corporation Money Tasks</name> ... </project>

正如你所看到的, 这只是一个定义了项目groupId, artifactId 和 version的基本的pom.xml 文件. 我们将创建 一个定制,其中包含我们money业务中一个的自定义节点.

通过在pom.xml 文件内引入依赖,就可以将集成的类库添加到你项目的依赖中:

<dependencies>   <dependency>     <groupId>org.activiti.designer</groupId>     <artifactId>org.activiti.designer.integration</artifactId>     <version>5.12.0</version><!-- Use the current Activiti Designer version -->     <scope>compile</scope>   </dependency></dependencies> ... <repositories>   <repository>       <id>Activiti</id>       <url>https://maven.alfresco.com/nexus/content/groups/public/</url>    </repository></repositories>

最后,在 pom.xml文件中添加对maven-compiler-plugin    的配置,Java 源代码级别最低是1.5 (看下面的代码片段). 这在使用注解时需要。也可以包含让Maven    生成JAR的MANIFEST.MF 文件的命令. 这不是必需的, 但这样你可以使用清单文   件的一个特定的属性作为扩展的名称 (这个名称可以显示在Designer的某处, 主要是为以后如果Designer    中有几个扩展的时候使用).如果你想这样做,将以下代码片段包含进 pom.xml文件: