bpmn一门路径&事件

发布于 2025-02-04 22:13:06 字数 199 浏览 4 评论 0原文

使用相同的XOR网关进行越野路径和事件是可能的吗?

Is it possible and correct to use same XOR gateway for outcoming paths and event?

enter image description here

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

北恋 2025-02-11 22:13:06

不,这在句法上是不正确的。

XOR网关在BPMN标准中称为“基于数据的独家网关”。仅通过在传入流提供的数据中找到匹配来完成外向流的选择。但是,您正在等待的事件不是被视为数据。

您可以改用事件的独家网关。它可能有两个传出的流程:一个指向“收到的消息”事件,另一个指向“ 14天已经过去”的事件。在“收到消息接收”事件之后,您可以用图片中的两个“是”和“否”流插入XOR网关。

另外,您可以从图片中的XOR网关中删除向计时器事件的流动,并将其作为中断边界计时器事件附加到XOR网关之前的任务。

No, it would be syntactically incorrect.

The XOR gateway is called “data-based exclusive gateway” in the BPMN standard. The selection of the outgoing flow is simply done by finding a match within the data that the incoming flow has provided. The event that you are waiting for is, however, not treated as data.

You could use an event-based exclusive gateway instead. It could have two outgoing flows: one pointing towards a “message received” event and another one with the “14 days have passed” event. After the “message received” event, you could then plug in the XOR gateway with its two “yes” and “no” flows as in your picture.

Alternatively, you could remove the flow towards the timer event from the XOR gateway in your picture and attach it as an interrupting boundary timer event to the task immediately preceding the XOR gateway.

书间行客 2025-02-11 22:13:06

简而言之,

BPMN独家门不是流程图决策节点:独家门不是从其传入流开始的决策任务。大门是根据传入流的那一刻可用的数据立即做出决定的地方。因此,绝不会导致延迟的大门。

更多详细信息

独家门 ,但必须选择一个:

  • 每个流都必须根据播放状态(可用数据)与条件表达式相关联;
  • 一个流可以是一个默认值,如果没有其他条件为真,则可以选择。 (通常您会在整个行上用/标记默认流。)

这不是您想要的:到计时器的流量不能是选择而不是选择的默认值公认的投诉。计时器流程似乎是替代路径,可以取代通过门。我知道这是大门之前的某些事情的暂停。

然后,正确的解决方案将取决于使计时器开始打勾的原因:

  • 如果是在门前紧接的任务,则只需添加中断计时器边界事件该任务:
  • 如果是进一步的消息,那么考虑到某些元素可能必须将某些元素分组为

In short

The BPMN exclusive gate is not a flowchart decision node: the exclusive gate is not a decision-making task that would start with its incoming flow. The gate is where the decision is IMMEDIATELY made based on the data available at that moment of the incoming flow. So it's never the gate that will cause delays.

Some more details

The exclusive gate can have multiple outgoing flows, but exactly one must be chosen:

  • each flow must be associated with a condition expression based on the the state of play (data available) when reaching the gate;
  • one flow can be a default that is chose if none to the other conditions are true. (Normally you'd mark the default flow with a / across the line.)

This is not what you want here: the flow to the timer cannot be a default that would be chosen instead of the accepted complaint. The timer flow seems to be an alternate path that replaces the way through the gate. I understand that it's a timeout for something preceding the gate.

The right solution will then depend on what makes the timer start to tick:

  • If it is the task immediately preceding the gate, then just add an interrupting timer boundary event of that task:
    enter image description here
  • If it is the reception of some message further ahead, then it might be slightly more difficult, considering that some elements might have to be grouped in an embedded subprocess to be able to interrupt the right sequence.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文