Activiti7 之BPMN2.0介绍（二）

BPMN2.0相对于BPMN1.0最大的区别就是定义、规范了流程引擎的执行语义和格式，利用标准的图元描述真实的业务发生过程，保证相同的流程在不同的流程引擎中得到一致的执行结果。在2.0的这套标准中，主要对流程执行定义了三类基本要素，分别为Activities（活动）、Gateways（网关）、Events（事件）。

1 开始事件

1.1 StartEvent(空开始事件)

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

ProcessInstance processInstance = runtimeService.startProcessInstanceByXXX();

1.2 TimerStartEvent(定时开始事件)

定时开始事件用来在指定的时间创建流程实例。 它可以同时用于只启动一次的流程 和应该在特定时间间隔启动多次的流程，子流程不能使用定时开始事件，定时开始事件在流程发布后就会开始计算时间。 不需要调用startProcessInstanceByXXX，当包含定时开始事件的新版本流程部署时， 对应的上一个定时器就会被删除。

其中timeDuration是指定定时器之前要等待多长时间；timeDate是使用 ISO 8601 格式指定一个确定的时间，触发事件的时间；timeCycle指定重复执行的间隔， 可以用来定期启动流程实例，或为超时时间发送多个提醒。

1.3 MessageStartEvent(消息开始事件)

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

注意：

• 消息开始事件的名称在给定流程定义中不能重复。流程定义不能包含多个名称相同的消息开始事件。 如果两个或以上消息开始事件应用了相同的事件，或两个或以上消息事件引用的消息名称相同，activiti会在发布流程定义时抛出异常。
• 消息开始事件的名称在所有已发布的流程定义中不能重复。 如果一个或多个消息开始事件引用了相同名称的消息，而这个消息开始事件已经部署到不同的流程定义中， activiti就会在发布时抛出一个异常。
• 流程版本：在发布新版本的流程定义时，之前订阅的消息订阅会被取消。 如果新版本中没有消息事件也会这样处理。
  流程实例启动，消息开始事件可以使用 下列RuntimeService中的方法来触发：

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

1.4 ErrorStartEvent(错误开始事件)

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

1.5 SignalStartEvent(信号开始事件)

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

2 结束事件

2.1 EndEvent(空结束事件)

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

2.2 ErrorEndEvent(错误结束事件)

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

2.3 TerminateEndEvent(终止结束事件)

终止结束事件表示为结束事件，具有terminateEventDefinition子元素。terminateAll属性是可选的，默认情况下为false。可以添加可选属性terminateAll。如果为true，则无论在流程定义中是否放置终止结束事件，并且无论是否处于子流程（甚至是嵌套）、（根）流程实例都将终止。

2.4 CancelEndEvent(取消结束事件)

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

3 边界事件

关于边界事件，都是捕获事件，它会附在一个环节上，边界事件不可能触发事件，这意味着，当节点运行时， 事件会监听对应的触发类型。 当事件被捕获，节点就会中断， 同时执行事件的后续连线。

3.1 TimerBoundaryEvent(定时边界事件)

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

3.2 ErrorBoundaryEvent(错误边界事件)

节点边界上的中间捕获错误事件， 或简写成边界错误事件， 它会捕获节点范围内抛出的错误。定义一个边界错误事件，大多用于内嵌子流程， 或调用节点，对于子流程的情况，它会为所有内部的节点创建一个作用范围。 错误是由错误结束事件抛出的。 这个错误会传递给上层作用域，直到找到一个错误事件定义向匹配的边界错误事件。当捕获了错误事件时，边界任务绑定的节点就会销毁， 也会销毁内部所有的执行分支 （比如，同步节点，内嵌子流程，等等）。 流程执行会继续沿着边界事件的外出连线继续执行。

3.3 MessageBoundaryEvent(消息边界事件)

边界消息事件，根据引用的消息定义捕获相同消息名称的消息。

3.4 CancelBoundaryEvent(取消边界事件)

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

3.5 CompensationBoundaryEvent(补偿边界事件)

节点边界的中间捕获补偿， 或简称为补偿边界事件， 可以用来设置一个节点的补偿处理器。补偿边界事件必须使用直接引用设置唯一的补偿处理器。补偿边界事件与其他边界事件的策略不同。 其他边界事件（比如信号边界事件）当到达关联的节点就会被激活。 离开节点时，就会挂起，对应的事件订阅也会取消。 补偿边界事件则不同。补偿边界事件在关联的节点成功完成时激活。 当补偿事件触发或对应流程实例结束时，事件订阅才会删除。

3.6 SignalBoundaryEvent(信号边界事件)

