If a package with existing package name is uploaded, all the processes in the package
will be versioned.
In this case, all the old processes in the package will be retired while a new version
will be be deployed.
Since there is only package level versioning, the new package should include all the
processes defined
in the old package, eventhough you may only need to update a single process in that
package.
WSO2 BPS 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 BPS's database and
can be queried using
the
Management API. The default behaviour for the
engine is to always
generate all events for every executed action. However from a performance standpoint it
is better to
deactivate some of the events you're not interested in (or even all of them). Inserting
all these events
generates a non-negligible overhead.
Event Types
The following table details each event possibly generated by ODE:
Event Name
Process/Scope
Description
Type
ActivityEnabledEvent
Scope
An activity is enabled (just before it's started)
activityLifecycle
ActivityDisabledEvent
Scope
An activity is disabled (due to dead path elimination)
activityLifecycle
ActivityExecStartEvent
Scope
An activity starts its execution
activityLifecycle
ActivityExecEndEvent
Scope
An activity execution terminates
activityLifecycle
ActivityFailureEvent
Scope
An activity failed
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
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 whether an event is associated with the process itself or
with one of its scopes.
The event type is used for filtering events.
Filtering Events
Filtering at the process level
Using the deployment descriptor, it is 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:
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
Filtering at the scope level
It is 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:
Note :
Note that it is 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 is the full list of selected events, not each event definition individually.
Event Listeners
WSO2 BPS lets you register your own event listeners to analyse all produced events and do whatever you want
to do with them. To create a listener, you just need to implement the org.apache.ode.bpel.iapi.BpelEventListener
interface.
Then add your implementation in the server's classpath (BPS_HOME/repository/components/lib) and add a property
in bps.xml giving your fully qualified implementation class name:
You can try the sample event listener that is shipped with WSO2 BPS by adding above configuration to the bps.xml and restart the server.
You can find the source of the sample implementation of event listener here.
Partner links
Partner-links are the abstraction for end-point references used in a the BPEL process. So
a partner-link definition should be able to represent all the information required to
interact with a external partner. Also the interaction can be two sided as follows.
The process invokes a partner
A partner invokes the process
So a partner-link may hold information on WSDL port-type that the business process offers
to and the WSDL port-type that the partner suppose to offer.
These information are characterized by a partner-link-type and role name at each
partner-link. There can be two roles may be defined for a partner-link known as "myRole"
and "partnerRole". "myRole" specifies the portType provided by the BPEL process to the
partner. "partnerRole" specifies the interface provided by the partner. Partner-links
can be defined in global level or scope level at a BPEL process.
The relevant partnerLinkType should be declared in the partner WSDL or the BPEL process
it-self such that it declares the set of roles and the port-types defined by each of the
roles.
