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 -
SHOULD BE
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.
