How to use Hibernate as the persistence layer for Apache ODE/WSO2 BPS

Note: In order to run ODE/BPS under Hibernate, you will have to include external dependencies (and accept Hibernate LGPL license).

By default, Apache ODE/WSO2 BPS uses OpenJPA as the persistence layer, but also includes implementation for Hibernate as well. For switching to Hibernate add the following system propety. (For WSO2 BPS you can do it via $CARBON_HOME/bin/wso2server.sh)
-Dode.persistence=hibernate \

Make sure you have copied the required Hibernate jar to $CARBON_HOME/repository/components/lib directory.
If you are getting errors at server start up, check whether the necessary tables have been automatically created by Hibernate. If not, you can use a script to manually create the tables (similar to the following used for MySQL DB)  Note Hibernate has slightly different database schemas and also uses "BPEL_" prefix in table names instead of "ODE_" prefix.
If you are using a DB other than Apache Derby, H2, MySQL or Oracle, and having trouble resolving the DB dialect from the database product name, you can manually set the HIBERNATE_DIALECT in org.apache.ode.daohib.bpel.BpelDAOConnectionFactoryImpl class. For implementation details see dao-hibernate and dao-hibernate-db modules in Apache ODE source.

Related discusson on "Switch to the hibernate DAO layer" mail thread.

ReplyTo header in Unified Endpoint configuration of WSO2 BPS

In a BPEL process, when there is an invoke to an external synchronus web service, and if you want to send the response of this service to a different endpoint (rather than sending back to the BPEL process), you can use Unified Endpoint configuration of WSO2 BPS 3.0.0 to set the WS:Addressing ReplyTo header as follows:
You can refer to this config file (locatd in registry or in the file system) as follows, inside the deploy.xml file:
There are other use cases of UEP like adding QOS, Security etc. You can read more on that here.

Use of 'DynamicImport-Package: *' in OSGi

In OSGi, 'DynamicImport-Package' attribute is used in the MANIFEST.MF file to specify the patterns of packages that are not found in the normal bundle contents or Import-Package field. If the package is not available in the initial resolution process, it will not fail, but will be attempted to resolve every time a class from the package is required.

 'DynamicImport-Package: *' is a trick used by bundles to allow importing client packages which are not known during bundle build time, in addition to its own dependencies, to prevent ClassNotFoundException issues. [i.e. If there are classes which have Class.forName (or other dynamic look up)] This turns OSGi Framework into a very expensive class path for the packages involved and breaks the concept of versions in OSGi. Use of this attribute is said to be a sign of a non-modular design and it might be a good time to revisit the architecture.

To learn more:

• DynamicImport-Package - OSGi Community Wiki http://wiki.osgi.org/wiki/DynamicImport-Package
• What is the difference between bootdelegation and DynamicImport-Package in osgi http://stackoverflow.com/questions/14729568/what-is-the-difference-between-bootdelegation-and-dynamicimport-package-in-osgi
• If code uses Class.forName (e.g. hibernate) consider DynamicImport-Package https://github.com/bndtools/bnd/issues/80

How to make use of WS-Addressing ReplyTo header in an Asynchronus BPEL Process

In Apache ODE or WSO2 BPS, if you are looking for a way to asynchronously call back from a BPEL process, after the process is finished, to an reply address dynamically provided in the Request Message with WS-Addressing headers, you can copy the wsa:Address from the ReplyTo header, to the partnerLink related to the final invoke as follows:

If you're testing this with SOAP UI, make sure you include wsa:Action, wsa:To, wsa:ReplyTo and MessageID in the request. Otherwise you will get an error similar to 'org.apache.axis2.AxisFault: A required header representing a Message Addressing Property is not present'
You can read more here about Using WS-Addressing in SOAP UI
Hat-tip: From Apache ODE mail archives, Related question from StackOverflow

How to clean up Instance data for a given BPEL Process Instance ID from Apache ODE/WSO2 BPS

This is a stored procedure that can be used to delete all the instance related data from the DB for a particular BPEL instance.

How to find BPEL Process Instance ID from Correlation Property Value in Apache ODE/WSO2 BPS

This is a small SQL query to retrieve Process Instance ID from the DB, when we know a Correlation Property Value, for a simple case where the correlation set consists of only one property.

SELECT PROCESS_INSTANCE_ID FROM ODE_SCOPE WHERE SCOPE_ID IN (SELECT cs.SCOPE_ID FROM ODE_CORRELATION_SET cs WHERE cs.CORRELATION_SET_ID IN (SELECT os.CORRSET_ID FROM ODE_CORSET_PROP os WHERE os.PROP_VALUE='$CORR_PROP'));

Here, use the respective correlation property value instead of $CORR_PROP

Using Log4j MDC (Mapped Diagnostic Context) in an Axis2 module

Mapped Diagnostic Context (MDC) is a thread-local key-value store that can be accessed from a Log4j conversion pattern. It can be used very effectively in web applications where one log serves several clients or users, to differentiate the log statements related to each client or request. In this example, the service a message is destined to, will be logged right next to the time of the log message, as the variable "service" in the MDC (referenced by %X). To make this work, you can put the Service name into the MDC, using the static method MDC.put(key, value).

MDC.put("service",messageContext.getAxisService().toString());

To use the MDC, you have to put a placeholder into the respective Log4j conversion pattern in lib/log4j.properties:

log4j.appender.CARBON_CONSOLE.layout.ConversionPattern=[%d{ISO8601}] [%X{service}] %5p - %c{1} - %m%n