BPMN 中的顺序流与消息流 - IT 观察者随笔

当 BPMN 图表中的元素正确连接时，该图表才具有意义。其中两个最重要的 BPMN 连接符是顺序流和消息流.

两者均以箭头表示，但它们描述的是不同的关系：

一个顺序流显示活动、事件和网关在流程内发生的顺序。
一个消息流显示不同参与者之间的通信，例如公司、建模为独立泳道的部门、客户或外部系统。

BPMN 图表比较了内部流程订单的顺序流与客户与公司等独立参与者之间通信的消息流。

混淆这两种连接符是 BPMN 建模中最常见的错误之一。

什么是顺序流？

顺序流表示流程的内部进展。它回答了以下问题：

接下来会发生什么？

顺序流以带有实心箭头的实线绘制。它可以连接同一泳道或流程内的事件、活动和网关。例如：

开始事件 → 接收订单 → 检查库存 → 发货 → 结束事件

这意味着流程按此顺序开始：接收订单、检查库存，然后发货。

顺序流还可以显示分支和合并：

从排他网关流出的流可能代表一种可能的决策结果。
从并行网关流出的多个流可能代表并行工作。
多个流入流可以合并到后续活动中。
条件流仅在指定条件为真时才会继续。
默认流在其他条件均不适用时提供备用路径。

顺序流定义流程行为。它们不仅仅是用于使图表更易读的视觉线条。

什么是消息流？

消息流表示不同 BPMN 参与者之间的通信。它回答了以下问题：

参与者之间交换了哪些信息？

消息流以虚线绘制，通常带有开放式箭头。它可以连接不同泳道中的活动、事件或其他适当的消息相关元素。

例如，在线零售商可能会向支付服务提供商发送支付请求：

零售商泳道：发送支付请求 - - - - - > 支付提供商泳道：接收支付请求

虚线连接表示一个参与者向另一个参与者发送信息。这并不意味着发送方直接控制接收方的内部流程。

消息流用于 BPMN 协作中，以建模独立参与者之间的通信。BPMN 规范将消息流作为流程和协作建模的标准元素之一。

主要区别

最简单的规则是：

在泳道内使用顺序流。在泳道之间使用消息流。

泳道代表一个参与者，例如公司、客户、供应商、独立建模的部门或外部应用程序。泳道（lane）仅是泳道内部的细分，因此不同泳道中的活动仍通过顺序流连接。

特性	顺序流	消息流
主要用途	显示流程顺序	显示通信
视觉外观	带实心箭头的实线	带开放式箭头的虚线
典型位置	在同一个泳道内	在不同泳道之间
表示	控制或执行流	信息交换
示例	审查请求 → 批准请求	客户 → 提交申请
是否跨越泳道边界？	否	是
控制另一参与方的流程？	建模内部进展	不；它表示交互

顺序流连接同一泳道内的流程对象，而消息流表示跨参与方边界交换的消息。

跨泳道的顺序流

考虑一个具有三个泳道的采购审批流程：

员工
经理
财务

如果这三个泳道都属于同一公司池，则该流程可以这样建模：

BPMN 图表展示了一个采购审批流程，其中顺序流连接了同一公司泳道内的员工、经理和财务泳道。

这些活动之间的箭头是顺序流，因为这些泳道属于同一池。

泳道用于标识职责，但它们不会创建独立的参与方。该流程仍然表示一个协调的内部工作流。

正确建模

BPMN 图表展示了同一公司泳道内跨越员工、经理和财务泳道的正确顺序流。

错误建模

在同一池内的泳道之间使用消息流：

员工泳道 - - - > 经理泳道 - - - > 财务泳道

这会错误地暗示员工、经理和财务团队是独立的 BPMN 参与方，而不是同一组织内的角色。

池之间的消息流

现在考虑一个涉及客户和供应商的采购流程。这些是独立的参与方，因此应建模为单独的池：

客户池：
提交订单
      - - - - - - - - - - >
供应商池：
接收订单

消息流表明供应商从客户处接收信息。随后，供应商的内部活动可以通过顺序流连接：

供应商池：
接收订单 → 检查库存 → 准备发货

一个完整的协作可能如下所示：

BPMN 图表展示了客户和供应商泳道，其中包含用于订单详情和发货确认的顺序流与消息流。

实际示例：在线订单履行

想象一个涉及以下内容的在线订单流程：

客户
在线商店
支付提供商
运输公司

一个合适的 BPMN 协作可能包含四个池。

