Events BPMN非中断异常流

在处理BPMN模型时，我们遇到了一个有关异常流的问题。 每当需要异常流时，我们都会给它自己的结束事件。尽管BPMN建议使用网关来合并正常流和异常流。我看不出这样做有什么好处，只是增加了一些麻烦。 然而，考虑这样一种情况，在这种情况下，我们有一个活动X和附加到边界非中断事件的子过程。触发时，将创建一个并行令牌并将其放在异常流的分支上。在通过异常流运行之后，结束事件将使用此令牌。 我假设此消耗不会触发上层流（包含此特定子项的流）继续，因为活动X中仍有一个令牌。当此活动结束并执行正常流时，此令牌也被消耗，子项不包含任何令牌。这将触发上层流动继续。 在这种情况下，我想不出任何需要合并异常流和正常流的情况。（活动x之后的活动也必须在异常流中运行，导致它们被多次执行的情况除外）

我假设此消耗不会触发上层流（包含此特定子流程的流）继续，因为活动X中仍有一个令牌

这是一个准确的说法；以下模型具有相同的语义（非中断多事件触发器用作占位符）：

BPMN规范中的管理部分是第10.5.3节，该节要求“流程内生成的所有令牌必须在流程完成之前由结束事件使用。”

在这种情况下，我想不出任何需要合并异常流和正常流的情况

一种可能需要合并的情况发生在两个流必须合并后才能开始流程中稍后的任务时。作为一个简单的示例，以以下模型为例：

---

在顶部的模型中，

活动Y

可能会在

活动X

完成后立即开始，无论是否存在并行运行的

异常活动的实例。在底部的模型中，
异常活动
的所有实例（如果有）完成后，
活动Y
才能启动。如果需要第二个示例的语义，则需要合并正常流和异常流。
最后一个图并不不准确，实际上是无效的

根据定义，异常流不能构成平滑流的一部分。根据定义，异常流不能使用IF进行计算

最后的图（错误地）引入了一个网关，它最终将接收两个令牌并（错误地）触发活动Y两次

我认为这种语言是错误的——如果异常流必须在Y触发之前完成，那么作者描述了一个中断边界事件。描述该事件解决了语法错误带来的建模问题。只生成一个令牌，并且只触发一次活动Y