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).
