事件

根据事件在流程中的位置，可分为：

所有事件在图中都显示为一个圆圈，圆圈线的类型（单线、双线、粗线） 表示事件在流程中的不同位置（启动、中间、结束）。

下面 XML 中是上图事件的一个示例：

在 BPMN 流程中，通过事件触发器指定某个事件应当在何时发生。 BPMN 中常用的几种事件触发器包括：

触发器可以手动或通过 API 调用激活。

在 BPMN 2.0 中，存在两个主要事件类别：catching 和 throwing 事件。

示例，请参考下面的捕获和抛出信号事件：

边界事件是捕获（型）事件，依附于活动（任务、嵌入的子流程或调用活动）。 可以是附着在活动上的多个事件。 边界事件总是捕获事件，无法被抛出。

在 XML 中，边界事件由特殊标签标记，具有 attachedToRef 属性，执行依附的活动：

该事件可以中断正常的流程执行。 适用于事件子流程中的边界事件和启动事件。

中断事件在图中展示为一个常规的过程中事件，依附于活动（任务或子流程）， 而非中断事件的边线为虚线。

非中断事件可以触发多次，每次都会开启一个新的流程执行（生成新令牌），直到任务完成。 例如，非中断循环计时器每 5 分钟触发一次，并向用户发送通知。

行为类型由 cancelActivity 属性定义。 默认设置为 true，对于中断事件，可以省略该属性的配置。 对于非中断事件，需要显式设置为 false。

示例，非中断定时器事件：

从技术上讲，空启动事件表示未指定用于启动该流程实例的触发器。 也就是说，引擎无法猜测该流程实例何时启动。

空启动事件通过没有内部图标（即，没有触发类型）的圆圈表示。

空启动事件用两个特殊的属性：

可以通过单击 BPMN Inspector 面板中的 create 链接来定义启动事件中的流程变量：

输入变量名并按回车：

默认情况下，新变量使用 String 类型创建，也可以将其类型更改为所需的类型。

如果在表单之前创建了流程变量，则会在表单中添加这些变量。

关于 表单 的配置，请参阅 流程表单 部分。

空启动事件的 XML 表示形式是一个常规的启动事件声明，但没有任何子元素。 （其他启动事件类型都有一个声明类型的子元素）。

中间空事件（Intermediate none events） 可用于表示流程中达到的某些状态。 引擎本身在事件中不做任何事情，只是穿过该事件继续行进。

中间空事件在图中展示为双线且没有内部图标（即，没有触发器类型）的圆圈。

中间空事件无特定属性

中间空事件的 XML 是使用 intermediateThrowEvent 定义的事件声明，没有任何子元素。

空结束事件（none end event） 是一种结束事件，表示流程完成，但没有任何特定输出或结果。 不会触发流程中的任何后续活动或流。

空结束事件在图中展示为粗线且没有内部图标的圆圈。

空结束事件无特定属性

定时器启动事件 用来在特定时间创建流程实例。 可用于仅启动一次或按特定时间间隔启动的流程。

定时器启动事件在图中展示为内部有时钟图标的圆圈。

定时器启动事件有一个特殊的 Timer Definition 属性，用于定义其类型和表达式。 参阅 定时器类型。

定时器启动事件的 XML 是一个常规的启动事件声明，带有定义定时器的子元素。 有关配置的详细信息，请参阅定时器定义。

定时器中间事件（Timer intermediate event） 可以作为秒表。执行到该事件时，将启动定时器。 当定时器在指定的时间间隔或指定的时间到达后触发时，流程将继续。

定时器中间事件是一个 等待状态。

定时器中间事件在图中展示为中间捕获事件，内部有一个定时器图标。

定时器中间事件的属性与定时器启动事件一样。

定时器中间事件的 XML 定义是中间捕获事件。 此时，其表示类型的子元素是 timerEventDefinition。

系统支持以下三种定时器：

设置定时器的时间参数有两种方式：

消息启动事件（message start event） 可使用命名消息启动流程实例。

消息启动事件在图中显示为带有消息事件符号的圆圈。 如果符号未填充，则表示捕获 （接收） 行为。

消息启动事件必须具有 Message 属性，指向已有的 消息定义。这是必须的，否则会导致部署错误。

消息启动事件的 XML 表示是带有 messageEventDefinition 子元素的普通启动事件：

消息中间捕获事件（intermediate catching message event） 使用特定的名称捕获消息。

中间捕获消息事件在图中展示为典型的中间事件（双线的圆圈），内部有消息图标。消息图标未填充表示“捕获”。

消息中间捕获事件与消息启动事件的属性相同。

消息中间事件在 XML 中定义为中间捕获事件。 此时，其表示类型的子元素是 messageEventDefinition。

当流程进入中间消息捕获事件时，将创建相应的消息订阅。 流程实例会在这里停止并等待，直到收到消息。 之后，捕获事件完成，流程继续执行。

消息中间捕获事件是一个 等待状态。 在下面的示例中，刘成刚将在 Activity 1 完成后等待消息，在收到消息后执行 Activity 2。

信号启动事件（signal start event） 可以使用一个命名的 信号定义 启动流程实例。 流程可以有一个或多个信号启动事件，但信号定义必须不同。

信号启动事件在图中显示为带有信号事件符号的圆圈。如果符号未填充，则表示捕获 （接收） 行为。

信号启动事件具有 Signal 属性，指向特定的信号定义。这个是必需属性，否则会导致部署错误。

信号启动事件的 XML 表示是带有 signalEventDefinition 子元素的普通启动事件：

信号中间捕获事件（Signal intermediate catching event） 捕捉 订阅 的同名信号。 信号中间捕获事件是一个 等待状态。

