How do I generate sql scripts for process definition deployment in jBPM?

Question

I'm looking into integrating jBPM with my current project, so far so good just including the jpdl jar in my ear and using the spring modules 0.8 jbpm module, however I've got to have a reasonable way of going from my changes to to the process definition in the designer to deployment in production.

The path has to be repeatable in a number of environments (dev, many test, staging and then prod) and ideally should be done while the system itself is not running.

I'd Ideally package the entire definition as an SQL script, however I haven't seen any tool to translate from processdefinition.xml to sql and assembling it all manually seems too fiddly and error prone.

Has anyone else out there had any experiences here?

The system is running on websphere 6.1 and it's my preference to avoid executing java code at migration time (running java code to generate artifacts that can then be used during migration is ok though)

Answer 1

Why not use the ant task extensions provided by JBPM specifically DeployProcessTask. You can deploy to different environments having just a single .par file and the corresponding jbpm-cfg.xml for the various dev/test/staging/prod environments. The only change you might have to do is to configure your hibernate config to directly connect to the database instead of using the datasource.

Answer 2

If you want to avoid going down the .par route, it's easy to write some simple Java code to deploy a new process definition version to your database. Something like

JbpmConfiguration jbpmConfiguration = JbpmConfiguration.getInstance("jbpm.cfg.xml"));
ProcessDefinition processDefinition = ProcessDefinition.parseXmlInputStream(newPdStream);
JbpmContext context = jbpmConfiguration.createJbpmContext();
context.getGraphSession().deployProcessDefinition(processDefinition);

You'll need to have the hibernate.properties or hibernate.cfg.xml for the relevant database on the classpath.

What's great about this way is that all of the versioning stuff is done for you automatically. We used to use a hack where we modified the process definition (basically ignoring versioning), but it was a big huge mess for process instances which were active at the time.

Answer 3

Workaround suggestion: deploy and intercept sql queries

I haven't tried this but I would suggest to try use the deployment of the jBPM-console deploy servlet or

context.getGraphSession().deployProcessDefinition(processDefinition);

as suggested by shyamsundar

AND

log the sql updates with LogDriver: http://rkbloom.net/logdriver/logdriver.tar.gz