信号边界事件， 它会捕获信号定义引用的相同信号名的信号。与其他事件（比如边界错误事件）不同，边界信号事件不只捕获 它绑定方位的信号。信号事件是一个全局的范围（广播语义），就是说信号可以在任何地方触发， 即便是不同的流程实例。捕获信号后，不会停止信号的传播。 如果你有两个信号边界事件，它们捕获相同的信号事件，两个边界事件都会被触发， 即使它们在不同的流程实例中。

4 中间捕获/触发事件

4.1 TimerCatchingEvent(定时中间捕获事件)

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

4.2 SignalCatchingEvent(信号中间捕获事件)

中间捕获信号事件 通过引用信号定义来捕获相同信号名称的信号。与其他事件（比如错误事件）不同，信号不会在捕获之后被消费。 如果你有两个激活的信号边界事件捕获相同的信号事件，两个边界事件都会被触发， 即便它们在不同的流程实例中。

4.3 MessageCatchingEvent(消息中间捕获事件)

捕获特定名称的消息。

4.4 SignalThrowingEvent(信号中间触发事件)

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

4.5 CompensationThrowingEvent(补偿中间触发事件)

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

4.6 NoneThrowingEvent(中间触发空事件)

该事件通常用于指示过程中达到的某些状态。

5 任务

在工作流Activiti的使用中，任务是不可或缺的元素，通过各种任务，来完成作业系统中各个环节的执行，任务分为用户任务、脚本任务、Java服务任务、邮件任务、手工任务、业务规则任务、调用活动（子流程）任务，下面就一一介绍。

5.1 用户任务

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

5.2 脚本任务

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

5.3 Java服务任务

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

5.4 邮件任务

activiti强化了业务流程，支持了自动邮件任务，它可以发送邮件给一个或多个参与者， 包括支持cc, bcc, HTML内容等等。activiti引擎要通过支持SMTP功能的外部邮件服务器发送邮件。 为了实际发送邮件，引擎需知道如何访问邮件服务器。在activiti.cfg.xml配置文件中配置：

mailServerHost—邮件服务器的主机名

mailServerPort—邮件服务器上的SMTP传输端口。默认为25

mailServerDefaultFrom—如果用户没有指定发送邮件的邮件地址，默认设置的发送者的邮件地址。

mailServerUsername—邮件服务器认证用户名

mailServerPassword—邮件服务器认证密码

mailServerUseSSL—ssl交互。默认为false

mailServerUseTLS—是否需要支持TLS。默认为false。

5.5 手工任务

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

5.6 接收任务

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

5.7 业务规则任务

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

5.8 调用活动（子流程）任务

调用节点引用流程定义外部的一个流程，使用调用节点的主要场景是需要重用流程定义， 这个流程定义需要被很多其他流程定义调用的时候。当流程执行到调用节点，会创建一个新分支，它是到达调用节点的流程的分支。 这个分支会用来执行子流程，默认创建并行子流程，就像一个普通的流程。 上级流程会等待子流程完成，然后才会继续向下执行。

6 网关

网关用来控制流程的流向， 网关可以消费也可以生成token。网关显示成菱形图形，内部有有一个小图标。 图标表示网关的类型。

6.1 并行网关

网关也可以表示流程中的并行情况。并行网关允许将流程分成多条分支，也可以把多条分支汇聚到一起。并行网关的功能是基于进入和外出的顺序流的：

• 分支： 并行后的所有外出顺序流，为每个顺序流都创建一个并发分支。

• 汇聚： 所有到达并行网关，在此等待的进入分支， 直到所有进入顺序流的分支都到达以后， 流程就会通过汇聚网关。

如果同一个并行网关有多个进入和多个外出顺序流， 它就同时具有分支和汇聚功能。 这时，网关会先汇聚所有进入的顺序流，然后再切分成多个并行分支。与其他网关的主要区别是，并行网关不会解析条件。 即使顺序流中定义了条件，也会被忽略。

6.2 排他网关

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

6.3 包含网关

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

• 分支： 所有外出顺序流的条件都会被解析，结果为true的顺序流会以并行方式继续执行， 会为每个顺序流创建一个分支。

• 汇聚： 所有并行分支到达包含网关，会进入等待， 直到每个包含流程token的进入顺序流的分支都到达。 这是与并行网关的最大不同。包含网关只会等待被选中执行了的进入顺序流。 在汇聚之后，流程会穿过包含网关继续执行。

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

6.4 基于事件网关

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

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

• 基于事件网关必须有两条或以上外出顺序流。
• 基于事件网关后，只能使用intermediateCatchEvent类型。 （activiti不支持基于事件网关后连接ReceiveTask。）
• 连接到基于事件网关的intermediateCatchEvent只能有一条进入顺序流。