信号中间捕获事件在图中展示为典型的中间事件（双线的圆圈），内部有信号图标。 图标未填充表示“捕获”。

信号中间捕获事件与信号启动事件的属性相同。

信号中间抛出事件（intermediate throwing signal event） 会抛出一个信号事件。 抛出的信号会广播至所有的捕获信号事件，包括启动和中间信号 订阅。

信号中间抛出事件在图中展示为典型的中间事件（双线的圆圈）， 内部有信号图标。 图标已填充表示“抛出”。

中间信号捕获事件属性与信号启动事件相同， 但语义不同 — 是抛出，而不是捕获。

错误启动事件（error start event） 可用于触发 事件子流程。 不能用于启动流程实例。错误启动事件是中断的（类型）。

错误启动事件在图中展示为带有错误事件符号的圆圈。如果符号未填充，则表示捕获 （接收） 行为。

错误启动事件有一个特殊的属性 — Error，引用某些 错误定义。

与消息和信号不同，错误定义不是必须设置。 如果没有设置错误定义，则发生的每个错误事件都可以启动子流程。

错误启动事件的 XML 表示是带有 errorEventDefinition 子元素的常规启动事件声明：

错误边界事件（error boundary event） 可以捕获在依附的活动范围内抛出的错误。

错误边界事件在图中显示为边界上的中间事件（双线的圆圈）， 内部有错误图标。 错误图标未填充以表示“捕获”（型）。

错误边界事件与错误启动事件具有相同的属性。

当流程执行到 错误结束事件（error end event） 时，当前流程路径将结束并抛出错误。

错误结束事件在图中显示为典型的结束事件（粗线的圆圈），内部有错误图标。 错误图标已填充表示“抛出”。

错误结束事件有一个特殊的属性 — Error，该属性非必需。 如果设置，则需要引用某些已存在的 错误定义。

错误结束事件在 XML 以结束事件表示，带 errorEventDefinition 子元素。

补偿中间抛出事件（Compensation intermediate throwing event） 可用于触发补偿。

补偿边界事件（Compensation boundary event） 可用于将补偿处理逻辑依附至活动。

补偿边界事件必须有方向地关联单个补偿处理逻辑。

补偿边界事件具有与其他边界事件不同的激活策略。 其他边界事件（比如信号边界事件）在所依附的活动启动时被激活。 活动完成后，这些边界事件将被禁用，并取消相应的事件订阅。

而补偿边界事件则不同。 补偿边界事件在所依附的活动成功完成时激活。 此时，才创建补偿事件的相应订阅。 当触发补偿事件或对应的流程实例结束时，删除订阅。 因此，其逻辑如下：

补偿边界事件在图中显示为边界上的典型中间事件（双线圆圈），内部有补偿图标。补偿图标未填充以表示“捕获”。 除了补偿边界事件之外，下图显示了补偿处理逻辑与边界事件的单向关联。

补偿边界事件必须有向关联至单一补偿处理逻辑。

补偿边界事件在 XML 中定义为典型的边界事件：

取消结束事件（cancel end event） 只能与 BPMN 事务子流程 结合使用。当流程到达取消结束事件事件时，将抛出一个取消事件，该事件必须由取消边界事件捕获。然后，取消边界事件取消当前事务并触发补偿。

取消结束事件在图中显示为典型的结束事件（粗线圆圈），内部带有取消图标。取消图标完全为黑色，表示“抛出”。

取消结束事件在 XML 中表示为带 cancelEventDefinition 子元素的结束事件。

一个依附在事务子流程边界的 中间捕获取消事件（intermediate catching cancel event），简称 取消边界事件（boundary cancel event），当事务被取消时触发。

当触发取消边界事件时，首先会中断当前范围内的所有激活的执行分支。 然后，为事务范围内的所有激活的补偿边界事件启动补偿。

补偿是同步执行的，边界事件在离开事务之前会等待补偿完成。 当补偿完成时，使用取消边界事件的出口顺序流，离开事务子流程。

取消边界事件，用内部有一个取消图标的标准中间事件（双线圆圈）表示。取消图标是白色的（未填充），代表“捕获”。

取消边界事件的 XML 定义为一个典型的边界事件：

由于取消边界事件是中断的，因此 cancelActivity 属性不是必需。

在这个示例中，我们可以看到并行执行的两个用户任务。 如果任务 #2 首先完成，则执行将到达终止结束事件。 此时，任务 #1 将被删除，即使仍然处于活动状态。

在下一个示例中，终止结束事件位于子流程中。当达到时，仅影响子流程。 因此，如果任务 #1 处于活动状态，则将被删除，子流程将被终止，主流程则以正常方式继续。

首先，在建模中，尽量使用 信号 代替 消息。多数情况下，这两种事件可以互换。

然后，使用服务任务调用 API。

服务任务可以实现为 Spring bean，示例：

使用 信号抛出中间事件 和 空结束事件 的组合替换：

在某些情况下，可以使用 BPMN 错误事件替代升级事件（escalation events）。 BPMN 中的错误事件用于处理流程执行期间发生的错误或异常。 可用于对流程中的错误处理和恢复机制进行建模。

另一方面，升级事件用于将问题上报到组织或流程层次结构中的更高级别。 当问题无法在当前级别解决并且需要升级以采取进一步措施时，通常会使用升级事件。

因此，升级事件在技术上非常接近错误事件。

条件事件定义当给定的条件计算结果为 true 时会触发的事件。 可以用作事件子流程的启动事件，也可以用作中间事件和边界事件。 启动和边界事件可以是中断或非中断。

可以将信号或消息事件与执行监听器结合使用实现类似的逻辑。

不要使用连接事件。