Activiti 5.15 用户手册

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

<process id="testEventListeners">
  <extensionElements>
    <activiti:eventListener class="org.activiti.engine.test.MyEventListener" />
    <activiti:eventListener delegateExpression="${testEventListener}" events="JOB_EXECUTION_SUCCESS,JOB_EXECUTION_FAILURE" />
  </extensionElements>

  ...

</process>

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

<process id="testEventListeners">
  <extensionElements>
    <activiti:eventListener class="org.activiti.engine.test.MyEventListener" entityType="task" />
    <activiti:eventListener delegateExpression="${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属性，通过额外属性，指定了抛出事件的类型。

<process id="testEventListeners">
  <extensionElements>
    <activiti:eventListener throwEvent="signal" signalName="My signal" events="TASK_ASSIGNED" />
  </extensionElements>
</process>

<process id="testEventListeners">
  <extensionElements>
    <activiti:eventListener throwEvent="globalSignal" signalName="My signal" events="TASK_ASSIGNED" />
  </extensionElements>
</process>

<process id="testEventListeners">
  <extensionElements>
    <activiti:eventListener throwEvent="message" messageName="My message" events="TASK_ASSIGNED" />
  </extensionElements>
</process>

<process id="testEventListeners">
  <extensionElements>
    <activiti:eventListener throwEvent="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.

既可以通过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的标准属性）：

<signal id="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);	

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

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

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

ProcessInstance processInstance = runtimeService.startProcessInstanceByXXX();

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

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

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

<startEvent id="start" name="my start event" />

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

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

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

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

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

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

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

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

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

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

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

        <startEvent id="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子元素：

<definitions id="definitions"
  xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
  xmlns:activiti="http://activiti.org/bpmn"
  targetNamespace="Examples"
  xmlns:tns="Examples">

  <message id="newInvoice" name="newInvoiceMessage" />

  <process id="invoiceProcess">

    <startEvent id="messageStart" >
    	<messageEventDefinition messageRef="tns:newInvoice" />
    </startEvent>
    ...
  </process>

</definitions>

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

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

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

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

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

    <signal id="theSignal" name="The Signal" />

    <process id="processWithSignalStart1">
        <startEvent id="theStart">
          <signalEventDefinition id="theSignalEventDefinition" signalRef="theSignal"  />
        </startEvent>
        <sequenceFlow id="flow1" sourceRef="theStart" targetRef="theTask" />
        <userTask id="theTask" name="Task in process A" />
        <sequenceFlow id="flow2" sourceRef="theTask" targetRef="theEnd" />
        <endEvent id="theEnd" />
    </process>

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

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

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

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

<startEvent id="messageStart" >
	<errorEventDefinition errorRef="someError" />
</startEvent>

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

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

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

<endEvent id="end" name="my end event" />

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

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

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

<endEvent id="myErrorEndEvent">
  <errorEventDefinition errorRef="myError" />
</endEvent>
          

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

<error id="myError" errorCode="123" />
...
<process id="myProcess">
...
          

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

<error id="myError" errorCode="error123" />
...
<process id="myProcess">
...
  <endEvent id="myErrorEndEvent">
    <errorEventDefinition errorRef="myError" />
  </endEvent>
          

等同于

<endEvent id="myErrorEndEvent">
  <errorEventDefinition errorRef="error123" />
</endEvent>
          

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

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

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

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

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

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

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

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

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

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

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

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

<boundaryEvent id="escalationTimer" cancelActivity="false" attachedToRef="firstLineSupport"/>

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

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

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

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

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

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

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

<boundaryEvent id="catchError" attachedToRef="mySubProcess">
  <errorEventDefinition errorRef="myError"/>
</boundaryEvent>
          

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

<error id="myError" errorCode="123" />
...
<process id="myProcess">
...
          

errorCode用来匹配捕获的错误：

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

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

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

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

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

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

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

<boundaryEvent id="boundary" attachedToRef="task" cancelActivity="true">
          <signalEventDefinition signalRef="alertSignal"/>
</boundaryEvent>
          		

参考信号事件定义章节。

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

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

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

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

<boundaryEvent id="boundary" attachedToRef="task" cancelActivity="true">
          <messageEventDefinition messageRef="newCustomerMessage"/>
</boundaryEvent>
          		

参考消息事件定义章节。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<boundaryEvent id="compensateBookHotelEvt" attachedToRef="bookHotel" >
          <compensateEventDefinition />
</boundaryEvent>

