This is the WSO2 Business Process Server documentation version 3.0.0.View documentation for the latest release.

Unknown macro: {next_previous_link3}
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

A business process is typically a collection of related and structured activities or tasks, that depicts a business use case and produces a specific service or output. For example, a banking customer requesting a bank load and getting loan approval is a simple process. An instance of this process is a specific example of this process workflow. So, Mr. Smith requesting for 50,000 USD and getting approval for it is an instance of the "bank loan approval" process. Every time a banking customer makes a request for a loan, that request triggers a new process instance in the BPM system, which flows through the elements of the process workflow according to its design.

At a particular time, there can be numerous instances of a single process. Follow the instructions below to access process instances.

1. Log in to the management console and select "Business Processes -> Instances" in the "Main" menu.

2. The "Instances Created" window opens.

  • Instance ID:
  • Process ID:
  • Status:
  • Date Started:
  • Last Active:
  • Total Instances:
  • Actions:

3. Click on an Instance ID to view "Instance Information". For example,

The following details can be accessed:

Instance Information

Details of the process instance as described above.

Root Scope Information
  • Scope ID:
  • Scope Name:
  • Status:
  • Variables:
Activity Information

<To be added>

4. In the "Instances Created" window, click on selected process ID.

5. The "Process Information" window opens. For more information on each section, refer to Deploy and Manage a BPEL Process.

Process Instance Events

WSO2 BPS generates events to facilitate tracking the activities of the engine and produces detailed information about process executions. These events are persisted in BPS's database and can be queried using the BPS Management API. The default behavior of the BPS engine is to generate events for every executed action. However, for better performance, it is recommended to deactivate selected or all events depending on your requirements as these events usually cause a non-negligible overhead in the system.

Event Types

The following table depicts the event types generated by ODE:

Event NameProcess/ScopeDescriptionType
ActivityEnabledEventScopeAn activity is enabled (just before it's started)activityLifecycle
ActivityDisabledEventScopeAn activity is disabled (due to dead path elimination)activityLifecycle
ActivityExecStartEventScopeAn activity starts its executionactivityLifecycle
ActivityExecEndEventScopeAn activity execution terminatesactivityLifecycle
ActivityFailureEventScopeAn activity failedactivityLifecycle
CompensationHandlerRegisteredScopeA compensation handler gets registered on a scopescopeHandling
CorrelationMatchEventProcessA matching correlation has been found upon reception of a messagecorrelation
CorrelationNoMatchEventProcessNo matching correlation has been found upon reception of a messagecorrelation
CorrelationSetWriteEventScopeA correlation set value has been initializeddataHandling
NewProcessInstanceEventProcessA new process instance is createdinstanceLifecycle
PartnerLinkModificationEventScopeA partner link has been modified (a new value has been assigned to it)dataHandling
ProcessCompletionEventProcessA process instance completesinstanceLifecycle
ProcessInstanceStartedEventProcessA process instance startsinstanceLifecycle
ProcessInstanceStateChangeEventProcessThe state of a process instance has changedinstanceLifecycle
ProcessMessageExchangeEventProcessA process instance has received a messageinstanceLifecycle
ProcessTerminationEventProcessA process instance terminatesinstanceLifecycle
ScopeCompletionEventScopeA scope completesscopeHandling
ScopeFaultEventScopeA fault has been produced in a scopescopeHandling
ScopeStartEventScopeA scope startedscopeHandling
VariableModificationEventScopeThe value of a variable has been modifieddataHandling
VariableReadEventScopeThe value of a variable has been readdataHandling

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

Process-Level Filtering

Using the It is possible to tweak event generation to filtrate which ones get created. First, events can be filtered at the process level using one of the following stanza:

<dd:process-eventsgenerate="all"/>
    <!-- Default configuration -->
    <dd:process-eventsgenerate="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 behavior; when nothing is specified in the deployment descriptor, all events are generated. The third form lets you define which types of events are generated. The possible types are: 

  • instanceLifecycle
  • activityLifecycle
  • dataHandling
  • scopeHandling
  • correlation
Scope-Level Filtering

It is also possible to define filtering for each scope of the process. This overrides the settings defined in 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:deployxmlns:dd="http://www.apache.org/ode/schemas/dd/2007/03">
    ...
 <dd:process-eventsgenerate="none">
    <dd:scope-eventsname="aScope">
        <dd:enable-event>dataHandling</bpel:enable-event>
        <dd:enable-event>scopeHandling</bpel:enable-event>
    </dd:scope-events>
    <dd:scope-eventsname="anotherScope">
        <dd:enable-event>activityLifecycle</bpel:enable-event>
    </dd:scope-events>
 </dd:process-events>
    ...
</dd:deploy>

Note

It is futile to enable an event associated with the process itself, when filtering events on scope. 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 which has event filters (up to the process). The full list of selected events gets inherited; not each event definition individually.

Event Listeners

WSO2 BPS allows to register your own event listeners to analyze all produced events and perform desired actions with them.

To create a listener, simply implement the org.apache.ode.bpel.iapi.BpelEventListener interface. Then add the implementation in the server's classpath ($CARBON_HOME/repository/components/lib) and add a property in bps.xml bye specifying your fully-qualified implementation class name:

<tns:WSO2BPSxmlns:tns="http://wso2.org/bps/config">
  ...
    <tns:EventListeners><tns:listenerclass="org.wso2.bps.samples.eventlistener.CustomEventListener"/></tns:EventListeners>
  ...
</tns:WSO2BPS>

You can try the sample event listener that is shipped with WSO2 BPS by adding the above configuration to the bps.xml and restarting the server. The source of the sample implementation of event listener can be found here.

 

  • No labels