Pages

Monday, July 13, 2009

Creating a jBPM process repository for unit testing with par files

My latest project involves general infrastructure improvements based on my experiences with jBPM. There have been many discussions about different aspects involving a generic process structure to enable the launching of new products in a more efficient, timely, and cost effective manner.

One of the more interesting elements in the general planning is to provide the development organization with a process repository. It will enable developers to leverage the existing Maven infrastructure to provide projects with exiting Process Archives, better known to jBPM developers as PAR files.

These files are similar to JAR files and contain the process definition along with any supporting Java classes needed to run. The interesting part is that you want to define simple process components (granularity is important) so that they can be leveraged through reuse. The idea then being that a new project can simply shop for existing process components and then import these exiting PAR files into a project where they plug into the project in process-state nodes (these being the jBPM sub-flows).

This requires that a simple process is the initial building block and needs to be setup with proper unit testing. For example, a simple process (which is left empty for posting purposes) that is used to transform input into some XML format via a single web service call. This call takes place in a state node, so you can see the process definition of the SuperProcess which calls the self contained SubProcess by fishing it out of the PAR repository included in the projects dependencies.

Of course these are really simple examples. We are looking into unit testing much more complex processes that include task-nodes, state-nodes, and processes with several layers (deep) of process-states. Anyone have experiences with these kinds of unit tests?