<association associationDirection="One" id="a1"  sourceRef="compensateBookHotelEvt" targetRef="undoBookHotel" />

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

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

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

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

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

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

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

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

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

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

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

<intermediateCatchEvent id="signal">
	<signalEventDefinition signalRef="newCustomerSignal" />
</intermediateCatchEvent>
                 

参考信号事件定义章节。

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

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

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

<intermediateCatchEvent id="message">
	<messageEventDefinition signalRef="newCustomerMessage" />
</intermediateCatchEvent>
                 

参考消息事件定义章节。

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

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

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

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

<intermediateThrowEvent id="signal">
	<signalEventDefinition signalRef="newCustomerSignal" />
</intermediateThrowEvent>
                 

异步信号事件如下所示：

<intermediateThrowEvent id="signal">
	<signalEventDefinition signalRef="newCustomerSignal" activiti:async="true" />
</intermediateThrowEvent>
                 

参考信号事件定义章节。

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

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

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

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

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

已知限制：

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

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

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

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

<intermediateThrowEvent id="throwCompensation">
	<compensateEventDefinition activityRef="bookHotel" />
</intermediateThrowEvent>

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

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

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

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

<sequenceFlow id="flow" sourceRef="theStart" targetRef="theTask">
  <conditionExpression xsi: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时， 才会选择它作为外出连线继续执行。

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

对应下面的图形显示：

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

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

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

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

参考下面模型实例：

它对应的XML内容如下：

<exclusiveGateway id="exclusiveGw" name="Exclusive Gateway" />

<sequenceFlow id="flow2" sourceRef="exclusiveGw" targetRef="theTask1">
  <conditionExpression xsi:type="tFormalExpression">${input == 1}</conditionExpression>
</sequenceFlow>

<sequenceFlow id="flow3" sourceRef="exclusiveGw" targetRef="theTask2">
  <conditionExpression xsi:type="tFormalExpression">${input == 2}</conditionExpression>
</sequenceFlow>

<sequenceFlow id="flow4" sourceRef="exclusiveGw" targetRef="theTask3">
  <conditionExpression xsi:type="tFormalExpression">${input == 3}</conditionExpression>
</sequenceFlow>

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

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

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

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

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

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

<parallelGateway id="myParallelGateway" />

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

参考如下代码：

    <startEvent id="theStart" />
    <sequenceFlow id="flow1" sourceRef="theStart" targetRef="fork" />

    <parallelGateway id="fork" />
    <sequenceFlow sourceRef="fork" targetRef="receivePayment" />
    <sequenceFlow sourceRef="fork" targetRef="shipOrder" />

    <userTask id="receivePayment" name="Receive Payment" />
    <sequenceFlow sourceRef="receivePayment" targetRef="join" />

    <userTask id="shipOrder" name="Ship Order" />
    <sequenceFlow sourceRef="shipOrder" targetRef="join" />

    <parallelGateway id="join" />
    <sequenceFlow sourceRef="join" targetRef="archiveOrder" />

    <userTask id="archiveOrder" name="Archive Order" />
    <sequenceFlow sourceRef="archiveOrder" targetRef="theEnd" />

    <endEvent id="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：

<inclusiveGateway id="myInclusiveGateway" />

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

参考如下代码：

    <startEvent id="theStart" />
    <sequenceFlow id="flow1" sourceRef="theStart" targetRef="fork" />

    <inclusiveGateway id="fork" />
    <sequenceFlow sourceRef="fork" targetRef="receivePayment" >
    <conditionExpression xsi:type="tFormalExpression">${paymentReceived == false}</conditionExpression>
    </sequenceFlow>
    <sequenceFlow sourceRef="fork" targetRef="shipOrder" >
    <conditionExpression xsi:type="tFormalExpression">${shipOrder == true}</conditionExpression>
    </sequenceFlow>

    <userTask id="receivePayment" name="Receive Payment" />
    <sequenceFlow sourceRef="receivePayment" targetRef="join" />

    <userTask id="shipOrder" name="Ship Order" />
    <sequenceFlow sourceRef="shipOrder" targetRef="join" />

    <inclusiveGateway id="join" />
    <sequenceFlow sourceRef="join" targetRef="archiveOrder" />

    <userTask id="archiveOrder" name="Archive Order" />
    <sequenceFlow sourceRef="archiveOrder" targetRef="theEnd" />

    <endEvent id="theEnd" />

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

