Fork me on GitHub

n. Slang a rough lawless young Kuali developer.
[perhaps variant of Houlihan, Irish surname]
kualiganism n

Blog of an rSmart Java Developer. Full of code examples, solutions, best practices, et al.

Monday, August 27, 2012

Automating Workflow XML Ingestion


Workflow objects are stored persistently in your RDBMS. These are complex objects with complex rules. There's just no practical way to update your RDBMS to make changes to your Workflow configuration directly. At this time, the best way to update your workflow configuration is via the XML Ingester. It's an excellent tool because of all the great debugging feedback it gives; however, it lacks automation capabilities. If we want to deploy remotely via Jenkins or something else, it's a little unhandy.

This post is to explain how to easily setup your Kuali application to automatically deploy workflow changes on environment startup. The real hero here is the builtin xml polling in Rice.


This is the change process that is followed for delivering a workflow configuration change to an environment.

1 Job for Polling Changes on trunk

In Jenkins, you can create a job specifically intended to poll for changes. What we want to do is poll for changes to our workflow path. If we are storing workflow changes in somemodule/src/main/resources/myinstitution/rice/somemodule/document/workflow/, we can set our jenkins job to poll for changes here.

2 Copy Updates

You then want to copy the modified workflow files to a location where they are packaged into a zip artifact.

3 Deploy zip Artifact

Now that we have the packaged changes, the only thing left is to push them out to the specified environment.

Here's a visual:

Here's a overview of the release flow for getting your changes out with a release:


As I mentioned before, the work is all done by Rice with the org.kuali.rice.kew.batch.XmlPollerServiceImpl. All you need to do to get it to work is setup the following in your rice-config.xml or the configuration file of whatever application you're using (kc-config.xml for example).

For versions of rice prior to 2.3.x use:
<param name="kew.xml.pipeline.lifecycle.enabled">true</param>
instead of
<param name="xml.pipeline.lifecycle.enabled">true</param>


These are the scripts I used which I described above


Now you should be able to setup some automation so you environment can automagically deploy workflow xml that is changed with each commit/release.

1 comment:

  1. I am sure it will work for many out there, it is good to see a valuable content from your side.