We will delve into the various event types, exploring their categorizations and applications.
It's vital to note that not every type of event is suitable for all variations; there are specific rules and guidelines governing their use.
As highlighted in the table, there are distinct limitations.
For instance, while you cannot initiate a primary process with an escalation event, it's entirely permissible to kickstart a subprocess with such an event.
To adhere to BPMN standards, it's crucial to consult and follow the provided guide.
Always ensure that your processes and diagrams conform to these accepted norms.
An Intermediate Event takes place between the beginning and the conclusion of a process.
They can either wait for a specific occurrence (such as receiving a message), initiate an occurrence (like dispatching a message), or pause until a condition is fulfilled or a designated time elapses.
Think of a scenario where a manager is given a specific duration to assess a request.
If the manager fails to complete the evaluation within this timeframe, an interrupting timer will activate, ceasing the ongoing process and initiating a different one.
The original task is no longer accessible; instead, the situation has shifted.
The provided example demonstrates the same function, but one is with an interrupting start event, while the other is with an interrupting boundary event.
- To initiate parallel activities without disturbing the primary flow, like sending periodic reminders while still waiting for a main task to complete.
- When you want to monitor situations without interrupting the main flow, such as watching for specific signals or messages.
Consider the previous example, but instead of terminating the initial review task when the time elapses, a Non-Interrupting Event is triggered, creating another thread.
A reminder is sent to the manager about the outstanding review without disturbing the primary review process.
The original task proceeds uninterrupted.
This scenario exemplifies the use of a Non-Interrupting Event, where the primary process and reminder notification operate in parallel.
Both actions stay active throughout their execution.
Throw events are used to "send" or "throw" a particular type of event.
In BPMN, when we talk about a throw event, we're generally discussing an activity or a situation where a specific signal, message, or error is being generated or sent out.
Imagine a situation where, as soon as the manufacturing of an item begins, a signal is sent to trigger a notification to another department or a customer.
This signal conveys that the production task has either commenced or concluded.
The throw event is immediate, causing no interruptions or delays in the main process.
It's crucial to recognize that there are numerous approaches to catching or receiving this notification signal.
Catch events are used to "receive" or "catch" a particular type of event.
In BPMN, when we refer to a catch event, we're talking about a point in the process where it's waiting for or listening to a specific event from another process or activity.
The reception of an event can take place in various ways.
Drawing from the previous example, the event can be caught at the inception of a sub-process within the same primary process.
Alternatively, it could be captured at the start of an entirely distinct process.
Moreover, it can also be seized by a boundary event of another task, provided that this task is active when the event is thrown, allowing it to be intercepted by its corresponding boundary event.
It can also be caught in the middle of a process (refer to the last example in the Non-Boundary Events section).
Boundary and Non-Boundary Events are pivotal in determining how certain events and activities are placed, handled, and how they interact with other elements in a process.
In our initial scenario where a manager needs to approve or review a submission, employing a timer as a start event impacts the entire workflow.
This implies that if this timer is triggered, a different process will kick off, regardless of where the main process currently stands.
On the other hand, when we utilize boundary events, we can confine the timer's influence to a specific task, subprocess, or call-activity.
This approach grants us greater precision over the timer's scope, as it only applies to the particular task or subprocess it's linked to, and the timer only initiates when the first task within its designated scope begins.
Note that a boundary event can be interrupting or non-interrupting.
If we want to initiate a separate process before starting the manufacturing task, we deploy an intermediate signal event.
This event's role is specifically to trigger a distinct process.
Unlike a start event, if a boundary catch event isn't active—meaning there's no active instance waiting at that signal event, the thrown signal won't be caught, and the separate process remains unused.
If our goal is to schedule the manufacturing to kick off at a specific time, say 6 pm, or delay it for a short while, we can represent this with a timer.
The workflow will pause at this event until the timer's conditions are satisfied.
Conditions function as gatekeepers.
For instance, the process will halt until the 'production_sheet_signed' variable evaluates as true, indicating the production sheet has been signed and manufacturing can commence.
The concept mirrors that of messages and signals.
A message, much like a signal, will only be caught in an intermediate event if there's an instance at the ready in the associated catch event.
⚠ Remember the key distinction between signals and message events is that while messages adhere to a one-to-one correspondence, signals can potentially relate to multiple recipients in a one-to-many fashion.
