Thursday, April 19, 2012

WS-BPEL 2.0 Extension Activity Development for WSO2 BPS

There are several ways to extend WSO2 BPS runtime functionalities such as
  • BPEL extension activities
  • Custom XPath extensions
  • Message Exchange Interceptors etc.

BPEL extension activities enable a pluggable architecture that allows for registering third party functionality to the WS-BPEL 2.0 execution runtime.
There are several BPEL extension activities supported by WSO2 BPS and with the upcoming WSO2 BPS 3.0.0 release, we are going to introduce several new BPEL extension activities such as

Here I have written a simplest extension activity implementation with a sample BPEL process so, a BPEL developer can re-use and extend it to have their own implementation.
The extension activity implementation can be found from

To come up this implementation, I followed this blog-post from Waruna Ranasinghe and it brings you more in-depth knowledge on BPEL extension activity development.

Friday, April 13, 2012

Wishing you a very happy new year 2012!

Since it is the festive season of Sinhala and Hindu new year for all Sri Lankans, I wish you all a happy and prosperous New Year 2012!. Also my team is celebrating the new year dawn with their loved ones except for few guys at on-site work outside LK.

With just the beginning of the vacation, we spent few days at Heritence Ahungalle, a beach hotel on the west coast of Sri Lanka. I had a luxury suite thanks to a good old friend from school days :). But we spent most of the time in the swimming pool and the beach due to the hot and humid weather.
Also the hotel is quite renowned for its sustainable building architecture by Geoffrey Bawa.

Related Posts

Thursday, April 12, 2012

Development and Deployment Best Practices for WSO2 BPS

This post contains an updated version of best practices related to developing and deploying business processes on WSO2 BPS (Business Process Server).

Table of Content
  • Deployment best practices
  • Development best practices
Deployment best practices
Default distribution of WSO2 BPS comes with embedded H2 database as BPEL engine's persistence storage and other settings which are suitable for use in development environment. But when you are going to production with WSO2 BPS, there are several configurations you need to change according to your production requirements. These configurations will change based on how much requests BPS is going to handle per second, your auditing and monitoring requirements, performance requirements and nature of your process. Following are the main things you should do before going production with WSO2 BPS.
  • If the deployed BPEL processes has any conflict like
        - Same BPEL process is deployed under several different package names
        - When a deployed BPEL process has an existing service name
    Those deployment issues are displayed under the relevant package in "Deployed Packages" page.
  • Configure external database server like MySQL as your persistence storage instead of embedded H2 database. You may experience slight performance gain for simple BPEL processes with H2 database, but when it comes to multiple concurrent requests and complex processes H2 can't server your performance needs.
  • Configure multi-threaded Http connection manager connection pool settings to suits to your BPEL processes. There are two configurations in Http connection manager. One is max total connections and other is max total connection per host. These settings will depend on number of concurrent requests BPS needs to handle and number of external service calls incorporated per process instance.
  • Configure BPEL process persistence - If you are implementing processes with request-response interaction model use in-memory processes instead of persistence processes. Whether to use in-memory or persisted processes will mainly depends on your business use-case.
  • Configure even-filtering at process and scope level. So you can save lot of database resources by reducing number of events generated.
  • Use process-to-process communication, if you are calling one BPEL process from another BPEL process deployed in the same BPS instance, it's better to use process-to-process communication to reduce overhead introduce by additional network calls.
  • In the default WSO2 BPS distribution, the size of a fault message (which is stored in BPEL DB) is limited to ~4KB.

    eg - See the following BPEL database SQL script
    So if a deployed BPEL process is expected to handle larger size of fault messages, the above database script should be modified and re-built from the source distribution accordingly.
  • Also make sure to configure process instance cleanup. Large number of process instance data will be accumulated in the BPEL engine persistence storage if you persisted processes, so to reduce performance overhead introduced by database size you should configure instance cleanup.
  • In addition to above things you should be careful when deploying WSO2 BPS in virtualized environments. We have seen random increase of network latency and random performance degradation when running on VMs.
  • If the BPEL is going to be deployed as a WS-secured service then, it's recommended to remove all the http endpoints from the process WSDL. Else the WSDL generation for the particular BPEL process will get failed.

    eg -
Note 1: Above mention configuration optimizations are true for Apache ODE also.

Note 2: Above mention best practices are valid for WSO2 BPS 3.0.0-SNAPSHOT and upward. You can do the above optimizations to older versions WSO2 BPS, but configurations and configuration mechanisms will be different. All of the above optimizations are supported by Apache ODE, but configuration is very different from WSO2 BPS.

Development best practices
When it comes to BPEL development in WSO2 BPS, BPEL developer need to aware some scenarios which could lead to some conflictions. Those are listed as follows.
  • It's not encouraged to refer the same variable as the input(in <receive/>) and output(in <reply/>) of the process. This could lead to problems if the message headers (<Header/> in SOAP <Envelope/>) in output variable are processed at the client-end. One possible use-case is when the process is secured if the input and output variables are same then the headers of the input will be used when the output is sent back to the client. So it could prone to errors if those security headers are not expected at the client end.