JBPM 4.4 vs JBPM 6.2

0
votes

I am planning to use advance version of JBPM i.e. JBPM 6.2. Currently my project is using JBPM 4.4 but there are issues with JBPM4 DB tables which are accessed internally by JBPM API. I need inputs regarding this udgradation activity:

  1. Since existing workflows will be continue to use. So is there any impact on existing workflows implemented by JBPM 4.4?
  2. Both the versions will use same JBPM tables or will be different tables?
  3. What are advantages of JBPM 6.2 over JBPM 4.4?
  4. What are up-gradation steps to be carried out without impacting existing one?
1
javajakarta-eejbossjbpm

1 Answers

7
votes

Unfortunately the jBPM 4.4. codebase is an entirely different codebase. With jBPM 5 RedHat actually rebranded the old Drools Flow project to become jBPM 5. It uses an entirely new database and persistence design to store process and task data. So to answer your questions:

  1. If by "Workflows" you mean existing ProcessInstances, the bad news is that your old ProcessInstances will not work with jBPM 6 at all. If by "Workflows" you mean ProcessDefinitions, there is a migration utility available (see http://www.schabell.org/2010/10/jbpm-migration-strategies-process.html)
  2. Entirely different tables, and I am not aware of a migration tool to fix that.
  3. As far as I know, RedHat never provided subscriptions to support jBPM 4. RedHat only provided support up to version 3, then skipped version 4 to support 5 and 6 again. There are many reasons for this, but suffice it to say that the jBPM4 codebase came to an end and there is very little if any activity there. jBPM 6 is an extremely active codebase. Lots of energy and innovation here. It comes with a solid web based tooling to complement the Eclipse tooling. You can model your processes, model your forms for tasks, build and deploy, all of this from the web interface. It uses git in the brackground to store resources and is fully clusterable. All of this is great, but I would say the lack of activity in the jBPM 4.4. codebase is enough to move on. You'll struggle to get support from the community for it.

  4. That is the $1000 000 question. I would suggest

    4.1. Convert your jpdl files to BPMN files, and develop all new process in BPMN.

    4.2. Migrate your system and implement the code to use the jBPM 6 RuntimeManager API and Task tables, perhaps using the tool mentioned in the link above)

    4.3. For task lists, aggregate tasks from both the old and new tables

    4.4. Keep both environments running in parallel until you have phased out all jBPM 4 processes.

Unfortunately, as far as I know, there is no quick and easy way to do it. Good luck!