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.
See also Working With Activity Event Handlers and Working with Process Definition Event Handlers.
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.