在线商店顺序流

在在线商店池中：

BPMN 顺序流图表展示了在线商店泳道中从开始到结束的订单处理步骤。

参与者之间的消息流

在池之间：

BPMN 图表展示了客户、在线商店、支付提供商和运输公司参与者之间的消息流。

支付提供商和运输公司可能有其自身的内部流程，但在线商店无法控制这些内部步骤。它仅与它们交换消息。

消息流并不意味着“任何通信”

一个常见的错误是在涉及信息时使用消息流。这并不总是正确的。

假设一个客户服务流程有一个名为审查客户邮件，随后是更新案例记录。邮件和案例记录是信息，但这些活动仍可能属于同一个流程和池。这些活动应通过顺序流连接。

区分主要基于参与者边界，而不仅仅是数据或信息是否存在。

使用：

顺序流用于参与者流程内的工作顺序。
消息流用于不同参与者之间的通信。
数据关联用于显示某活动读取或生成数据对象。
关联用于将注释或支持文档链接到流程元素。

数据对象和注释提供上下文；它们不能替代顺序流或消息流。

池、泳道和流选择

选择正确的连接器始于选择正确的参与者结构。

在以下情况使用泳道：

活动属于同一组织。
团队共享一个整体流程。
您希望按部门或角色展示职责。
流程引擎或组织负责协调工作。

示例包括：

同一家公司内的销售、财务和运营部门
员工入职期间的 HR、IT 和设施部门
同一家保险公司内的理赔受理、评估和支付环节

在这些泳道中的活动之间使用顺序流。

在以下情况下使用池：

参与方为独立组织。
客户与公司进行交互。
外部系统拥有其自身的流程。
您希望隐藏或抽象另一参与方的内部工作流程。
该交互最好理解为协作或消息交换。

示例包括：

客户与零售商
银行与支付服务提供商
制造商与供应商
雇主与政府机构
公司与外部身份验证服务

在这些池之间使用消息流。

以两种方式建模同一场景

考虑一个涉及银行和申请人的贷款申请场景。

方案一：将申请人作为泳道

如果该图描述的是银行协调的内部流程，并将申请人视为参与该流程的角色，则申请人可能作为银行池内的一个泳道出现。

BPMN 图表展示了一个贷款申请流程，其中申请人被建模为银行泳道内的一个泳道，顺序流连接了各项活动。

顺序流连接各项活动。

当目标是记录银行的内部操作流程时，此方法非常有用。

方案二：将申请人作为独立池

如果该图侧重于申请人与银行之间的协作，请使用独立池：

BPMN 图表展示了一个贷款申请流程，其中申请人和银行为独立泳道，说明了用于数据交换的消息流。

此方法强调独立参与方之间的沟通与交接。

没有任何一种表示方式在所有情况下都自动正确。合适的选择取决于模型的目的和范围。

常见错误

在泳道之间使用消息流

泳道是池的子部分。如果两个泳道属于同一个池，应使用顺序流连接它们的活动。

在独立的池之间使用顺序流

顺序流不应从一个参与方池跨越到另一个池。池之间的通信应使用消息流。

混淆内部工作与外部通信

消息流应展示消息交换，而每个参与方的内部工作应分别使用顺序流进行建模。

例如：

错误：
客户任务 → 供应商任务

更好的协作模型是：

客户池：
提交订单
      - - 订单消息 - - >
供应商池：
接收订单 → 验证订单 → 确认订单

将泳道视为独立组织

泳道可能代表部门、角色或系统，但它仍处于池内。如果参与方拥有独立的过程边界并独立通信，则可能需要使用独立的池。

使用含义不明的箭头

每个连接符都应回答一个具体问题：

这是否表示接下来发生什么？
这是否表示谁与谁通信？
这是否将数据或文档链接到某个活动？

如果答案不明确，该连接符可能放置不当或多余。

使用 Visual Paradigm BPMN Online Free 创建顺序流和消息流

Visual Paradigm BPMN Online Free 提供了一个基于浏览器的环境，用于创建和编辑 BPMN 图表。其拖放编辑器可用于建模池、泳道、活动、事件、网关、顺序流和消息流。Visual Paradigm 还提供 BPMN 2.0 建模能力、流程下钻功能，以及分享或导出图表的选项。

一个由 AI BPMN 工具生成的 BPMN 业务流程图，用于建模员工入职流程。

一个实用的工作流程是：

