业务流程模型与符号（BPMN）2.0提供了一种标准化的语言来描述工作流。虽然内部流程步骤较为直接，但整合组织外部的实体需要特定的建模技术。外部参与者包括客户、合作伙伴、第三方系统或监管机构。正确表示这些交互可以确保流程执行的准确性并实现清晰的沟通。本指南详细介绍了在BPMN 2.0规范内连接外部参与者的技术细节。
理解边界 🛑
在建模外部交互时，根本挑战在于定义流程的边界。在BPMN中，一个池代表一个参与者。一个流程通常只有一个池，代表执行工作流的组织。任何位于该池之外的实体都被视为外部的。
- 内部池：包含组织所拥有的活动。
- 外部池：代表与流程交互但不控制其内部逻辑的参与者。
当您建模涉及外部方的流程时，必须区分组织内部发生的事情和外部世界发生的事情。这种区分决定了用于连接活动的流程类型。
消息流与顺序流 💬
BPMN中最关键的区别之一是顺序流与消息流之间的差异。混淆这两者可能导致技术上无效或逻辑上模糊的模型。
- 顺序流：表示执行的顺序在单一参与者（在一个池内）内部。这些是实线箭头。
- 消息流：表示信息的交换在两个参与者（两个池之间）之间。这些是虚线箭头。
在连接外部参与者时，必须使用消息流。在两个池之间使用顺序流是一种建模错误。顺序流意味着控制，即上游活动直接触发下游活动。消息流意味着通信，其中一方发送消息并等待响应或确认。
视觉表示
| 流类型 | 方向 | 线条样式 | 使用场景 |
|---|---|---|---|
| 顺序流 | 内部 | 实线 | 同泳道内活动到活动 |
| 消息流 | 外部 | 虚线 | 泳道到泳道（参与者到参与者） |
| 关联 | 内部/外部 | 点线 | 连接数据对象或注释 |
外部通信的事件类型 📨
事件是与外部参与者启动或终止交互的主要机制。您可以根据时机和意图对这些交互进行分类。
开始事件
开始事件标志着流程的开始。当外部参与者触发一个流程时，开始事件通常是一个消息开始事件.
- 此事件表示流程在继续之前会等待传入的消息。
- 它位于泳道的最开始位置。
- 传入的消息流直接连接到此事件。
例如，客户发送的订单确认消息会启动履行流程。在消息到达之前，该流程并不存在。
中间事件
中间事件发生在流程的生命周期中。当流程处于活动状态时，它们有助于捕获消息。
- 中间捕获消息事件： 流程在此暂停，直到收到特定消息。这常用于异步更新，例如来自银行系统的付款确认。
- 中间发送消息事件： 流程在此点发送消息。当流程需要通知外部方状态变更时使用。
边界事件
边界事件附着在活动的边界上。它们允许您处理异常或超时，而无需立即停止主流程。
- 消息边界事件： 如果外部方在流程运行期间发送取消请求，此事件将捕获该请求。
- 这使得流程能够在不放弃当前活动的情况下对外部干扰作出响应。
网关与决策 🔄
外部参与者通常通过决策点引入复杂性。一个流程可能需要根据从外部来源接收到的响应进行分支。网关用于管理这些路径。
XOR 网关
排他网关（XOR）从多个选项中选择一条路径。在外部交互的背景下，这通常在接收到响应后使用。
- 如果外部系统返回“成功”消息，流程将遵循一条路径。
- 如果消息表明“错误”，流程将遵循另一条路径。
- 传入的消息流必须连接到决策之前的网关或事件。
AND 网关
包容网关在条件满足时允许同时采取多条路径。然而，在消息流中，同步是关键。
- 汇聚网关会等待所有传入路径完成。
- 与外部方通信时，延迟很常见。您必须确保网关在继续之前等待必要的消息。
处理异步性 ⏳
外部交互很少是即时的。系统可能离线，或者响应可能需要时间。BPMN 2.0 通过异步行为来处理这种情况。
- 非阻塞： 当一个流程发送消息时，除非明确建模为等待，否则不会等待即时回复。
- 消息保留： 流程引擎会存储消息，直到其被接收。
- 超时： 如果在设定时间内未收到响应，定时中间事件可以触发升级。
这对长时间运行的流程至关重要。如果流程为每次外部调用都同步等待，将导致资源低效消耗。异步消息传递允许流程在等待期间继续执行其他任务。
数据交换与负载 📦
消息不仅仅是信号；它们还携带数据。在BPMN中，数据由以下表示：数据对象 和 数据输入/输出.
- 数据对象： 用于表示活动使用或生成的信息的可视化符号。
- 数据输入： 启动活动所需的信息。
- 数据输出： 活动生成的信息。
与外部参与者连接时，消息内容至关重要。您应在消息规范中记录预期的数据负载。
| 组件 | 功能 | 外部相关性 |
|---|---|---|
| 消息 | 数据容器 | 定义接口契约 |
| 数据对象 | 特定数据项 | 显示正在传输的内容 |
| 关联 | 将对象链接到元素 | 明确数据流方向 |
常见陷阱需避免 ⚠️
建模外部参与者会引入特定风险。常见错误可能导致流程模型无效或难以执行。
- 使用顺序流连接泳道： 如前所述，这是无效的。跨泳道通信时，必须始终使用消息流。
- 缺少消息开始事件： 如果流程通过外部输入启动，则必须使用消息开始事件。通用开始事件意味着流程在内部启动。
- 无法到达的路径： 确保每个涉及外部输入的路径都有相应的响应。如果流程等待一个永远不会到达的消息，就会发生死锁。
- 忽略错误处理： 外部系统会失败。始终使用边界事件或错误结束事件来建模错误路径。
- 泳道过于复杂： 不要为每个外部实体都创建一个泳道。应将泳道保留给外部实体，并仅在必要时使用泳道表示该实体内的内部角色。
清晰性最佳实践 ✅
为确保模型对技术团队和业务利益相关者都易于理解，请遵循以下指南。
- 清晰标注： 明确命名消息流（例如“订单确认”、“状态更新”）。
- 使用协作图： 对于复杂的多方交互，协作图通常比单一的大泳道更清晰。
- 分离关注点： 尽可能将内部流程逻辑与外部接口逻辑分开建模。
- 记录接口： 为消息中使用的数据结构附加注释或单独的技术规范。
- 一致的样式： 对所有消息流使用相同的线型和颜色编码，使其与顺序流区分开来。
外部交互的生命周期 🔁
理解生命周期有助于正确放置元素。典型的交互遵循以下顺序：
- 启动： 外部方发送一条消息。这会触发一个消息开始事件。
- 处理： 内部活动处理数据。如果需要更多外部数据，可能会发生中间事件。
- 响应： 流程向外部方发送一条消息作为回应。
- 完成： 结束事件标志着流程的成功终止。
如果流程超时或收到错误，生命周期将以不同方式结束，通常需要补偿或取消流程。
关于外部连接的结论 🎯
建模外部参与者需要精确性。内部控制与外部通信之间的区别是有效BPMN 2.0图的基础。通过正确应用消息流、适当的事件以及清晰的边界定义，您将创建一个准确反映业务现实的蓝图。
在这些方面的细节关注可以防止执行错误，并确保所有利益相关者都理解系统如何与更广阔的世界交互。目标是创建一个不仅视觉上正确，而且语义上稳健的模型。
