Skip to content

Change Boundary Event Type#11293

Open
DmytroKost wants to merge 2 commits into
mendix:developmentfrom
DmytroKost:wor/change-boundary-event-type
Open

Change Boundary Event Type#11293
DmytroKost wants to merge 2 commits into
mendix:developmentfrom
DmytroKost:wor/change-boundary-event-type

Conversation

@DmytroKost
Copy link
Copy Markdown
Contributor

For 11.12


Boundary events are re-created upon interrupting behavior change because in-place conversion can result in invalid states. An interrupting boundary event must abort its parent activity when triggered, meaning an activity cannot have more than one active interrupting boundary event. Converting an already-triggered non-interrupting boundary event to interrupting in place violates this rule: the parent activity remains in progress, resulting in an interrupting boundary event whose parent is never aborted. Conversely, converting an already-triggered interrupting boundary event to non-interrupting in place leaves it active on an already-aborted parent activity, contradicting the rule that a non-interrupting boundary event must not abort its parent.

#### Implications of Changing the Boundary Event Type
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took me a bit to understand this section. What do you think about the following? We can even wrap it in an alert for more emphasis.

Changing a non-interrupting Boundary Event

Due to technical limitations, changing an ongoing non-interrupting boundary event creates a partially resolvable conflict of type Current Activity Moved out of Path on running workflow instances, which requires manual intervention. This does not apply to interrupting boundary events.

For resolution steps, see Workaround for Non-resolvable and Partially Resolvable Conflicts.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changing an ongoing non-interrupting boundary event

may imply any change to its configuration (like first execution type). I think it makes sense to mention "type" like I did and give an example.

which requires manual intervention

This is true for every conflict. I think the problem is not manual intervention but rather the limitation that one cannot continue the workflow.

For resolution steps, see

That linked section focuses on a workaround. The resolution steps are mentioned in the first reference to the conflict Current Activity Moved out of Path.

1. Right-click the boundary event to open its context menu.
2. Click **Change event**.
3. Select one of the available options:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can leave out the image and options. So just

You can change the type of an existing boundary event via the context menu, without having to delete and re-add it. To do so:

  1. Right-click the boundary event to open its context menu.
  2. Click Change event.
  3. Select the desired boundary event type.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I rephrased the into to the section like you suggested.

Regarding the image, if we can show part of UI we are referring to I see no reasons not to. In this case its a single graphic so it doesn't even clutter the documentation.

If you think we should remove this picture then we could just as well remove the rest of them from the page. right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants