PXE generates events to let you track what is exactly happening in the engine and produces detailed information about process executions. These events are persisted in PXE's database and can be browsed using the Console.
The following table details each event possibly generated by PXE:
| Event Name |
Process/Scope |
Description |
Type |
| ActivityEnabledEvent |
Scope |
An activity is enabled (just before it's started) |
activityLifecycle |
| ActivityExecStartEvent |
Scope |
An activity starts its execution |
activityLifecycle |
| ActivityExecEndEvent |
Scope |
An activity execution terminates |
activityLifecycle |
| CompensationHandlerRegistered |
Scope |
A compensation handler gets registered on a scope |
scopeHandling |
| CorrelationMatchEvent |
Process |
A matching correlation has been found upon reception of a message |
correlation |
| CorrelationNoMatchEvent |
Process |
No matching correlation has been found upon reception of a message |
correlation |
| CorrelationSetWriteEvent |
Scope |
A correlation set value has been initialized |
dataHandling |
| ExpressionEvaluationFailedEvent |
Scope |
The evaluation of an expression failed |
dataHandling |
| ExpressionEvaluationSuccessEvent |
Scope |
The evaluation of an expression succeeded |
dataHandling |
| NewProcessInstanceEvent |
Process |
A new process instance is created |
instanceLifecycle |
| PartnerLinkModificationEvent |
Scope |
A partner link has been modified (a new value has been assigned to it) |
dataHandling |
| ProcessCompletionEvent |
Process |
A process instance completes |
instanceLifecycle |
| ProcessInstanceStartedEvent |
Process |
A process instance starts |
instanceLifecycle |
| ProcessInstanceStateChangeEvent |
Process |
The state of a process instance has changed |
instanceLifecycle |
| ProcessMessageExchangeEvent |
Process |
A process instance has received a message |
instanceLifecycle |
| ProcessTerminationEvent |
Process |
A process instance terminates |
instanceLifecycle |
| ScopeCompletionEvent |
Scope |
A scope completes |
scopeHandling |
| ScopeFaultEvent |
Scope |
A fault has been produced in a scope |
scopeHandling |
| ScopeStartEvent |
Scope |
A scope started |
scopeHandling |
| VariableModificationEvent |
Scope |
The value of a variable has been modified |
dataHandling |
| VariableReadEvent |
Scope |
The value of a variable has been read |
dataHandling |
The second column specifies wether an event is associated with the process itself or with one of its scopes. The event type is used for filtering events.
Using PXE's deployment descriptor, it's possible to tweak events generation to filtrate which ones get created. First, events can be filtered at the process level using one of the following stanza:
<dd:process-events generate="all"/>
<dd:process-events generate="none"/>
<dd:process-events>
<dd:enable-event>dataHandling</dd:enable-event>
<dd:enable-event>activityLifecycle</dd:enable-event>
</dd:process-events>
The first form just duplicates the default behaviour, when nothing is specified in the deployment descriptor, all events are generated. The third form lets you define which type of event is generated, possible types are: instanceLifecycle, activityLifecycle, dataHandling, scopeHandling, correlation.
It's also possible to define filtering for each scope of your process. This overrides the settings defined on the process. In order to define event filtering on a scope, the scope activity MUST have a name in your process definition. Scopes are referenced by name in the deployment descriptor:
<dd:deployment-descriptor xmlns:dd="http://pxe.fivesight.com/schemas/2006/02/14/bpeldd">
...
<dd:process-events generate="none">
<dd:scope-events name="aScope">
<dd:enable-event>dataHandling</bpel:enable-event>
<dd:enable-event>scopeHandling</bpel:enable-event>
</dd:scope-events>
<dd:scope-events name="anotherScope">
<dd:enable-event>activityLifecycle</bpel:enable-event>
</dd:scope-events>
</bpel:process-events>
...
</dd:deployment-descriptor>
Note that it's useless to enable an event associated with the process itself when filtering events on scopes.
The filter defined on a scope is automatically inherited by its inner scopes. So if no filter is defined on a scope, it will use the settings of its closest parent scope having event filters (up to the process). Note that what gets inherited in the list of event, not each event definition individually.
