Camunda并行网关不等待所有序列流。

huangapple go评论86阅读模式
英文:

Camunda parallel gateway does not wait for all sequence flows

问题

我正在使用Camunda实现一个BPMN流程。我的工作流程如下所示:

Camunda并行网关不等待所有序列流。

如您所见,任务A、B和C都是需要完成的用户任务。有时需要重复执行这些任务,因此我通过REST API修改流程实例。

这种修改会在需要重复执行的任务/活动之前开始。

现在,如果您要重复执行任务A 3次,因为您希望重复执行它,那么并行网关将不再等待所有序列流都执行完毕,而只会触发终止事件(需要终止触发通知服务任务)。

据我理解,这似乎是包容网关的行为,它只等待一定数量的序列流执行。

但是,根据我理解,并行网关应该等待其连接的每个单独的序列流都执行完毕。

这个行为是否已知?

英文:

I am implementing a bpmn process with camunda. My Workflow looks as follows:

Camunda并行网关不等待所有序列流。

As you see tasks A, B and C are user tasks which need to be completed. Sometimes these tasks need to be repeated so i modify the process instance via the rest api.

This modification then starts before the task/activity that has to be repeated.

Now if you complete task A 3 times because you want to repeat it, the parallel gateway no longer waits for all sequence flows to be executed and just triggers the terminate event (needed to kill the trigger notification service task above).

As i understand this seems to be the behaviour of an inclusive gateway, which just waits for a certain amount of sequence flows to be executed.
But the parallel gateway should wait for every single one of its joined sequence flows to be executed as far as i unterstand it.

Is this behaviour known?

答案1

得分: 2

BPMN 2.0规范第10.5.4节“并行网关”中提到:

对于传入的流,并行网关将等待所有传入的流,然后触发通过其传出的顺序流的流程。

因此,从技术上讲,您的期望是正确的。引擎只等待与传入顺序流数量相等的令牌数,因此您得到了观察到的行为。

如何处理重复执行(以及触发)的方式相当不常见。为什么不使重复任务的可能性在流程中可见呢?例如,您可以附加一个消息边界事件并将其回环到任务(在您的示例中是A)。然后使用消息API,而不是更侵入性的修改API。这将导致一个更能反映可能发生的流程模型。

除了使用修改API之外,还有其他替代的模型化选项,包括BPMNError、升级、紧随任务的XOR网关、嵌套子流程等。

英文:

The BPMN 2.0 specification section 10.5.4 "Parallel Gateways" says:

> For incoming flows, the Parallel Gateway will wait for all incoming
> flows before triggering the flow through its outgoing Sequence Flows.

so technically your expectation is correct. The engine only waits for a number of tokens equal to the number of incoming sequence flows and therefore you get the observed behavior.

How you are work with a repeated execution (and also the trigger) is rather uncommon. Why don't you make the possibility of repeating the task visible in the process? You could for instance attach a message boundary event and loop back into the task (A in your example). Then use the message API instead of the more invasive modification API. This would lead to a process model which better reflects what can happen.
Other alternative options to model this better instead of using modification API include BPMNError, Escalation, xor gateway following task, embedded sub process and more.

huangapple
  • 本文由 发表于 2023年3月3日 21:10:30
  • 转载请务必保留本文链接:https://go.coder-hub.com/75627492.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定