Events
In the following we will describe the events' simulation properties.
Linking Events to Each Other
To simulate BPMN 2.0 models, we need to know, which sending event(s) trigger(s) which receiving event(s). To accomplish this, we need to give events that shall be linked to each other the same name.
Approach
Imagine you create a model that contains two intermediate sending message events and two intermediate receiving message events. Then there are two possible ways, to identify associated (or linked) events:
-
You connect the events via message flows.
-
(This is not possible for other event types, therefore we also offer a second option, see below)
-
-
You do not want to add anymore flows to your model, because they would reduce your model’s clarity.
-
Therefore we offer you the possibility, to avoid using message flows between sending and receiving message events by simply giving them the same name.
-
Please see Models 4c (Messages without an explicit message flow), 5 (sending Signals to Multiple Process Instances) and 6 (Triggering Start Events) from the Simulation Tutorial for examples to this concept.
Limitations
There are some limitations to this concept:
-
Pay attention to the events' relations. E. g. one sending message event can trigger only one receiving message event, 1:1 relation. But one sending signal event can trigger more than just one receiving signal event, 1:n relation.
-
Receiving events without a label (name) will catch all triggered sending events of the same type depending on the relations (see bulleting above).
-
If the model contains one receiving and one sending event of the same type, it will link these two events to each other.
-
It is possible to model n:1 relations (always depending on the BPMN 2.0 Specification’s constraints. E. g. one receiving message event can be triggered by n sending message events).
Start Events
A process is started by a start event, which can be either general or depending on time or on other facts (receiving a message, signal etc.). Since the latter cases always involve sending events, we only need to add simulation properties to the general and to the timer start event.
To start the process we need to add some information. We can either select one of the
-
stochastic distributions (see Stochastic Event Trigger or Model 1a from the Simulation Tutorial for examples)
-
or recurrent time instants from the time editor to determine the process' inter-arrival time (see Calendar Based Event Trigger or Model 1c from the Simulation Tutorial for examples)
-
or we can write a Python-script (Scripted delay). See Scripted Event Trigger or Model 1d from the Simulation Tutorial for examples
| Contrary to the conceptual idea of the message receiving start event, we allow you to specify an inter-arrival time to represent the duration until the message receipt. This is occasionally necessary, e. g. if you do not want to model a black box pool, which sends the messages to this specific start event, and which solely exists to start this event. |
Simulation Properties of the General and the Timer Start Event
Optional Simulation Properties
- Inter-arrival Time
-
Select a stochastic distribution (which represents your process' inter-arrival time) or use Calandar based or Script based Event Triggers to set up the inter-arrival times.
-
See Assigning Inter-arrival Time / Duration for more information.
-
Or see Chapter 1 (Processes and Sequence Flow) from the Simulation Tutorial for an example.
-
Intermediate Events
Events generally do not possess any simulation properties. All of them use the inherent information based on the BPMN 2.0 specification.
However there are exceptions:
-
Timer intermediate event: It basically does the same job as the general / timer start event. The only difference is that it can be placed "in" the flow or it can be attached to an activity.
-
Message receiving intermediate event: In some occasions you will simply want to create a model, which uses the conceptual idea of a message receiving event, but which does not necessarily have a respective sender event in another pool. Therefore we offer you the possibility to specify an optional duration to represent the time consumption until the message receipt usually occurs.
-
Conditional intermediate event: This type of event is triggered when a condition is met. Therefore, such a condition must be added as a simulation property. The event can be placed "in" the flow or attached to an activity.
| If you do not specify one of the below properties, the simulation will execute the event immediately when reaching the activity. |
Simulation Properties of the Timer Intermediate Event
Optional Simulation Properties
- Inter-arrival time
-
Specify a distribution (for a time span), a recurrent time instant or a script to represent this event’s trigger delay. This approach is equivalent to the stochastic time operations at Start Events. See Model 12 - Scripted Delay from the Simulation Tutorial for an example.
Simulation Properties of the Message receiving Intermediate Event
Simulation Properties of the Conditional Intermediate Event
Optional Simulation Properties
- Condition
-
Specify a condition for when this event should trigger.
End Events
End events do not contain any simulation properties. They are used to terminate a process and to trigger start events if they are linked to those.
The number of occurrences of end events is counted and provided in simulation results.