Database upgrades from jBPM 5.4 to jBPM 6

Introduction

I’ve recently had to convert a currently in-use production system running in jBPM 5.4 to jBPM 6.

The jBPM 6 team did make an attempt to make the upgrade process fairly easy by ensuring that they only added columns and objects. Theoretically this would mean that Hibernate’s included update process would be able to migrate the database automatically.

This almost works, but not completely. The issues are mostly in the included new drools packages involving sequencing, as well as the addition of the runtime deployment ID in the drools code where we need to manually correct the database.

You’ll need to run these fixes after the launch of the app server if you plan to use these fixes in conjunction with Hibernate’s update, so you may want to instead build up a script of the upgrade changes and avoid using Hibernate’s update altogether.

Fixing the Sequences

New Sequences

As part of jBPM 6, it seems that several entities that were previously using the default HIBERNATE_SEQUENCE are now using their own sequences. Specifically, I found process_instance_info_id_seq and task_id_seq sequences are new.

The process_instance_info_id_seq should be set to the value of HIBERNATE_SEQUENCE + 51 , for safety. This is because that sequence’s Increment By value is using the default of 50.

The task_id_seq sequence should be set to the HIBERNATE_SEQUENCE sequence’s value.

Correcting Increment By

Other sequences were previously using different default values of ‘Increment by’. It seems logical that this must be due to a newer version of Hibernate being used – previously a value of 1 was being used, whereas the default is now 50. As the sequence already exists, Hibernate does not update it.

This can cause some weird issues where, due to the HiLo sequence generator being used, identity values which are already used are generated. This then causes unique constraint violation exceptions to be thrown, specifically in sessioninfo_id_seq and workiteminfo_id_seq , both of which should be changed to increment by 50 instead of the previous 1.

Fixing Runtime Deployment Id

A runtime deployment ID is now associated with the tasks. As it is a new column, it is null for any existing tasks. This causes an issue when jBPM attempts to look up the runtime to work with the task.

You can simply set the deploymentid to an appropriate default value for your system. For example, if you’re using the singleton runtime manager, you could do:

Complete Oracle Code

Here’s my complete update script for Oracle:

 Conclusion

These corrected all of the database migration related issues I was experiencing. Leave a comment if you found any others and I’ll update the page.

Tagged with: , ,
Posted in Java
3 comments on “Database upgrades from jBPM 5.4 to jBPM 6
  1. Arif Mohammed says:

    It is a good start 🙂 Thank you.

  2. Lawrence Lai says:

    Great post! Thanks for your sharing.

Leave a Reply