You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/en/docs/refguide/modeling/application-logic/workflows/event-sub-processes.md
+25-28Lines changed: 25 additions & 28 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,20 +15,20 @@ Below is an example of what an event sub-process looks like:
15
15
16
16
### When to Use Event Sub-Processes
17
17
18
-
An event sub-process is like a Boundary Event, with the exception that an event sub-process can start at any time, whereas a Boundary Event can start only while the activity it is attached to is active.
19
-
Choosing between a Boundary Event and an event sub-process is a common architectural crossroads.
18
+
An event sub-process is like a boundary event, with the exception that an event sub-process can start at any time, whereas a boundary event can start only while the activity it is attached to is active.
19
+
Choosing between a boundary event and an event sub-process is a common architectural crossroads.
20
20
21
21
#### Ideal Use Cases
22
22
23
-
***Global Exception Handling** – Handling errors or cancellations that could occur at any point during the workflow execution.
24
-
***Isolated Logic** – Complex steps triggered by a specific event (e.g., "Change of Address") without cluttering the main flow.
25
-
***Inline Updates** – Updating data in a long-running process without interrupting the primary state of the workflow.
23
+
***Global exception handling** – Handling errors or cancellations that could occur at any point during the workflow execution.
24
+
***Isolated logic** – Complex steps triggered by a specific event (for example, "Change of Address") without cluttering the main flow.
25
+
***Inline updates** – Updating data in a long-running process without interrupting the primary state of the workflow.
26
26
27
-
#### When NOT to Use
27
+
#### When Not to Use Event Sub-Processes
28
28
29
-
***Sequential Logic** – If the logic must happen after a specific task, use a standard sequence flow.
30
-
***Conditional Logic Based on Activity State** – You may want to execute a flow only if a certain condition is met while a specific activity is active. A **Boundary Event** should be used here because it is triggered only if the activity it is attached to is active.
31
-
***Returning to a Specific Point** – If you need to abort a specific task execution and resume it later, a **Boundary Event (Interrupting)** is often more appropriate. Once the event is triggered, the **Boundary Event** can utilize a **Jump activity** to return to the original task.
29
+
***Sequential logic** – If the logic must happen after a specific task, use a standard sequence flow.
30
+
***Conditional logic based on activity state** – You may want to execute a flow only if a certain condition is met while a specific activity is active. A boundary event should be used here because it is triggered only if the activity it is attached to is active.
31
+
***Returning to a specific point** – If you need to abort a specific task execution and resume it later, an interrupting boundary event is often more appropriate. Once the event is triggered, the boundary event can utilize a **Jump** activity to return to the original task.
32
32
33
33
### How Event Sub-Processes Work
34
34
@@ -47,22 +47,22 @@ The workflow will NOT complete until all active execution paths, both the main f
47
47
48
48
#### Triggers and Notifications
49
49
50
-
Event sub-processes are triggered by a **Notify Workflow** microflow action. When the trigger is received, the sub-process becomes **In Progress**.
50
+
Event sub-processes are triggered by a **Notify workflow** microflow activity. When the trigger is received, the sub-process becomes **In Progress**.
51
51
52
52
#### Interrupting vs. Non-Interrupting
53
53
54
-
***Interrupting (Solid line)** – Immediately cancels the main process flow.
55
-
***Non-Interrupting (Dashed line)** – Runs in parallel with the main flow.
54
+
***Interrupting (solid line)** – Immediately cancels the main process flow.
55
+
***Non-Interrupting (dashed line)** – Runs in parallel with the main flow.
56
56
57
-
{{% alert color="warning" %}}
57
+
{{% alert color="info" %}}
58
58
Currently, Mendix only supports the non-interrupting variant of event sub-processes. Support for interrupting event sub-processes is planned for a future release.
59
59
{{% /alert %}}
60
60
61
61
#### Concurrency Limitation
62
62
63
-
Mendix Workflows currently support a **single concurrent instance** per defined event sub-process. If a non-interrupting event sub-process is already active, subsequent attempts to trigger that same sub-process via the **Notify Workflow**action will return false. No new instances will be created for that specific sub-process while one is In Progress. A new instance can only be initiated once the active sub-process has completed its execution path.
63
+
Mendix Workflows currently support a **single concurrent instance** per defined event sub-process. If a non-interrupting event sub-process is already active, subsequent attempts to trigger that same sub-process via the **Notify workflow**activity will return `false`. No new instances will be created for that specific sub-process while one is **In Progress**. A new instance can only be initiated once the active sub-process has completed its execution path.
64
64
65
-
If your workflow has multiple, distinct event sub-processes defined (e.g., one for "Address Change" and one for "Document Upload"), each one can have its own active instance simultaneously. One being active does not prevent a different one from being triggered.
65
+
If your workflow has multiple, distinct event sub-processes defined (for example, one for "Address Change" and one for "Document Upload"), each one can have its own active instance simultaneously. One being active does not prevent a different one from being triggered.
66
66
67
67
## Getting started
68
68
@@ -71,28 +71,25 @@ If your workflow has multiple, distinct event sub-processes defined (e.g., one f
71
71
To add an **Event sub-process** to a workflow, follow these steps:
72
72
73
73
* Select an event sub-process from the **Sub-processes** section in the workflow **Toolbox**.
74
-
75
74
* Drag it onto a dashed drop zone adjacent to the main workflow process.
* The sub-process flow will be contained within a dashed rectangle. This dashed border around the sub-process start event indicates that it is a non-interrupting sub-process.
80
-
81
-
* The flow can contain the same types of activities as the main process flow (e.g., **User Task**, **Call Microflow**, **Decision**).
* The sub-process flow is contained within a dashed rectangle. This dashed border around the sub-process start event indicates that it is a non-interrupting sub-process.
79
+
* The flow can contain the same types of activities as the main process flow (for example, **User Task**, **Call Microflow**, **Decision**).
83
80
* It must start with a **Start** event (triggered by a notification) and end with at least one **End** event.
84
81
85
82
## Execution
86
83
87
-
To start an event sub-process create a **Notify Workflow** microflow action and point it to the event sub-process start event.
84
+
To start an event sub-process, create a **Notify workflow** microflow activity and point it to the event sub-process start event.
An event sub-process is bound to the lifecycle of its parent workflow instance. Administrative actions and system-level events (such as errors or version conflicts) directly impact the execution state of active sub-processes.
94
91
95
-
The following table outlines how top-level workflow operations and system states affect any event sub-process currently In Progress:
92
+
The following table outlines how top-level workflow operations and system states affect any event sub-process that is currently **In Progress**:
96
93
97
94
| Event or Operation | Effect on Event Sub-Process | System Behavior |
@@ -107,18 +104,18 @@ The following table outlines how top-level workflow operations and system states
107
104
108
105
Event sub-processes have specific restrictions regarding [Jump activity](/refguide/jump-activity/) and [Jump to](/refguide/jump-to/):
109
106
110
-
***Between Processes**: It is not possible to jump into a sub-process from the main process (or vice versa), nor between different sub-processes.
111
-
***Within a Sub-process**: Jumps within the same sub-process are permitted.
107
+
* Between processes: It is not possible to jump into a sub-process from the main process (or vice versa), nor between different sub-processes.
108
+
* Within a sub-process: Jumps within the same sub-process are permitted.
112
109
***Jump to Start Event**: Aborts the current sub-process instance and returns it to a waiting state.
113
110
***Jump to End Event**: Completes the sub-process instance immediately.
114
111
115
112
## Domain Model Structure
116
113
117
-
To provide comprehensive monitoring, management, and auditing capabilities, the Mendix Workflow engine utilizes specific system entities and associations. These ensure that every event sub-process instance is traceable back to its definition and correctly linked to the overall workflow lifecycle.
114
+
To provide comprehensive monitoring, management, and auditing capabilities, the Mendix Workflow Engine utilizes specific system entities and associations. These ensure that every event sub-process instance is traceable back to its definition and correctly linked to the overall workflow lifecycle.
118
115
119
116
### WorkflowSubProcessDefinition
120
117
121
-
The `WorkflowSubProcessDefinition` entity represents the metadata of a Sub-process as defined in the workflow model.
118
+
The `WorkflowSubProcessDefinition` entity represents the metadata of a sub-process as defined in the workflow model.
0 commit comments