Latest release(version 2.0.0) of WSO2 BPS, includes a fix for supporting custom XPath functions based on Saxon. There was a class loading issue in the previous releases of WSO2 BPS, which breaks the custom XPath function support.

Now you can write your own custom XPath extension functions as described in Saxon’s extensibility documentation, deploy them on WSO2 BPS and use them in you process definitions.

To deploy your XPath extensions in WSO2 BPS, you need to copy them into the BPS_HOME/repository/components/lib directory.

When writing XPath extension functions, there are some special cases. For example, if you want to pass a BPEL variable(WSDL Message or XSD Element type) into your extension functions, in simplest way, you need to use net.sf.saxon.om.NodeInfo as the parameter type. According to Saxon documentations DOM Node as the input parameter also should work when you want to get a XML element as the input. but I couldn’t get it to work when I am doing tests. And if you need to access XPath processing context, you need to have XPathContext as the first parameter to your function. When you want to return XML elements from your extension functions, you can use return type as org.w3c.dom.Node.

When returning XML elements, please make sure to create them using DOM AI tried to create DOM from a string like following. But failed when evaluating XPath on the return value as well as converting that DOM to AXIOM OM when sending response back to the BPEL process caller at the integration layer.

Here is the final sample extension source.

And here is how you can use that extension inside BPEL process definition. In this sample, I am creating the response XML using this custom XPath function.

If you have any questions on custom XPath function in WSO2 BPS, please feel free to put comment on this post. You can use extension written following above guidelines in Apache ODE also. In Apache ODE case you need to copy extension JAR into Apache ODE web application’s lib directory or relevant place in your JBI based Apache ODE deployment.

What is process instance data?

When process instance start it’s execution, there are various types of information needs to be tracked and stored. For example when process receives a message process engine will create a process instance for execution and process engine must store the input message to it’s during the life time of process instance to use in intermediate steps. Like that there are various informations stored in WSO2 BPS‘s persistence storage or when process is in-memory those information will be maintained as normal Java Objects.

Process instance in WSO2 BPS keep tracks of instance state, instance variables, messages, message properties, information about message exchanges, correlations and information about execution events. So when persistence is enabled for processes all the above information will be stored in the WSO2 BPS persistence storage. So during their life time process instances will accumulate considerable amount of data in persistence storage.

From the above process instance data, messages and variable take a large percentage of space from persistence storage or from memory. BPEL processes heavily depends on the message they exchanged between partners and clients. In the middle of the process life cycle there can be various data manipulations and all those information also stored in persistence storage. These XML messages can be sizable ones some times.

So during the life time of the process engine, it can accumulate huge amount of data and this will directly effect the database performance and then to performance of BPEL engine it self. This happens because WSO2 BPS BPEL engine is tightly coupled with persistence storage for persistence processes.

To preserve the performance level we want, we may some time need to clean the above described instance data from WSO2 BPS BPEL engine’s persistence storage.

Configuring Instance Data Cleanup

BPEL packages deployed in WSO2 BPS must contain configuration file called “deploy.xml” which is local to that BPEL package and contain configuration information related to processes. In that file we can specify process instance data cleanup configuration per process.

In the WSO2 BPS 1.1.1 we only provide support for deletion of instance data after process instance is finished. And you can specify whether to delete instance data at successful completion or completion with failure or in both cases. And you can also fine tune the instance data cleanup based on instance data categories.

There five different categories of instance data:

• instance – Contains informations like created date, last active date, process id, instance state, root scope id and execution state(Data in ODE_PROCESS_INSTANCE table of WSO2 BPS persistence storage). Execution state column of ODE_PROCESS_INSTANCE contains JACOB Execution Queue as a byte array.
• variables – Process instance scope information, XML values of the variables and partner link variables. Contents of the tables ODE_SCOPE, ODE_XML_DATA and ODE_PARTNER_LINK
• messages – Information about incoming and out going messages, message exchanges information and message exchange properties. Contents of the tables ODE_MESSAGE, ODE_MESSAGE_ROUTE, ODE_MEX_PROPS and ODE_MESSAGE_EXCHANGE
• correlations – Information about correlations.Contents of the DE_CORRELATION_SET, ODE_CORSET_PROP tables.
• events – Contents of the ODE_EVENTS table.

How to Configure

Here is a sample deploy.xml file.

As shown in the above example you can specify the ‘cleanup’ configuration under ‘process’ element of deploy.xml file. And the cleanup configuration’s XML schema is given below.

Let’s look at some examples of instance data cleanup.

Cleaning up all the data on successful or failed instances

Cleaning up all the data on successful completion of instances

Cleaning up all the data on successful completions and messages and correlations of faulty completions

Effect of process instance data cleanup

