An event in the Stardust Process Engine is a condition or situation affecting the behavior of a running process instance or activity instance. An arising event is normally associated with a set of actions, which will then execute. Specific for such actions is that they allow richer process behavior than straight modeled control flow.
However, an event itself can be caused by the workflow processing - see the explanation of engine events below.
The difference to triggers is that events always have the scope of already running process instances or activity instances.
For details on working with Event Handlers in the Eclipse Modeler and the Modeling perspective, please refer to chapters Working With Activity Event Handlers and Working with Process Definition Event Handlers in the Eclipse Modeling Guide and chapter Modeling the Organizational Structure in the Business Process Modeling Handbook respectively.
The event types accepted by the Stardust Process Engine may be categorized as follows:
Engine events for an activity instance/process instance arise because of a change in the overall state of the activity instance/process instance:
Pull events are events which arise by meeting a time condition (e.g. a timer event).
For an activity/process definition event handlers have to be defined to be aware of a specific event at runtime. An event handler defines the specific match condition to accept the event at runtime. Multiple event handlers are possible - even for the same event type.
An activity may define the following event handlers:
The ultimate goal of getting notified of event occurrence is to introduce custom side effects. Multiple event actions may be defined per event handler, which will execute consecutively at runtime if the event handler matches the event.
A couple of event actions are predefined:
The following table displays for which process or activity event handler specific event action types are supported:
| Event Action Type | Process Event Handler Types | Activity Event Handler Types |
|---|---|---|
| Abort Process | Timer | Timer, On Exception |
| Abort Activity | Timer, On Exception | |
| Delegate Activity | On Activity State Change, Timer, On Exception | |
| Send Mail | Timer, On Process State Change | On Activity State Change, Timer, On Exception, On Assignment |
| Process Trigger | Timer, On Process State Change | On Activity State Change, Timer, On Exception, On Assignment |
| Schedule Activity | On Activity State Change, Timer, On Exception | |
| Set Data | Timer, On Process State Change | On Activity State Change, Timer, On Exception, On Assignment |
| Activate Activity | Timer, On Exception, On Assignment | |
| Complete Activity | Timer, On Exception | |
| Exclude User | On Assignment |
Event handlers can pass data to the subordinate actions. These data are offered as access points. The concrete set of available access points depends on the type of the event handler.
It is possible to extend the Stardust Process Engine by custom event action types. For details, refer to the Programming Guide.
Handlers for pull events are not automatically enabled by default but instead may be enabled programmatically at runtime by an operation called binding.
When binding an event handler the Stardust API allows overriding the properties of the event handler and the subordinate event actions and bind actions (see below).
Alternatively, it is possible to configure the timer event to be bound automatically. This will bind the timer event at activity instance creation time. However, the bind actions are executed in this case, too.
An enabled "Log Handler" specifies whether an occurrence of the corresponding event should be logged to the audit trail or not.
If Consume on match is selected any logically following handler accepting the same event will not be executed, thus effectively terminates the processing of the current event.
Beyond event actions it is possible to specify bind actions which are executed when the event is bound. Bind actions are executed in order of definition.
Bind actions are especially useful in a workflow scenario called resubmission. Resubmission (of an activity) means removing an interactive activity instance from a worklist and putting it back later, based on some criterion. Resubmission for an activity in Stardust is modeled in the following way:
At runtime, this would allow the following resubmission scenario:
There are obviously variants of this scenario, e.g. to auto bind the handler and leave out step 2 of the above modeling scenario. This would result in a behavior where the activity instance is always put to the worklist only after a certain amount of time. This could be useful in situations where it is sure that you have to wait a certain time, e.g to receive a document by mail.
Analog to the process of binding there is the process of unbinding an event handler, which removes the binding of the handler. This also has to be done programmatically. Unbind actions are defined similarly to bind actions. They are executed when unbinding happens.
To continue the preceding example, imagine you want to explicitly remove the activity instance from resubmission because the reason for being hibernated no longer exists. When unbinding this activity instance there has to be a mechanism to put it back to the worklist. This could be done by an appropriate scheduled unbind action.
The Modeling perspective uses intermediate events, following the BPMN 2.0 standards. As the name implies, the Intermediate Event indicates where an event happens somewhere between the start and end of a Process. It affects the flow of the Process, but does not start or (directly) terminate the Process. Intermediate Events can be used to:
The following diagram depicts the classification of intermediate events supported in the Portal Modeling perspective.
Figure: Intermediate Event
Boundary events are Intermediate events attached to the boundary of an Activity. Boundary events can be:
You should use Timer Boundary event if an activity is not processed within specified time interval, explanation email should be sent.
You should use Error Boundary event in case an error occurs when executing an activity and the activity should get aborted.
Boundary Events can have only one outbound exception flow, but multiple paths can be supported using a gateway. All Boundary Events in a model must have an outgoing sequence flow.
Note
BPMN 2.0 allows multiple outbound exception flows from a boundary event.
The Stardust engine currently does not support this, but may provide
it in a future release.
Non-boundary events are Intermediate events specified always between two activities, or gateway and activity. Only timer event can be added as a non-boundary event.
You can use the non-boundary timer event if you want a delay between the two activities.
Note
Non-Boundary Events are not directly supported by the Stardust engine,
but it is shown as a Route Activity.
Non-boundary Intermediate Events can have both an inbound and outbound sequence flow. All Intermediate Events in a model must have both an incoming and outgoing sequence flow.
Interrupting events do:
Interrupting events can be timer or error boundary events.
Non-interrupting events do:
Non-interrupting events can be timer boundary or non-boundary events.
The following elements can be the exception flow target:
Note that Data may not be connected directly to Events in the Portal Modeling perspective.
An existing exception flow (i.e., connection) is maintained when dropped onto another activity or onto the drawing canvas.