[WOR-2536]: Update docs for interrupting boundary events GA #9685
Conversation
davevissermx
force-pushed
the
WOR-2536-update-docs-for-GA-int-boundary-events
branch
from
faf6232 to
6e142c1
Compare
| The **Recurrence** property allows a non-interrupting timer boundary event to execute multiple times when the specified interval has elapsed. The following parameters can be set. | ||
| | Type | Description | | ||
| | --- | --- | | ||
| | Interval | You can set a certain duration for the timer. With the **Repeat every** setting, you can indicate the number of seconds, minutes, hours, days, weeks or months the timer's duration is. Possible values for the setting are:<br /><ul><li>Minutes</li><li>Hours</li><li>Days</li><li>Weeks</li><li>Months</li> </ul> | |
There was a problem hiding this comment.
- Repeat every doesn't have seconds option
- "With the Repeat every setting ... the timer's duration is". You are referring to the interval between occurrences, which is somewhat different from the first execution duration. I think it will be good to indicate that.
| @@ -125,6 +121,16 @@ An interrupting boundary event path must end with an **End** event or a **Jump** | |||
| When there are multiple boundary events attached to an activity and an interrupting boundary event is executed, all the scheduled boundary events will be aborted and all the boundary events that have already started will continue to run until the entire workflow ends. | |||
| {{% /alert %}} | |||
|
|
|||
| ## Nested jump rules | |||
| Boundary events come with a specific set of rules for jumps when they are nested, the variations are working meant for both a modelled jump and a runtime ad-hoc jump. In the following table are the differences specified. | |||
There was a problem hiding this comment.
"a modelled jump and a runtime ad-hoc jump", I would put it "a Jump activity and and ad-hoc jump" with references to the corresponding articles.
| @@ -125,6 +121,16 @@ An interrupting boundary event path must end with an **End** event or a **Jump** | |||
| When there are multiple boundary events attached to an activity and an interrupting boundary event is executed, all the scheduled boundary events will be aborted and all the boundary events that have already started will continue to run until the entire workflow ends. | |||
| {{% /alert %}} | |||
|
|
|||
| ## Nested jump rules | |||
There was a problem hiding this comment.
Let's rename it to just "Jump rules", since we might want to expend the scope of cases in this section to also include:
- Jump rules related to jumping in or out of boundary events to the main path
- Jumps between sibling or unrelated (not nested) boundary events
| ## Nested jump rules | ||
| Boundary events come with a specific set of rules for jumps when they are nested, the variations are working meant for both a modelled jump and a runtime ad-hoc jump. In the following table are the differences specified. | ||
|
|
||
| |Parent | Child | Description| |
There was a problem hiding this comment.
We don't need to specify what kind of path is the child/parent path (parallel path, boundary event or main path). It doesn't matter when it comes to the jump options, because we currently don't allow to perform an ad hoc jump into the parent path or out of the child path (we will add an option to jump out of interrupting boundary events later, and if it's already implemented for the Jump activity we should specify it).
I suggest to organize the rules in the following way:
- Jump inside a boundary event: not allowed (and never will be regardless of how they are organized)
- Jump outside a boundary event: not allowed (will be allowed in the future for interrupting boundary events but only to the parent/grandparent path)
- Jump within a boundary event: allowed
| @@ -134,12 +140,6 @@ The list of variables is described below: | |||
| * `$ParentTask` – the parent user task of the attached boundary event | |||
| * `$CalledWorkflowInstance` – the parent Call workflow activity of the attached boundary event | |||
|
|
|||
| ## Current Limitation {#limitation} | |||
There was a problem hiding this comment.
Let's mention one limitation that becomes relevant mainly with the introduction of recurrence. The limitation is that a scheduled timer boundary event is not cancelable by another instance of the same boundary event. A more concrete example will be an ad hoc jump from MUT to itself. If we have a scheduled timer and then we perform a jump to self, effectively restarting the activity, a new timer will be scheduled. However, the old timer will still be pending, and if it expires first the new timer will be ignored. There might be other cases where the same behavior can be observed but I don't think we need to list them all. We are also planning or removing this limitation in the future.
|
The points regarding changing the boundary event type have to be completely changed, since they don't describe what happens accurately: https://github.com/mendix/docs/pull/9685/files#diff-5f3afa7b2f6cd6055dc4e5f9c58bc87e5668ac5991eaff9ab6b9ab37cad53d44R87 Point 1 says "The boundary event is re-created as the specified type. As a result, new IDs are created. These IDs are used by the Mendix Runtime for conflict detection analysis.", where the last sentence is incorrect, new IDs are not used for conflict detection. Instead, we should indicate that the boundary event will be scheduled with the specified type right after redeploy as soon as the workflow is in progress. Point 2 says "The current activities on the boundary event path including the boundary event itself become incompatible and need to be restarted.". The workflow becomes incompatible rather then the activities. And that will happen only if the boundary event has already started, if it was scheduled it will be effectively ignored. I think it's useful to point to the 2 conflict types that will occur:
|
| @@ -125,6 +121,16 @@ An interrupting boundary event path must end with an **End** event or a **Jump** | |||
| When there are multiple boundary events attached to an activity and an interrupting boundary event is executed, all the scheduled boundary events will be aborted and all the boundary events that have already started will continue to run until the entire workflow ends. | |||
| {{% /alert %}} | |||
|
|
|||
| ## Nested jump rules | |||
There was a problem hiding this comment.
Comment to section: #### Implications of Changing the Boundary Event Type
Pls explain why we are doing it this way? I think it's mainly because of the possible migrations of inflight processes that would not make much sense.
There was a problem hiding this comment.
Right, the main reason we're doing this is indeed because of execution limitations that we impose on ongoing boundary events. For example, the parent activity will be in-progress when a non-interrupting BE starts, and after it's type is changed to interrupting the parent activity will still stay in progress thus allowing to have more than one active interrupting boundary event. And vice versa, when an interrupting BE is changed to a non-interrupting the parent activity is already aborted, and since a non-interrupting BE cannot end the workflow it will hang forever unless aborted.
|
|
||
| |Parent | Child | Description| | ||
| | -------- |-------- | ------- | | ||
| |Interrupting | Interrupting | When an interrupting boundary event is nested inside an interrupting boundary event we are allowed to either jump out of the boundary event flow or end the workflow.| |
There was a problem hiding this comment.
@Yiyun333 pls check in this table the use of "we are allowed" or similar. Do we use this or we use "you" or make it neutral. Note: this is for the entire table.
| |Interrupting | Non-Interrupting | When an interrupting boundary event is nested inside an non-interrupting boundary event we are only allowed to jump out of the boundary event flow to it's parent flow.| | ||
| |Non-Interrupting | Interrupting | When a non-interrupting boundary event is nested inside an interrupting boundary event we are only allowed to jump in the nested non-interrupting boundary event flow, this follows the same rules as the parallel split outcomes.| | ||
| |Non-Interrupting | Non-Interrupting | When a non-interrupting boundary event is nested inside an non-interrupting boundary event we are only allowed to jump inside the nested non-interrupting boundary event flow, this follows the same rules as the parallel split outcomes.| | ||
|
|
||
| ## Boundary Event Variables | ||
|
|
||
| Boundary events have dedicated variables that can be used to get direct access to the values of the parent activity if it is either a user task or Call workflow activity. You can get information such as the parent activity's `DueDate`, which can be used in the boundary event flow and its expressions. For instance, you can use the expression `addDays($ParentTask/DueDate, -2)` to configure a timer boundary event so that it is triggered two days before the due date of its parent user task. |
There was a problem hiding this comment.
"... used to get direct access..." => "... used by activities in the path of the boundary event to get direct access..."
This MR updates the docs for the GA release of interrupting boundary events