BPMN 模型与节点类型

1. 什么是 BPMN

BPMN，全称 Business Process Model and Notation，中文一般称作“业务流程建模与标注”。它是一种被国际广泛采用的业务流程图标准，由 OMG（Object Management Group）制定，最新版本是 BPMN 2.0。

它的目标是让“业务人员看得懂，技术人员能实现”。也就是说，BPMN 图既能作为业务沟通的可视化文档，也能被流程引擎直接读取并执行。

当你在 Flowable Modeler 或 Camunda Modeler 中绘制流程时，其实就是在用 BPMN 语法描述一套可以被机器识别的逻辑。
这些逻辑最终会保存为一个 XML 格式的 .bpmn 文件，引擎读取并解析其中的结构，执行对应的节点。

2. BPMN 模型的基本组成

一张 BPMN 流程图通常由三类元素构成：
事件（Event）、活动（Activity） 和 网关（Gateway）。
这三者共同定义了“什么时候开始、做什么事、在什么条件下往哪走”。

除此之外，还有一些辅助元素（如顺序流、泳道、消息流等），用于描述执行顺序、角色分工和系统交互。

我们逐一来看。

3. 事件（Event）

事件是流程的“信号灯”，表示某个事情的发生。BPMN 中的事件分为三种主要类型：开始事件、结束事件、边界事件。

3.1. 开始事件（Start Event）

表示流程的起点。它告诉引擎：流程从这里启动。
例如“员工提交请假申请”、“系统接收到支付回调”都属于开始事件。

在图形上通常用一个空心圆表示：

○——开始

常见的开始事件类型：

普通开始事件：手动启动流程；
消息开始事件：接收到消息后启动；
定时开始事件：到达指定时间自动触发；
信号开始事件：当某个全局信号被广播时触发。

对于绝大多数审批类流程，我们使用普通开始事件即可。

3.2. 中间事件（Intermediate Event）

表示流程在进行中某个时刻等待或触发的事件。
比如“等待外部系统回调”、“计时三天后自动转交”、“接收审批结果”等。
中间事件通常绘制在流程线中间，形状是一个双圆圈：

◎——中间事件

3.3. 结束事件（End Event）

表示流程的终点。
当执行流到达结束事件时，流程实例会被标记为“已完成”，引擎会清理运行时数据并写入历史表。

常见的结束事件类型包括：

普通结束事件：流程正常结束；
错误结束事件：抛出异常，中断流程；
终止结束事件：强制终止整个流程实例（包括所有分支）。

图形上通常为实心圆：

●——结束

4. 活动（Activity）

活动表示“要做的事”，是流程中最核心的执行节点。
BPMN 中的活动分为几种主要类型：

4.1. 用户任务（User Task）

由人工完成的任务，例如“主管审批”、“经理签字”。
当执行流到达用户任务节点时，引擎会在数据库中生成一条任务记录，分配给某个审批人。
用户完成任务后，引擎再自动流转到下一个节点。

这类节点在企业流程中最常见，形状为一个带小人图标的矩形。

4.2. 服务任务（Service Task）

由系统自动执行的任务，例如“调用外部接口”、“发送通知短信”、“写入数据库”。
它不需要人工参与，而是通过配置 Java Delegate 或表达式（Expression）来指定执行逻辑。

这类任务是实现系统自动化的关键。
在图形上，它通常是一个矩形，带有齿轮形图标。

4.3. 脚本任务（Script Task）

用于执行一段脚本（如 JavaScript、Groovy），在流程中处理逻辑或赋值变量。
例如可以用脚本任务判断金额大小、格式化数据等。

4.4. 接收任务（Receive Task）

表示流程到此暂停，等待外部系统发出“继续执行”的信号后再往下走。
常用于异步回调或消息驱动场景，例如支付完成后再继续审批。

4.5. 子流程（Sub-Process）

当流程很复杂时，可以将其中一部分拆分成一个“子流程”，实现模块化。
子流程既可以内嵌在主流程中，也可以单独定义为可复用流程。

这种设计思想和代码中的“函数调用”类似，便于维护与复用。

4.6. 调用活动（Call Activity）