HashMap<String, Object> variableMap = new HashMap<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分钟内发出信号，定时器就会取消，流程会沿着信号执行。 如果信号没有出现，流程会沿着定时器的方向前进，信号订阅会被取消。

<definitions id="definitions"
	xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
	xmlns:activiti="http://activiti.org/bpmn"
	targetNamespace="Examples">

	<signal id="alertSignal" name="alert" />

	<process id="catchSignal">

		<startEvent id="start" />

		<sequenceFlow sourceRef="start" targetRef="gw1" />

		<eventBasedGateway id="gw1" />

		<sequenceFlow sourceRef="gw1" targetRef="signalEvent" />
		<sequenceFlow sourceRef="gw1" targetRef="timerEvent" />

		<intermediateCatchEvent id="signalEvent" name="Alert">
			<signalEventDefinition signalRef="alertSignal" />
		</intermediateCatchEvent>

		<intermediateCatchEvent id="timerEvent" name="Alert">
			<timerEventDefinition>
				<timeDuration>PT10M</timeDuration>
			</timerEventDefinition>
		</intermediateCatchEvent>

		<sequenceFlow sourceRef="timerEvent" targetRef="exGw1" />
		<sequenceFlow sourceRef="signalEvent" targetRef="task" />

		<userTask id="task" name="Handle alert"/>

		<exclusiveGateway id="exGw1" />

		<sequenceFlow sourceRef="task" targetRef="exGw1" />
		<sequenceFlow sourceRef="exGw1" targetRef="end" />

		<endEvent id="end" />
</process>
</definitions>

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

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

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

<userTask id="theTask" name="Important task" />
				  

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

<userTask id="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分钟。

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

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

<process ... >

  ...

  <userTask id='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 ... >

  ...

  <userTask id='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与其他已存的账户管理方案集成。

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

<userTask id="task1" name="My task" >
  <extensionElements>
    <activiti:taskListener event="create" class="org.activiti.MyAssignmentHandler" />
  </extensionElements>
</userTask>

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

public class MyAssignmentHandler implements TaskListener {

  public void 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。

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

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

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

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

public class FakeLdapService {

  public String findManagerForEmployee(String employee) {
    return "Kermit The Frog";
  }

  public List<String> findAllSales() {
    return Arrays.asList("kermit", "gonzo", "fozzie");
  }

}

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

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

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

<scriptTask id="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对于一些脚本语言，无法实现自动保存变量。 参考这里获得更多信息。

<scriptTask id="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'属性。 任何已存的流程变量都会被脚本执行的结果覆盖。 如果没有指定返回变量名，脚本的返回值会被忽略。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<serviceTask id="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的链接，获得更多信息）。

public class ToUppercase implements JavaDelegate {

