-
Notifications
You must be signed in to change notification settings - Fork 12
BoundaryEvent Plugin
boundaryEvents
and boundaryEvent
This plugin supports BPMN boundary events. A boundary event always belongs to one dedicated task. Each task can have multiple boundary events. Therefore the different boundary events that belong to one task are enumerated with the tag boundaryEvent
between the boundaryEvents
tags. The syntax of a boundaryEvent
is nearly equivalent to the syntax of every normal event but is extended by a eventProbability
tag which defines which with probability this boundary event triggers.
Currently supported boundary events are cancel events (cancelEventDefinition
), compensation events(compensateEventDefinition
), conditional events(conditionalEventDefinition
), error events(errorEventDefinition
), escalation events(escalationEventDefinition
), link events( linkEventDefinition
), message events(messageEventDefinition
), signal events( signalEventDefinition
)and terminate events(terminateEventDefinition
).
(Furthermore there are timer events(timerEventDefinition
) but they are handled differently right now.)
None
If the XES-Logger is active, the boundary events will be logged in there.
Each BPMN boundary event belongs to one task. The boundary event will be scheduled by his given event probability after its arrival rate if the scheduling time is smaller or equal to the end of the task. If the arrival rate is higher, the boundary event will not be scheduled.
If a boundary event is triggered and it is an interrupting event
, the belonging task will be canceled instantly and just the branch of the boundary event will be followed. The regular flow will never fire. Interrupting events will be scheduled once.
If a boundary event is triggered and it is an non interrupting event
, the belonging task will not be canceled. The boundary event will be scheduled to trigger after the arrival rate again. This will happen as long as the time to trigger is smaller or equal to the end time of the belonging task. The regular flow will be followed once after ending the task. The boundary event flow will trigger once every time the boundary event fires.
Example for a boundary event in simulation file:
<bsim:Task id="Task_0a9svk3" name="Task 1">
<bsim:duration timeUnit="MINUTES">
<bsim:constantDistribution>
<bsim:constantValue>60</bsim:constantValue>
</bsim:constantDistribution>
</bsim:duration>
<bsim:boundaryEvents>
<bsim:boundaryEvent id="BoundaryEvent_1fpwyp1" name="Ablehnung">
<bsim:eventProbability>1</bsim:eventProbability>
<bsim:arrivalRate timeUnit="MINUTES">
<bsim:constantDistribution>
<bsim:constantValue>20</bsim:constantValue>
</bsim:constantDistribution>
</bsim:arrivalRate>
</bsim:boundaryEvent>
</bsim:boundaryEvents>
</bsim:Task>
Normally the eventProbability
should always be 1, except you have very special claims and you can not regulate it by choosing or modifying the distribution for this boundary event.
The belonging BPMN file has to contain (this is in case it is a messageEvent, follow the same concept):
<bpmn:boundaryEvent id="BoundaryEvent_1fpwyp1" name="Ablehnung" attachedToRef="Task_0a9svk3" cancelActivity="true">
<bpmn:outgoing>SequenceFlow_1pmljcm</bpmn:outgoing>
<bpmn:messageEventDefinition id="sid-684bb66e-44e0-44e9-930a-22442bb66ba3" messageRef="sid-49ff666e-c07f-428f-9f70-ecb0a29b882a"/>
</bpmn:boundaryEvent>
and the corresponding event definition:
<bpmn:message id="sid-49ff666e-c07f-428f-9f70-ecb0a29b882a" name="ThesisOverMessage"/>
In detail to the implementation and pluggable usage:
The parser of Scylla gets extended by the BoundarySCParserPlugin
at the SimulationConfigurationParserPluggable
regulating the parsing of boundary events. Furthermore the TaskBeginEventPluggable
gets extended by the BoundaryTBPlugin
to do the creating and scheduling of boundary events mentioned above. Also the BPMNIntermediateEventPluggable
gets extended (by the BoundaryIntermediateEventPlugin
) to ensure the cancellation of the parent task if it is an interrupting event.