与子流程类似，但它不是嵌入式的，而是调用另一个独立定义的流程。
比如“主流程”调用一个名为“通用审批”的子流程，这样多个流程都可以复用相同的逻辑。

5. 网关（Gateway）

网关控制流程的走向，决定“往哪条路径走”、“是否并行执行”或“何时汇聚”。
BPMN 中的网关形状是一个菱形，不同类型的网关表示不同逻辑：

5.1. 排他网关（Exclusive Gateway，XOR）

只会选择一条路径执行。
比如：

if (days <= 3)
   → 主管审批
else
   → 总经理审批

在图中用一个普通菱形表示，内部有“×”符号。

5.2. 并行网关（Parallel Gateway，AND）

用于同时执行多个分支。
当执行流到达并行网关时，引擎会复制多条执行路径，分别进入不同的分支，直到所有分支都完成后再汇聚。

常用于“多部门并行审批”场景。

图中用菱形内含“+”号表示。

5.3. 包含网关（Inclusive Gateway，OR）

类似排他网关，但它可以选择多个满足条件的路径并行执行。
例如：

if (金额 > 5000)
    → 财务审批
if (天数 > 3)
    → 经理审批

此时两个条件都满足，就会同时走两条线。

5.4. 事件网关（Event-Based Gateway）

这种网关用于等待不同事件的发生来决定流程走向。
比如等待“用户批准”或“超时3天未处理”，两者先到哪个事件，就执行哪个分支。

6. 连接线（Sequence Flow）

连接线用于描述流程的执行顺序。
每一条线都有一个条件表达式（Condition Expression），用于判断是否可以流转。
例如：

<sequenceFlow id="flow1" sourceRef="task1" targetRef="task2">
    <conditionExpression>${days <= 3}</conditionExpression>
</sequenceFlow>

在 BPMN 图中，箭头表示执行方向，条件判断通常会写在连线旁边。

7. 泳道与角色（Lane & Pool）

在企业级流程中，常常需要表示“谁负责哪一步”。
BPMN 提供了 泳道（Lane） 和 泳池（Pool） 来区分角色或系统。

泳池（Pool）：表示一个独立的参与者或系统（如“公司A”、“外部系统B”）。
泳道（Lane）：表示泳池内的角色或部门（如“员工”、“主管”、“HR”）。

通过泳道划分，可以清晰看到每个节点由谁负责执行，便于管理职责与审批路径。

8. 消息流与信号

BPMN 还支持不同流程之间的通信机制。

消息流（Message Flow）：用于表示两个独立流程之间传递消息，例如“订单流程”向“发货流程”发送通知。
信号事件（Signal Event）：一种广播机制，一个流程发出信号，其他监听相同信号的流程都能被触发。

这让流程引擎具备了跨系统协同的能力。

9. 边界事件（Boundary Event）

边界事件是挂在任务节点外侧的小圆圈，用于“打断”或“监控”任务。
例如：

超时边界事件：审批人在 3 天内未处理则自动转交；
错误边界事件：调用接口出错后走补偿分支。

边界事件可以是中断型（打断当前任务）或非中断型（并行触发）。

10. 综合示例

我们来看一个综合的 BPMN 示例（文字版）：

○（开始）
   ↓
[员工填写请假单]
   ↓
<排他网关：天数>3？>
   ↙                 ↘
[主管审批]       [总经理审批]
   ↘                 ↙
      [HR备案]
         ↓
        ●（结束）

这张图表达的业务含义很清楚：
员工提交申请后，系统根据请假天数自动选择不同的审批路径，审批完成后再由人事备案，最后流程结束。

这张图就是一个可执行的 BPMN 模型，引擎会根据它精确地控制执行顺序。

11. 总结

BPMN 是流程引擎的灵魂，它用一种图形化、标准化的方式把业务逻辑“画”给系统看。
事件定义了流程的起点与终点，活动表示“做什么事”，网关负责判断走向，泳道划分角色职责，连接线则串起整个过程。

掌握了这些元素，你就能独立地看懂和绘制任何一张 BPMN 流程图，也能在 Flowable 或 Camunda 中自由地设计业务流程。