  public void execute(DelegateExecution execution) throws Exception {
    String var = (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格式要求的。

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

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

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

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

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

<serviceTask id="javaService" name="Java service invocation"
  activiti:class="org.activiti.examples.bpmn.servicetask.ReverseStringsFieldInjected">

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

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

public class ReverseStringsFieldInjected implements JavaDelegate {

  private Expression text1;
  private Expression text2;

  public void execute(DelegateExecution execution) {
    String value1 = (String) text1.getValue(execution);
    execution.setVariable("var1", new StringBuffer(value1).reverse().toString());

    String value2 = (String) text2.getValue(execution);
    execution.setVariable("var2", new StringBuffer(value2).reverse().toString());
  }
}

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

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

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

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

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

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

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

public class ThrowBpmnErrorDelegate implements JavaDelegate {

  public void execute(DelegateExecution execution) throws Exception {
    try {
      executeBusinessLogic();
    } catch (BusinessException e) {
      throw new BpmnError("BusinessExceptionOccured");
    }
  }

}

<serviceTask id="javaService"
  name="Java service invocation"
  activiti:class="org.activiti.ThrowsExceptionBehavior">
</serviceTask>

<sequenceFlow id="no-exception" sourceRef="javaService" targetRef="theEnd" />
<sequenceFlow id="exception" sourceRef="javaService" targetRef="fixException" />

public class ThrowsExceptionBehavior implements ActivityBehavior {

  public void execute(ActivityExecution execution) throws Exception {
    String var = (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接口直接获得这些服务：

public class StartProcessInstanceTestDelegate implements JavaDelegate {

  public void execute(DelegateExecution execution) throws Exception {
    RuntimeService runtimeService = execution.getEngineServices().getRuntimeService();
    runtimeService.startProcessInstanceByKey("myProcess");
  }

}
            

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

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

@Component("startProcessInstanceDelegate")
public class StartProcessInstanceTestDelegateWithInjection {

    @Autowired
    private RuntimeService runtimeService;

    public void startProcess() {
      runtimeService.startProcessInstanceByKey("oneTaskProcess");
    }

}
            

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

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

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

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

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

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

<message id="prettyPrintCountRequestMessage" itemRef="tns:prettyPrintCountRequestItem" />
<message id="prettyPrintCountResponseMessage" itemRef="tns:prettyPrintCountResponseItem" />

<itemDefinition id="prettyPrintCountRequestItem" structureRef="counter:prettyPrintCount" />
<itemDefinition id="prettyPrintCountResponseItem" structureRef="counter:prettyPrintCountResponse" />

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

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

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

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

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

<ioSpecification>
	<dataInput itemSubjectRef="tns:prettyPrintCountRequestItem" id="dataInputOfServiceTask" />
	<dataOutput itemSubjectRef="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。

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

<process id="simpleBusinessRuleProcess">

  <startEvent id="theStart" />
  <sequenceFlow sourceRef="theStart" targetRef="businessRuleTask" />

  <businessRuleTask id="businessRuleTask" activiti:ruleVariablesInput="${order}"
      activiti:resultVariable="rulesOutput" />

  <sequenceFlow sourceRef="businessRuleTask" targetRef="theEnd" />

  <endEvent id="theEnd" />

</process>
			  

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

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

这时，只会执行rule1和rule2。

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

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

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

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

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

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

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

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

<serviceTask id="sendMail" activiti:type="mail">
		      

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

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

<serviceTask id="sendMail" activiti:type="mail">
  <extensionElements>
    <activiti:field name="from" stringValue="order-shipping@thecompany.com" />
    <activiti:field name="to" expression="${recipient}" />
    <activiti:field name="subject" expression="Your order ${orderId} has been shipped" />
    <activiti:field name="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'。

<serviceTask id="sendMule" activiti:type="mule">
		      

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

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

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

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

<serviceTask id="sendCamel" activiti:type="camel">
          

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

<camelContext id="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的定义，如下所示：

<serviceTask id="serviceTask1" activiti:type="camel">
	<extensionElements>
		<activiti:field name="camelContext" stringValue="customCamelContext" />
	</extensionElements>
</serviceTask>
		

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

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

public class SimpleCamelCallRoute extends RouteBuilder {

  @Override
  public void configure() throws Exception {

	  from("activiti:SimpleCamelCallProcess:simpleCall").to("log: org.activiti.camel.examples.SimpleCamelCall");
  }
}

<process id="SimpleCamelCallProcess">
        <startEvent id="start"/>
        <sequenceFlow id="flow1" sourceRef="start" targetRef="simpleCall"/>
		
        <serviceTask id="simpleCall" activiti:type="camel"/>
		
        <sequenceFlow id="flow2" sourceRef="simpleCall" targetRef="end"/>
        <endEvent id="end"/>
</process>
          

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

@Deployment
public void testPingPong() {
  Map<String, Object> variables = new HashMap<String, Object>();

  variables.put("input", "Hello");
  Map<String, String> outputMap = new HashMap<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返回的结果。流程应该像是这样：

<process id="PingPongProcess">
  <startEvent id="start"/>
  <sequenceFlow id="flow1" sourceRef="start" targetRef="ping"/>
  <serviceTask id="ping" activiti:type="camel"/>
  <sequenceFlow id="flow2" sourceRef="ping" targetRef="saveOutput"/>
  <serviceTask id="saveOutput"  activiti:class="org.activiti.camel.examples.pingPong.SaveOutput" />
  <sequenceFlow id="flow3" sourceRef="saveOutput" targetRef="end"/>
  <endEvent id="end"/>
</process>
    

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

<serviceTask id="serviceTask1" activiti:type="camel">
  <extensionElements>
    <activiti:field name="camelBehaviorClass" stringValue="org.activiti.camel.impl.CamelBehaviorCamelBodyImpl" />
  </extensionElements>
</serviceTask>
	

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

@Override
public void configure() throws Exception {
  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属性来启用这个功能。

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

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

<receiveTask id="receiveAsyncPing" name="Wait State" />
		

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

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

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

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

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

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

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

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

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

<receiveTask id="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'。

<serviceTask id="shellEcho" activiti:type="shell">
		      

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

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

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