Until now, how to package a jBPM web application for deployment into SOA-P has been a source of confusion. In particular, it has never been clear whether the WAR should include the process definition or any jBPM libraries or configuration files. The objective of the present article is to clarify and establish a best practice.

Deploy the process definition(s) separately

Process definitions, being longevous artifacts, saved in an external database and unattached to the lifecycle of the web application or the application server itself, should be deployed separately from the web application. It is advisable to deploy the process before the web app so that the application can comfortably operate under the assumption the process is available at all times.

Options for process deployment include the GPD deployment tab,  the JSF console upload form and the Ant DeployProcessTask.

Do not include jBPM libraries

In SOA-P, the jbpm.esb module already provides the libraries and configuration files required to run jBPM applications. Sticking with the provided versions and settings comes with the benefit of the extensive Quality Engineering effort spent by Red Hat, and prevents issues such as class loading conflicts or configuration mismatches.

Give alternate configuration files a unique name

In multitenancy use cases, a single application server installation hosts separate applications which require different configurations. The suggestion here is to give each configuration file a unique name other than jbpm.cfg.xml, to avoid overriding the default configuration file provided with the platform.