Page Comparison

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.

...

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.

...

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

...

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>

...

...

...

...

...

...

...

Event Listeners

WSO2 BPS lets you allows to register your own event listeners to analyse analyze all produced events and do whatever you want to do perform desired actions with them.

To create a listener, you just need to simply implement the org.apache.ode.bpel.iapi.BpelEventListener interface. Then add your the implementation in the server's classpath (BPS$CARBON_HOME/repository/components/lib) and add a property in bps.xml giving 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 restart restarting the server. You can find the The source of the sample implementation of event listener can be found here.

...

...