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
+37-36Lines changed: 37 additions & 36 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,94 +6,95 @@ weight: 20
6
6
7
7
## Introduction
8
8
9
-
An Event Sub-process is a separate execution flow that is not part of the normal sequence flow of its workflow. It resides inside the workflow and starts executing upon receiving a specific trigger.
10
-
It is crucial to understand that an Event Sub-process is part of the same workflow instance. It is not a "separate" workflow; rather, a single workflow instance can contain multiple concurrent processes.
9
+
An event sub-process is a separate execution flow that is not part of the normal sequence flow of its workflow. It resides inside the workflow and starts executing upon receiving a specific trigger.
10
+
It is crucial to understand that an event sub-process is part of the same workflow instance. It is not a "separate" workflow; rather, a single workflow instance can contain multiple concurrent processes.
11
11
12
-
Below is an example of what an Event Sub-process looks like:
12
+
Below is an example of what an event sub-process looks like:
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 (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.
26
26
27
27
#### When NOT to Use
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, 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.
32
32
33
33
### How Event Sub-Processes Work
34
34
35
35
#### Lifecycle
36
36
37
-
The Event Sub-process is initialized (but not started) as soon as the main process starts and remains in a waiting state until a notification is received.
37
+
The event sub-process is initialized (but not started) as soon as the main process starts and remains in a waiting state until a notification is received.
38
38
39
39
{{% alert color="info" %}}
40
-
**What keeps a workflow In Progress?** A workflow instance remains in the **In Progress** state as long as **at least one** of the following is true:
41
-
- The Main Process path has not yet reached its End Event.
42
-
- Any Event Sub-Process that was started has not yet reached its End Event.
40
+
A workflow instance remains **In Progress** as long as at least one of the following conditions is met:
41
+
42
+
* The main process path has not yet reached its end event.
43
+
* Any event sub-process that was started has not yet reached its end event.
43
44
{{% /alert %}}
44
45
45
-
The workflow will **not** complete until all active execution paths, both the main flow and any triggered event sub-processes, have reached their respective End Events.
46
+
The workflow will NOT complete until all active execution paths, both the main flow and any triggered event sub-processes, have reached their respective end events.
46
47
47
48
#### Triggers and Notifications
48
49
49
-
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 action. When the trigger is received, the sub-process becomes **In Progress**.
50
51
51
52
#### Interrupting vs. Non-Interrupting
52
53
53
-
-**Interrupting (Solid line)** – Immediately cancels the main process flow.
54
-
-**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.
55
56
56
57
{{% alert color="warning" %}}
57
-
Currently, Mendix only supports the Non-interrupting variant of Event Sub-processes. Support for Interrupting Event Sub-processes is planned for a future release.
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.
58
59
{{% /alert %}}
59
60
60
61
#### Concurrency Limitation
61
62
62
-
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** 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
64
64
-
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 (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
66
66
67
## Getting started
67
68
68
69
### Adding Event Sub-Processes
69
70
70
-
To add an Event Sub-process to a workflow, follow these steps:
71
+
To add an **Event sub-process** to a workflow, follow these steps:
71
72
72
-
* Select an Event Sub-process from the **Sub-processes** section in the workflow **Toolbox**.
73
+
* Select an event sub-process from the **Sub-processes** section in the workflow **Toolbox**.
73
74
74
75
* 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.
79
80
80
81
* The flow can contain the same types of activities as the main process flow (e.g., **User Task**, **Call Microflow**, **Decision**).
81
82
82
-
* It must start with a **Start Event** (triggered by a notification) and end with at least one **End Event**.
83
+
* It must start with a **Start**event (triggered by a notification) and end with at least one **End** event.
83
84
84
85
## Execution
85
86
86
-
To start an Event Sub-process create a **Notify Workflow** microflow action and point it to the Event Sub-process start event.
87
+
To start an event sub-process create a **Notify Workflow** microflow action 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.
93
+
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.
93
94
94
-
The following table outlines how top-level workflow operations and system states affect any Event Sub-process currently In Progress:
95
+
The following table outlines how top-level workflow operations and system states affect any event sub-process currently In Progress:
95
96
96
-
| Event or Operation | Effect on Event Sub-process| System Behavior |
97
+
| Event or Operation | Effect on Event Sub-Process| System Behavior |
| Abort Workflow | Aborted | The sub-process is permanently stopped and cannot be re-notified. |
99
100
| Restart Workflow | Aborted & Reset | The active sub-process instance is aborted. It returns to a waiting state and can be notified again. |
@@ -104,16 +105,16 @@ The following table outlines how top-level workflow operations and system states
104
105
105
106
## Jump Rules
106
107
107
-
Event Sub-processes have specific restrictions regarding [Jump activity](/refguide/jump-activity/) and [Jump to](/refguide/jump-to/):
108
+
Event sub-processes have specific restrictions regarding [Jump activity](/refguide/jump-activity/) and [Jump to](/refguide/jump-to/):
108
109
109
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.
110
111
***Within a Sub-process**: Jumps within the same sub-process are permitted.
111
-
***Jump to Start Event**: Aborts the current sub-process instance and returns it to a waiting state.
112
-
***Jump to End Event**: Completes the sub-process instance immediately.
112
+
***Jump to Start Event**: Aborts the current sub-process instance and returns it to a waiting state.
113
+
***Jump to End Event**: Completes the sub-process instance immediately.
113
114
114
115
## Domain Model Structure
115
116
116
-
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.
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.
117
118
118
119
### WorkflowSubProcessDefinition
119
120
@@ -138,7 +139,7 @@ The `WorkflowSubProcessDefinition` entity represents the metadata of a Sub-proce
138
139
139
140
### WorkflowSubProcess
140
141
141
-
The `WorkflowSubProcess` entity represents a specific runtime instance of an Event Sub-process. A `WorkflowSubProcess` object is created only after an Event Sub-process is notified and started its execution.
142
+
The `WorkflowSubProcess` entity represents a specific runtime instance of an event sub-process. A `WorkflowSubProcess` object is created only after an event sub-process is notified and started its execution.
0 commit comments