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.


Denis Weerasiri said...

bpel developer online training| bpel developer training| call ...
Developer Online Training, BPEL Developer training, BPEL Developer
course contents, BPEL Developer Employees to learn at their own pace and
maintain control of learning “where, when and how” with boundless
access 24/7by 21st Century Software Solutions.
---- Call Us +917386622889

Denis Weerasiri said...

Hello, i am new to BPEL .
can u please give me instructions for BPEL accessing databse MYSQL from eclipse IDE

Denis Weerasiri said...

I did not get your question. Are you trying to access a MySQL DB from a BPEL workflow?
Or are you trying to model a BPEL workflow from Eclipse IDE?

Denis Weerasiri said...

Than's for your reply,
yes, how would i access mysql databse from BPEL. Is it possible or.

Denis Weerasiri said...

How BPEL support Database accessing? is my main question.

Denis Weerasiri said...

WS-BPEL specification only allow you to interact with web service interfaces (eg- WSDL based services). Hence if you need to access a DB, first you need to wrap that DB as a data service. This is one framework that helps you to wrap your DB as a Web service (
Once you wrap it, BPEL can talk to the data service and extract data from the DB.

Denis Weerasiri said...

Thank's a lot Dennis,

Now i got Idea about this concept.