If you run WSO2 BPS without any cleanup of process instance data, it’ll effect the performance of database and then the throughput of WSO2 BPS. Response time of the process instances will also increase due to this. The best way to avoid this type of performance degradation is by configuring processes to cleanup process instance at completion. You can also write your own tools using instance management API to delete process instances periodically.

Future of instance data cleanup

In the latest version of WSO2 BPS we only provide deletion of process instance data after process instance execution is finished. But this is not enough in production environment. Users may need to keep the instance data for some time for auditing purposes and delete process instance data after several days. For example they may want to keep successful process instance information 3 days and failed process instance information 5 days. Also they may want to change this configuration process wise. So we are planning to introduce this support in next version(2.0) of WSO2 BPS.

WSO2 Business Process Server team released the latest version(1.1.0) of WSO2 BPS yesterday 19th November 2009.  As the successor of WSO2 BPS 1.0.1, WSO2 BPS 1.1.0 comes with handful of new features which will make process developer’s life easier.

WSO2 BPS 1.1.0 uses revision of Apache ODE trunk which is going to be the future of Apache ODE BPEL engine as it BPEL engine. In addition to that there are several bug fixes to the Apache ODE like fixing E4X extension support when using OpenJPA data access objects. WSO2 BPS 1.1.0 comes with a completely new integration layer for Apache ODE which integrated ODE with WSO2 Carbon platform. Now the previously unsecured BPEL management API is completely secured based on WSO2 Carbon authentication mechanism and new version has a completely re-written Web service API for managing your BPEL engine. There are some improvements to be done on the management API and those will be available with the upcoming releases.

By leveraging the extension mechanism of new ODE engine, now you can extend WSO2 BPS’s BPEL language by introducing your own extension to BPEL language and deploying them on WSO2 BPS.

This version of WSO2 BPS has the provisioning support based in Equinox P2; now users can extend the BPS by installing features available in WSO2 Carbon P2 repositories. For example by installing mediation feature, you’ll be able to do service mediation using WSO2 BPS.

Here is the list of new features available in WSO2 BPS 1.1.0

• Apache ODE trunk’s revision is used as the BPEL Engine
• New WSO2 Carbon integration layer for Apache ODE
• BPEL Process Versioning Support
• Support for invoking secured(Using WS-Security) partner services.
• Experimental clustering support
• Invoke activity recovery support through management console
• E4X based data manipulation support for BPEL assignments
• BPEL Extension support for extending WS-BPEL language
• Equinox P2 based provisioning support –  extend your BPS instance by installing new P2 features [5].

You can download this release at http://wso2.org/downloads/bps.

When two different BPEL processes deployed in Apache ODE need to communication with each other, Apache ODE bypass the integration layer and directly talks to the process from another process. But we recently discovered that when one process is in-memory and other process is persisted, there will be a class cast exception when engine invokes the in-memory process in P2P manner from persisted process or other way around(in-memory process invokes persisted process).

This happens at the DAO layer. Even though data access layer was implemented using several abstraction level, this error cannot be handle by those abstractions. Here is the code fragment which handles Process to Process communication in ODEProcess class.

The problem occurred when we trying to set the request to my role message exchange object. The request must be a implementation of MessageDAO interface. myRoleMex object returned from ODEProcess’s createMessageExchange method will depend on the persistence type of that process. If it’s a JPA based persisted process it’ll return a object of org.apache.ode.bpel.jpa.MessageExchangeDAOImpl class. When setting the request attribute of that class it’ll try to cast that object to org.apache.ode.dao.jpa.MessageDAOImpl. But the request generated from in-memory process is object of org.apache.ode.dao.memdao.MessageDAOImpl class, so that the class cast exception will be thrown. In this situation we can’t use in-memory implementation’s MessageDAO object with JPA based DAO implementation because annotations and some other details required for JPA will not be there in the in-memory DAO implementation.

So when there are process to process communication in you BPEL processes, users must  avoid deploying one process in-memory and other process persisted. If your processes are deployed in two different Apache ODE instances, this thing doesn’t have any effect.

Most of the time business process are long running and implemented in asynchronous style. But there may be situations that we are using synchronous business process which are not long running. So client expect a response  back from the server without a time out. This response can be a SOAP fault. The main thing is, clients must get a response back even process failed during execution.

Apache ODE has this nice feature called activity recovery support for BPEL invoke activities. If external service invoke failed due to unavailability of end point, due to a SOAP fault or domain name resolution error, user can retry this activity after the errors in external services are fixed.

If the process operations are synchronous, client will get time out error if invoke activity failed during execution in normal case. This not good thing for synchronous operation. Client must get a fault as a response if invoke activity failed during synchronous operation. So you if your process operations are synchronous and you need fault reponse if invoke activity failed during process execution, you need to disable activity recovery feature and set fault on failure to true. This can be done using following code snippet in a BPEL scope which has invoke activity.

Here is a sample BPEL process that use the above feature.