打开 BPMN 绘图工具。
创建一个新的业务流程图。
为每个独立参与方添加一个池。
仅当划分同一参与方内的职责时才添加泳道。
将活动和事件放置在相应的池或泳道内。
使用顺序流连接内部活动。
使用消息流连接独立的池。
为消息流标注有意义的名称，例如：
- 订单详情
- 付款请求
- 审批决策
- 发货确认
为离开决策点的顺序流添加条件。
检查图表，确认没有顺序流跨越池边界。
使用自动布局或手动对齐以提高可读性。
分享或导出完成的图表以供利益相关者审查。

Visual Paradigm 的 BPMN 编辑器支持流程下钻功能，允许将高层级子流程扩展为更详细的流程图表，而不会使主模型过于拥挤。

使用 AI 辅助功能

AI 辅助的 BPMN 功能可以帮助根据自然语言描述创建初始流程模型。Visual Paradigm 的 AI 工具可以解读叙述内容，识别参与者和活动，建议泳道和网关，并生成可编辑的 BPMN 图表。生成的图表随后可以在在线编辑器中打开，以便进行手动细化。

例如，不要从空白画布开始，而是提供如下提示：

为涉及客户、在线零售商、支付提供商和物流公司的在线订购流程创建 BPMN 协作。

客户向零售商提交订单。零售商检查库存并向支付提供商发送付款请求。支付提供商返回批准或拒绝消息。如果付款获批，零售商向物流公司发送发货请求。物流公司向零售商发送交付确认，零售商再通知客户。

AI 生成的草稿可能会识别出：

客户、零售商、支付提供商和物流公司作为池
库存检查作为活动
付款审批作为网关
付款请求和付款结果作为消息流
零售商内部步骤作为顺序流
发货确认作为消息流

应将 AI 视为起点而非最终权威。请仔细审查生成的模型，特别是池与泳道之间的边界。

一个有用的细化提示

生成初始图表后，请求特定修正：

审查图表，确保零售商池内的所有流均为顺序流，而零售商、支付提供商、客户和物流公司之间的所有通信均以消息流表示。为每个消息流添加标签。

您还可以要求 AI 执行以下操作：

为付款被拒添加替代路径。
为付款超时添加定时器事件。
将客户支持分离为独立的池。
将内部部门转换为泳道。
扩展发货子流程。
识别任何错误跨越泳道边界的连接器。

Visual Paradigm 将其 AI 辅助工作流程描述为对话式和迭代式的：用户可以生成图表，请求更改，然后在功能齐全的在线编辑器中打开结果以进行进一步编辑。

审查 AI 生成的图表

在共享或实施 AI 生成的 BPMN 模型之前，请检查以下内容：

独立参与者是否被表示为独立的泳道？
同一组织内的部门和角色是否被表示为泳道？
顺序流是否仅限于正确的泳道？
消息流是否仅用于泳道之间的通信？
每条消息流是否都有明确的发送者和接收者？
消息名称是否有意义？
网关条件是否明确？
在适当位置是否包含了开始和结束事件？
该图表是否反映了真实的业务流程？
利益相关者是否已审查参与者边界？

AI 可以加速图表创建，但它可能会错误地推断组织边界。部门可能被建模为独立的泳道，而实际上它应该是泳道；或者外部服务可能被放置在组织的泳道内部。人工审查仍然至关重要。

快速决策指南

在 Visual Paradigm 或任何其他 BPMN 工具中进行建模时，请使用此规则：

两个连接元素是否位于同一个泳道内？

是 → 使用顺序流。

否 → 它们是否是位于不同泳道中的独立参与者？

是 → 使用消息流。

否 → 考虑是否需要数据关联或文档关联。

另一种记住区别的方法是：

顺序流描述工作如何流动。消息流描述信息如何在参与者之间流动。

结论

在 BPMN 中，顺序流和消息流服务于不同的目的：

顺序流表示活动、事件和网关的内部顺序。
消息流表示独立参与者之间的通信。
泳道组织泳道内的职责，但不会创建新的参与者。
泳道池建立参与者边界并确定消息流适用的位置。

Visual Paradigm 免费在线版 BPMN 通过可视化的拖放建模环境使这一区分变得实用。其 AI 辅助功能可根据自然语言描述生成初始 BPMN 模型，而在线编辑器则允许您修正泳道边界、优化连接符、标注消息，并为利益相关者审查准备模型。

如有疑虑，请先确定边界。如果工作发生在同一参与者内部，请使用顺序流；如果两个独立参与者交换信息，请使用消息流。