Camunda 8 概念详解：梳理新一代工作流引擎的核心概念与组件

1 Camunda 8 简介

Camunda 8 将强大的 BPMN 流程和 DMN 决策执行引擎与协作建模、运维和分析工具相结合。Camunda 8 的各个组件协同工作，共同构成完整的 Camunda 8 体验，使您能够设计、自动化和改进业务流程。

借助 Camunda 8，您可以对复杂的业务流程进行端到端的建模、执行和操作。

1.1 核心组件

Modeler：设计完全可执行的流程和决策模型，减少不匹配和交接摩擦，同时赋予工程师构建正确解决方案所需的自由度。Camunda Modeler 为业务用户提供了一种直观的方式，可以使用 BPMN 和 DMN 标准对流程和决策进行建模，从而确保其意图清晰、结构化，并可供开发人员直接使用。开发人员可以直接使用模型构建可扩展、灵活的解决方案，而无需担心与业务意图脱节。
Connectors：连接器可与任何系统或技术通信，从而缩短自动化和编排业务流程所需的时间。出站连接器触发 Camunda 外部的事件，而入站连接器则允许在 Camunda 上运行的进程接收来自外部系统的消息。连接器还可用作 AI 代理的工具层，使代理能够以受控且可重用的方式与外部系统交互。
AI agents：构建具有安全防护措施[的企业级 AI 代理，使其能够自主解决复杂问题。Camunda 实现了代理 BPMN，使团队能够在统一且可执行的模型中对确定性流程逻辑和动态代理行为（例如推理循环、内存、提示、红黄绿灯系统和人机交互边界）进行建模。
Forms ：某些自动化流程需要人工参与和交互。创建并实施自定义表单，用于提供工作指令、收集信息，并帮助人们决定需要完成的任务。
TaskList：提供轻量级、用户友好的界面，方便用户进行人工操作，并与自定义表单紧密集成。它提供开箱即用的任务用户界面，使团队能够快速迭代流程开发，而无需构建自定义前端应用程序。
Workflow and decision engine ：Zeebe 是一款分布式工作流和决策引擎，它用事件流式消息架构取代了传统的关联数据库。这种方法消除了数据库瓶颈，确保了横向扩展性，并提供了内置的弹性。

1.2 抽象概念

流程实例 ：流程实例是流程定义的一次具体执行，由唯一的 processInstanceKey 标识，代表一个业务流程从开始到结束的完整运行过程；流程实例的有效载荷限制为 4 MB。此限制包括流程变量和工作流引擎内部数据，因此仅变量可用的空间不足 4 MB。不建议在流程上下文中存储大量数据
任务：任务是 BPMN 流程中的基本构建单元，例如服务任务（Service Task）、用户任务（User Task）等。当流程实例的执行 token 到达某个任务时，Zeebe 引擎会为该任务创建一个作业（Job），然后等待作业完成后才继续推进流程。
作业：作业是任务被激活时由 Zeebe 创建的工作单元；它有以下关键属性：
- Type（类型）：用于匹配能处理该作业的工作者。
- Key（唯一键）：用于提交结果或报告失败。
- Variables（变量）：流程实例的上下文数据。
只要作业未完成，Zeebe 就不会推进流程到下一步。
Job Woker ：作业工作者是实现具体业务逻辑并处理作业的服务。它通过轮询（polling）或流式推送（job streaming）方式从 Zeebe 获取特定类型的作业，执行完毕后向 Zeebe 发送 complete（完成）或 fail（失败）命令。多个工作者可以订阅同一类型的作业以实现水平扩展。
Job Executor Thread ：**作业线程是作业工作者内部用于并发执行作业的线程池。**默认线程数为 1，可通过配置增加：
yaml 复制代码
```
camunda:
  client:
    execution-threads: 2
```
线程数决定了单个工作者能同时处理的最大并发作业数量。

2 公共概念

2.1 变量

（1）变量名

变量名可以是任何包含下划线符号 _ 的字母数字字符串 ，推荐使用 Snake_case，不允许使用三叉戟式命名法 kebab-case 因为它包含连字符 - ，在表达式中访问变量时，请记住变量名区分大小写。

限制：

它不能以数字开头（例如，不允许使用 1stChoice ；您可以改用 firstChoice ）。
它不能包含空格（例如，不允许使用 order number ；您可以改用 orderNumber ）。
它可能不包含运算符 （例如 + 、 - 、 * 、 / 、 = 、 > 、 ? 、 . ）。
它不能是字面值 （例如 null 、 true 、 false ）或关键字 （例如 function 、 if 、 then 、 else 、 for 、 between 、 instance 、 of 、 not ）。

（2）变量值

变量的值以 JSON 值的形式存储，可用类型如下：

字符串（例如 "John Doe" ）
数字 0.23 例如 123 ）
布尔值（例如 true 或 false ）
数组（例如 ["item1" , "item2", "item3"] ）
对象（例如 { "orderNumber": "A12BH98", "date": "2020-10-15", "amount": 185.34} ）
空（ null ）

整数实际上仅限于 64 位整数范围；非整数数以 IEEE-754 双精度值存储，提供大约 15-17 位有效十进制数字，而不是任意的 BigDecimal 精度；如果需要任意精度或非常大的数字，请考虑将它们存储为字符串或外部数据存储，而不是存储为进程变量。

（3）变量作用域

变量作用域定义了变量的可见性 。根作用域是流程实例本身。此作用域中的变量在整个流程中都可见。

当流程实例进入子流程或活动时，会创建一个新的作用域。此作用域内的活动可以观察此作用域及其上级作用域（即父作用域）的所有变量。但是，此作用域之外的活动无法观察此作用域中定义的变量。

如果一个变量与更高作用域中的变量同名，则该变量会被覆盖。此作用域中的活动只会观察此变量的值，而不会观察更高作用域中的变量的值。

当变量合并到流程实例中时（例如，在作业完成时、在消息关联时等），每个变量都会从活动的范围传播到其更高的范围。

2.2 执行监听器

执行监听器 (EL) 允许用户通过执行自定义逻辑来对工作流执行生命周期中的各种事件做出反应；可以使用执行监听器来提供对流程执行的灵活性和控制，并处理复杂的数据和外部系统交互，而不会使 BPMN 模型充斥着技术细节。

常见场景：

Task 的前置处理和后置处理。
元素表达式的变量外部计算。
解耦进程和数据同步。

Executor Listener 是一个阻塞操作，这意味着工作流的执行生命周期只有在监听器完成后才会继续。这确保了监听器定义的所有必要的预处理和后处理操作在工作流继续执行下一个环节之前都已完全执行完毕。

Executor Listener有两种类型：

开始： 在元素处理之前调用。可用于设置变量或执行前提条件。
结束： 在元素处理完毕后调用。可用于执行清理或后处理任务。

Executor Listener 有三个属性：

eventType：指定 Executor Listener 的类型。

3 Task

业务流程模型和符号（BPMN） 是一种用于表示复杂流程的图形化符号；业务流程模型和符号 (BPMN) 是全球流程建模标准。

BPMN 流程的基本元素是任务；这些任务是构成有意义结果的原子工作单元。当一个令牌到达一个任务时，该令牌会停止，Zeebe 会创建一个作业并通知已注册的工作进程来执行该作业。当该作业处理程序发出完成信号时，令牌会继续沿输出序列流进行处理。

3.1 Task Service

服务任务代表流程中具有特定类型的工作项；当输入服务任务时，系统会创建一个相应的作业。流程实例会在此处停止，并等待作业完成。

3.1.1 Task Definition

服务任务必须具有 taskDefinition 用于指定哪些作业工作线程taskDefinition 服务任务的工作。

taskDefinition 指定一下属性：

type（必须）：用作参考，指定哪些作业工作者请求相应的服务任务作业。type 可以是任何静态值，也可以指定以=为前缀的 FEEL 表达式，该表达式计算结果为任何 FEEL 字符串，例如：="order-" + priorityGroup。
Retries（可选）：指定工作进程指定工作线程执行任务失败时的重试次数。

服务任务可以定义任意数量的 taskHeaders ；这些任务头是静态元数据，会随任务一起传递给工作进程。任务头可以用作工作进程的配置参数。

3.1.3 Variable Mapping

变量映射在 TaskService 中主要分为两类：Input Mapping 和 Output Mapping。

默认情况下，所有作业变量都会合并到流程实例中。可以通过在服务任务中定义输出映射来自定义此行为。

输入映射可用于将变量转换为作业程序可接受的格式，变量是流程实例的一部分，代表该实例的数据；变量包含一个名称和一个 JSON 值。变量的可见性由其变量作用域决定。

输入/输出变量映射可用于创建新变量或自定义变量如何合并到流程实例中。

输入映射可用于创建新变量。它们可以定义在服务任务、脚本任务、业务规则任务、调用活动、用户任务、发送任务和子流程中。
输出映射可用于多种用途：
- 自定义变量如何合并到流程实例中。
- 它们可以定义在服务任务、接收任务、消息捕获事件和子进程中。
- 它们可用于脚本任务和用户任务。
如果定义了一个或多个 输出映射，则结果变量会被设置为映射定义作用域内的局部变量 。然后，输出映射会应用于这些变量，并在该作用域内创建新变量。这些新变量会被合并到父作用域中。如果作业/消息变量没有对应的映射，则该变量不会被合并。

3.2 User Task

用户任务用于模拟需要由人完成的工作，并由工作流引擎或软件应用程序辅助完成。这与手动任务不同，手动任务不需要外部工具的辅助。当流程实例到达用户任务时，Zeebe 会创建一个新的用户任务实例。流程实例会在此暂停，等待该用户任务实例完成。用户任务实例完成后，流程实例才会继续执行。

3.2.1 Assignments

用户任务支持使用 zeebe:AssignmentDefinition 扩展元素指定任务分配。这可用于定义任务可以分配给哪个用户。可以同时指定以下一个或多个属性：
- Assignee：指定分配给该任务的用户。任务列表将为该用户认领该任务。
- candidateUsers：指定可以分配任务的用户。
- candidateGroups：指定可以分配任务的用户组。
用户任务支持使用 zeebe:taskSchedule 扩展元素指定任务计划。这可用于定义用户何时与特定任务进行交互。可以同时指定以下一个或两个属性：
- dueDate：指定用户任务的截止日期。
- followUpdate：指定用户任务的后续日期。

可以使用 followUpDate 定义用户开始处理任务的最晚时间，然后使用 dueDate 提供用户完成任务的截止日期。

可以使用 zeebe:priorityDefinition 扩展元素来指定用户任务的优先级。优先级必须是介于 0 和 100 之间的整数。如果未提供值，则默认值为 50，优先级数值越高，表示重要性越高。

3.2.2 Variable Mapping

默认情况下，所有 Camunda 用户任务变量都会合并到流程实例中。可以通过在用户任务中定义输出映射来自定义此行为。

输入映射可用于将变量转换为不同的格式。

3.2.3 Forms

用户任务通常包含一个表单。表单包含用户的操作说明，并以结构化的方式记录最终结果信息。

然而，用户任务并不局限于表单。用户任务还可以用于引导用户访问其他应用程序或将他们重定向到网站。

Camunda Forms：提供了一种灵活的方式，可以通过表单 ID 将用户任务链接到 Camunda 表单。以这种方式链接的表单可以与引用的流程模型一起部署，属性如下：
- formId：表单 ID。
- bindingType：属性决定使用哪个版本的链接表单。
  - Latest：用户任务激活时部署的最新版本。
  - Deployment：与当前正在运行的版本一起部署的版本。
  - versionTag：最近部署的版本，前提条件是版本使用 versionTag 进行了标注。
  如果未指定 bindingType 属性，则默认使用 latest 。
External Form Reference

不常用，跳过。

用户任务可以定义任意数量的 taskHeaders ；这些任务头是静态元数据，与用户任务一起存储在 Zeebe 中。任务头可用作任务列表应用程序的配置参数。

3.2.5 Task Listener

用户任务支持用户任务监听器，允许您对用户任务生命周期事件做出反应。

taskListener 的每个元素需要指定以下属性：

eventType（必须）：监听器监听的事件类型，取值如下：creating、assigning、updating、completing、canceling.
Type（必须）：指定哪些作业工作进程请求相应的任务监听器作业。
Retries：重试次数。

Task Listener 会由 Zeebe 基于 Task 创建 Job实例时被执行。

3.2.6 Implementation

用户任务不一定需要由 Zeebe 管理。您可以使用 Job worker 实现自定义用户任务逻辑。要为用户任务定义 Job worker 实现，只需从任务中移除 zeebe:userTask 扩展元素即可。通过 Job worker 实现的用户任务与服务任务的行为类似，但有两个主要区别：

视觉表现：视觉标记区分用户任务和服务任务。
模型语义：过程模型中的解释和目的各不相同。

Job Worker 已经被弃用，推荐使用 Camunda User Task 来获得强大的功能和良好的实现。

3.3 Receive Task

接收任务引用消息；这些任务用于等待直到收到正确的消息。

当接收任务时，系统会创建一个相应的消息订阅。此时，进程实例会停止并等待消息关联完成。

Global Message Reference：该 ReceiveTask 监听哪条消息。
Name：消息的名称，发布时必须完全匹配。
Subscription Correlation：用哪个变量的值来找到对应的流程实例； Zeebe 的匹配规则：messageName 相同且 correlationKey 值等于实例中 ticket_id 变量的值 → 命中该实例。

3.3.1 Message

一条消息可以被一个或多个接收任务引用；它必须定义消息的名称，一条消息包含一下两个属性：

Name：消息的名称。
Subscription Correlation key：是一个表达式，通常用于访问进程实例中保存消息关联键的变量。该表达式在激活接收任务时进行求值，且结果必须为 string 或 number 。

3.4 Send Task

发送任务的行为与服务任务完全相同，发送任务用于模拟向外部系统发布消息。这两种任务类型都基于作业和作业工作者。它们之间的区别在于视觉表示（即任务标记）和模型的语义。

3.4.1 Task Definition

发送任务必须像服务任务一样定义作业类型。它指定工作进程应该订阅的作业类型。

taskDefinition 指定一下属性：

type（必须）：用作参考，指定哪些作业工作者请求相应的服务任务作业。type 可以是任何静态值，也可以指定以=为前缀的 FEEL 表达式，该表达式计算结果为任何 FEEL 字符串，例如：="order-" + priorityGroup。
Retries（可选）：指定工作进程指定工作线程执行任务失败时的重试次数。

3.5 Business Rule Task

将复杂的业务决策逻辑从流程代码中解耦出来，交由 DMN (Decision Model and Notation) 引擎自动执行。它允许你在 BPMN 流程图中直接嵌入一个"决策表"，流程运行到该节点时，会自动输入数据、计算规则、输出结果。

3.5.1 Called Decision

在 Implementation 选择了 DMN decision 才能配置 Called Decision。

被调用的决策将业务规则任务链接到 DMN 决策，可以是链接到决策表，也可以是链接到决策表达式；参数如下：

Decision ID：DMN 的 decisionID。
Binding：被调用 DMN 的版本：
- latest：业务规则任务激活时最新部署的版本。
- Deployment：与当前正在运行的进程版本一起部署的版本。
- vertionTag：最新部署的版本，该版本已使用 versionTag 属性中指定的版本标签进行注释。
ResultVariable：业务规则任务必须将决策结果的流程变量名称定义为 resultVariable 。决策结果存储在此 resultVariable 中。默认情况下， resultVariable 定义的变量会合并到流程实例中。可以通过在业务规则任务中定义输出映射来自定义此行为。

3.5.2 Task Definition

在 Implementation 选择了 Job Worker 才能配置 Task Definition。

采用作业工作进程实现的业务规则任务与服务任务的行为完全相同。

3.6 Script Task

在流程引擎内部直接执行一段轻量级的代码片段（通常是 JavaScript），用于对流程变量进行简单的转换、计算或格式化，而无需启动外部的 Job Worker。

3.6.1 Script

在 Implementation 选择了 FEEL expression 才能配置 Script。参数如下：

result Variable：定义 FEEL 表达式，默认情况下， resultVariable 定义的变量会合并到流程实例中。可以通过在脚本任务中定义输出映射来自定义此行为。
FEEL expression：定义过程变量的名称。该变量将存储 FEEL 表达式求值的结果。

3.6.2 Task Definition

在 Implementation 选择了 Job Worker 才能配置 Task Definition。

采用作业工作进程实现的业务规则任务与服务任务的行为完全相同。

3.7 Manual Tasks

手动任务是指需要人为操作但无需外部工具或用户界面的任务。在引擎和 BPMN 模型中，手动任务被处理为传递活动，在流程实例到达时自动继续流程。

手动任务可以深入了解流程引擎之外执行的任务，有助于对流程进行建模，尽管没有使用任何关联的自动化流程。

4 Gateway

网关是能够以比普通序列流更复杂的模式路由令牌的元素；网关是能够以比普通序列流更复杂的模式路由令牌的元素。

Gateway 的判断变量在日常的使用中都是从流程实例中将流程变量取出来作为判断条件。

4.1 Exclusive Gateway

互斥网关（或 XOR 网关）允许您根据数据（即过程变量）做出决策。

如果一个互斥网关有多个出站顺序流，则除一个顺序流外，所有顺序流都必须具有一个 conditionExpression 来定义流的执行时机。该网关可以有一个没有 conditionExpression 的顺序流，该顺序流必须定义为默认流。当进入互斥网关时，将对 conditionExpression 进行求值。流程实例会采用第一个满足条件的顺序流程。

Gateway 的 conditionExpression 属性不在 Gateway 组件上，而是在 Gateway 流程线上。

conditionExpression 定义了何时执行某个流程。它是一个布尔表达式，可以访问流程变量并将其与字面值或其他变量进行比较。当表达式返回 true 时，条件满足。多个布尔值或比较可以组合成析取（ or ）或合取（ and ）。

javascript 复制代码

= totalPrice > 100
= order.customer = "Paul"
= orderCount > 15 or totalPrice > 50
= valid and orderCount > 0

4.2 Parallel Gateway

并行网关（或 AND 网关）允许您将数据流拆分为并发路径。不需要从流程实例中读取流程变量进行判断。

当接入具有多个出站顺序流的并行网关时，所有流都会被接入。这些路径会并发且独立地执行。

可以使用具有多个传入序列流的并行网关连接并发路径。进程实例在并行网关处等待，直到每个传入序列都被处理完毕。

4.3 Event-Based Gateway

基于事件的网关必须至少有两个出站序列流。每个序列流必须连接到类型为定时器的中间捕获事件。消息或信号。

当进入基于事件的网关时，流程实例会在网关处等待，直到某个事件被触发。当第一个事件被触发时，会执行该事件的输出序列流程。之后，网关的其他事件将无法被触发。

4.4 Inclusive Gateway

包容性网关（或 OR 网关）允许基于数据或过程变量做出多个决策。包容性网关可以是发散型（将顺序流程拆分为多条路径）或收敛型（在继续之前合并拆分的路径）。

如果一个包容性网关有多个出站顺序流，则所有顺序流都必须有一个条件来定义何时执行该流。如果包含网关只有一个出站顺序流，则不需要设置条件。

conditionExpression定义了何时执行某个流程。它是一个布尔表达式，可以访问流程变量并将其与字面值或其他变量进行比较。当表达式返回 true 时，条件满足。

多个布尔值或比较可以组合成析取（ and ）或合取（ or ）。

javascript 复制代码

= totalPrice > 100
= order.customer = "Paul"
= orderCount > 15 or totalPrice > 50
= valid and orderCount > 0
= list contains(courses, "salad")

5 Events

可以通过多种方式向流程中添加事件。事件不仅可以用来让令牌在特定点等待，还可以用来中断令牌的执行过程。事件可以捕获异常也可以抛出异常。

此外，还区分了开始事件、中间事件和结束事件：

开始事件 （捕获事件，因为它们只能对某些事情做出反应）用于表示过程或子过程的开始。
结束事件 （抛出事件，因为它们表明某些事情已经发生）用于表示特定序列流程的结束。
中间事件可以用来表示某事已经发生（即中间投掷事件），或者用来等待和对某些事件做出反应（即中间接球事件）。

中间捕获事件可以以两种不同的方式插入到您的流程中：正常流程或附加到活动，它们被称为边界事件。

边界事件提供了一种方法来模拟在活动进行期间发生事件时应该如何处理。例如，如果某个流程正在等待用户任务完成，但等待时间过长，则可以将一个中间计时器捕获事件附加到该任务，并设置一个指向通知任务的出站序列流，从而允许建模者自动向用户发送提醒邮件。

5.1 Message Event

消息事件是引用消息的事件；它们用于等待直到收到正确的消息。当单个进程实例需要等待来自辅助进程或外部系统的消息时，会使用消息事件。这是一种单发送单接收关系 (1:1)，因为消息不能有多个接收者。

（1）Message Start Event

一个进程可以有一个或多个消息启动事件（以及其他类型的启动事件）。每个消息事件都必须有一个唯一的消息名称。当流程部署时，它会为每个消息启动事件创建一个消息订阅。先前版本流程（基于 BPMN 流程 ID）的消息订阅将被关闭。

（2）Message Boundary Event

一个活动可以有一个或多个消息边界事件。每个消息事件都必须有一个唯一的消息名称。

当进入该活动时，它会为每个边界消息事件创建一个相应的消息订阅。如果触发了非中断边界事件，则活动不会终止，并且可以关联多条消息。

（3）Message Intermediate Throw Event

一个过程可以包含中间消息抛出事件或消息结束事件，以模拟向外部系统（例如 Kafka 主题）发布消息的过程。

中间消息抛出事件和消息结束事件的行为与服务任务或发送任务完全相同。并且具有相同的与工作相关的属性（例如工作类型、自定义标头等）。

5.2 Signal Event

信号事件是指引用某个信号的事件。广播一个信号会触发所有与该广播信号名称匹配的信号事件。

如果您需要与多个监听器通信，通常使用信号事件。对于中间事件，信号会触发所有持有相应捕获事件等待令牌的进程实例，即使这些实例位于不同的进程中。对于启动事件，信号会为每个具有相应启动信号的进程启动一个实例。

因此，信号形成了一个单发送方与多个接收方的关系。

（1）Signal Start Event

信号启动事件可用于启动进程实例。通过一次广播，即可利用信号启动事件部署多个进程，从而创建多个进程实例（广播信号会遍历所有可用的订阅。如果广播的信号名称与信号启动事件的名称匹配，则创建进程实例）。

信号订阅仅存在于流程定义的最新版本中。部署同一流程的新版本（基于 BPMN 流程 ID）将删除旧的信号订阅。系统会为新部署的流程定义创建一个新的订阅。删除流程的最新版本时，信号订阅也会被删除。如果同一流程的先前版本（基于 BPMN 流程 ID）包含信号启动事件，则会为其创建一个新的订阅。

（2）Signal Intermediate Catch Event

当进入信号中间捕获事件时，会创建一个信号订阅。进程实例此时停止，并等待同名广播信号触发。广播信号会遍历所有可用的订阅。如果广播信号的名称与信号订阅的名称匹配，则会触发该信号订阅。当订阅被触发时，相应的信号捕获事件完成，进程实例继续运行。

（3）Signal Boundary Event

一个活动可以有一个或多个信号边界事件。每个信号事件都必须有一个唯一的信号名称。当进入该活动时，它会为每个边界信号事件创建一个信号订阅。如果触发的是非中断型边界事件，则该活动不会终止，并且多个广播信号可以触发这些边界事件。

（4）Signal Throw Event

一个过程可以包含信号中间抛出事件或信号结束事件，以模拟信号的广播。当信号投掷事件被触发时，它会广播一个可以触发信号订阅的信号。

5.3 Timer Event

定时器事件是由设定的定时器触发的事件；一个进程可以有一个或多个定时器启动事件（以及其他类型的启动事件）。每个定时器事件都必须具有时间日期或时间周期定义。

当流程部署时，它会为每个计时器启动事件安排一个计时器。先前版本流程（基于 BPMN 流程 ID）的已安排计时器将被取消。

当定时器被触发时，会创建一个新的进程实例，并激活相应的定时器启动事件。

Timer Event 需要配置的属性为 timer，参数如下：

timer 可以定义为静态值（P3D），也可以定义为表达式，使用表达式有两种常见方式：

访问变量： =remainingTime
使用临时值：=date and time(exprationDate) - date and time(creationDate)

如果表达式属于流程的定时器启动事件，则在部署流程时进行评估。否则，在激活定时器捕获事件时进行评估。评估结果必须为与静态值具有相同 ISO 8601 格式的 string ，或等效的时间值（例如日期时间、持续时间或周期）。

5.3 Error Event

在流程自动化中，您经常会遇到与默认场景的偏差。解决这些偏差的一种方法是使用 BPMN 错误事件，它允许流程模型对任务中的错误做出反应。

例如，如果在以下过程中使用无效信用卡，则该过程将采取与通常不同的路径，并使用默认付款方式收款。

在 BPMN 中，错误定义了可能发生的错误。 错误事件是流程中的元素，用于引用已定义的错误。一个错误可以被一个或多个错误事件引用。

错误必须定义一个 errorCode 。此 errorCode 的值用于确定哪个 catch 事件可以捕获抛出的错误。

对于错误抛出事件，可以将 errorCode 定义为 expression 或静态值。如果配置了 errorCode 表达式，则在事件触发时将对其进行求值，并使用该表达式抛出错误。

6 SubProcesses

子流程 是元素容器，允许定义通用功能；当事件触发时，无论子进程中的哪个元素当前处于活动状态，子进程都会被中断。

6.1 Embedded Sub Processes

嵌入式子流程允许您对流程中的各个元素进行分组；嵌入式子进程必须且只能有一个非主启动事件。不允许有其他启动事件；当进入嵌入式子流程时，启动事件被激活。只要包含该子流程的元素处于活动状态，子流程就会保持活动状态。当最后一个元素完成后，子流程结束，并执行输出顺序流程。

嵌入式子流程通常与边界事件一起使用。一个或多个边界事件可以附加到子流程。当触发中断边界事件时，整个子流程（包括所有活动元素）将被终止。

6.2 Event Sub Processes

事件子流程是由事件触发的子流程。它可以全局添加到流程中，也可以局部添加到嵌入式子流程中。

事件子流程必须恰好有一个以下类型之一的开始事件：

事件子流程的行为类似于边界事件，但它位于作用域内部，而不是附加到作用域。与边界事件类似，事件子流程可以是中断性的，也可以是非中断性的（在 BPMN 中，通过起始事件的实线或虚线边框来表示）。当包含事件子流程的作用域被激活时，可以触发该事件子流程的起始事件。

非中断式事件子进程可以多次触发。中断式事件子进程只能触发一次；当触发中断事件子进程时，其包含作用域的所有活动实例都会终止，包括其他非中断事件子进程的实例；如果触发了事件子进程，则其包含范围只有在触发的实例完成后才会完成。

6.3 Ad-Hoc-Sub Processes

临时子进程是一种特殊的嵌入式子进程，带有临时标记 （用波浪号 "~" 表示）。与常规子进程相比，临时子进程在执行内部元素方面提供了更大的灵活性。

临时子流程的内部元素不与开始或结束事件关联。每个元素都可以多次执行，顺序不限，也可以跳过；如果各个元素相互依赖，则可以通过顺序流将这些元素连接起来，从而在临时子流程中构建结构化的序列。

Retries：调用工作线程失败时需要重试的次数。

如果在同一活动中定义了多个相同 eventType 的监听器，则它们将按照 BPMN 模型中定义的顺序依次执行。