1 of 1 people found this helpful
One of the options you have there is to use the tooling that's specifically meant for this job: https://github.com/eschabell/jbpmmigration.
But I must admit right away: this is work in progress, and if you're looking to migrate very soon it probably isn't sufficient yet. We're working hard to get it there, but we only have so much spare time...
Eric and I are very much interested in your use case, of course, since we're trying to make this tooling as useful as possible. So if you have any questions, scenarios you need support for, or anything else regarding the migration, don't hesitate to contact us!
Thanks for your pointer.
More information on my case,
1. We currently use jBPM 3.2
2. We currently design a jpdl with eclipse plugin and create a par file
3. Upon deploying the par file we'll have our processes inserted to jbpm_process_definition table
4. We have our implementaion revolving around that.
We are interested in.
1. Upgrading it to jbpm5
2. We are looking out for options to either migrating the existing data or a way to use the data.
I'm more than happy to share more information on my project and spend some time on this if needed to shape up this for the community.
Some details on the tooling can be found in the project wiki, but your jBPM3.2 is the targeted initial conversion.
I am currently putting up a page in the wiki to show the overview of what needs to be done and what has been completed, that should make this easier to follow.
Also take note of the various articles listed there, they are full of tips on what you need to watch out for to get your processes in order.
We are only focused on the migration of process definitions right now. Data migration is a whole different story.
Finally, if you have process definitions and want to submit them to us, I am more that willing to add them to the test suite which gives you a converted process based on our tooling. I changes the process details to protect their origins and have a vast set (over 80 tests) based on real life process submitted by various sources (see the project).
You are more than welcome to join the project, just see the github repo, fork / pull-requests are the modus operandi and post issues you have for us in there.
Actually you shouldn't start such a migration lightly. We already have customers doing some migration from jBPM 3.x to other Process Engines. But since basically everything has changed (database layout, API, process definition, with jBPM 5 even some core concepts) it really some change.
Currently we made best experience with a step by step approach (see e.g. http://www.bpm-guide.de/2010/12/24/using-bpmn-2-0-models-with-jbpm-3-a-migration-path-and-more/): Extract the process definition to BPMN and maybe keep the jBPM 3 by a transformation (see e.g. http://fox.camunda.com/doc/#jbpm3Bpmn). Abstract the Process Engine (with a layer like http://fox.camunda.com/doc/#peal). Afterwords exchanging the engine is more a architecture/framework thing and you can migrate process by process. There I think migrating instance data should be avoided if somehow possible, it is really complex :-)
Hi Ratnavel, definitely check out http://kverlaen.blogspot.com/2011/01/migrating-to-jbpm5.html and get involved as Eric and Maurice said. You can also ping the core devs in IRC (see http://www.jboss.org/drools/irc and also add the #jbpm channel).
Hi Bernd, nice advertising
Not sure going from engine A to engine B where A == B is truly considered an upgrade to anyone.
Maybe I did not make myself clear, I would propose to do the migration step by step. The first step indeed doesn't change the engine but prepares everything to change it in the next step. But if all your tests still run after the first step, you know you didn't break anything and have BPMN 2.0 models and a abstraction layer ready to make migrations easier. We just made very good experiences with this in big environments. Didn't say it is th only way.
And for the advertisment: Hy, it is open souce too and I was long time jBPM 3 commiter, so don't blame me for liking this engine ;-)
Tihormir: +1 ;-)
Sounds like a good way to sell lots of your services? ;-)
We are also looking for similar migration from 3.x to 5.x. Looking at lot of discussions and pages that are published for migration, i see there was lot of efforts been put in getting this migration easy and it is WIP. It looks like we need to wait for some more time if we have to use the current tools in production environment.
Few open questions i still have is
- We have the current customers on JBPM 3, If we migrate to JBPM 5, as per my understanding they still can run the old process instance using the jbpm3 api’s, if they start creating a new workflow using JBPM5 then we need to call the new api’s for execution purpose. Or is there any abstract class that does this automatically based on the ProcessDefinition/Process id that is passed or should we do this internally in the programs of JBPM.
- Will it be possible for us to do the data migration from jbpm3 to jbpm4 by comparing the database structure so that we will have only one version of workflows that we need to deal with or will it be a waste of time to invest based on the amount of change you had introduced in jbpm4/5.
Any help is appreciated.
Q quick anser, but it seems I am not really welcome in this thread (even if I don't get why, I just told what we did in the projects at customers and pointed out to some sources of open source components. Where is the big advertisment again??).
Abstracting the API is possible but not that easy. We did a small POC with the open source abstraction layer we wrote (http://fox.camunda.com/doc/#peal, http://fox.camunda.com/doc/fox-peal/). But you have to write an own binding, which is a bit of work. Biggest problem I think is operations, since they have to care about instances in different engines, which make the already not easy situation much more complex.
Instance migration on the DB level as you describe I think is too complex, because databse structure changed a lot from jbpm 3 to 4 and even more from 4 to 5. I wouldn't doubt you get that easily working, but would be very interessted if you did :-)
Can't speak for everyone, of course, but I think you've definitely contributed considerably for jBPM3 and surely know your way around. So don't feel un-welcome in any discussion about it!
Nevertheless, I think you can't blame people for not liking the fact that you more or less 'left' the JBoss/jBPM community in favour of Activiti
Good to know you guys at Camunda keep an eye open this way though; helps us to stay on top of our game!
1. No, the jBPM5 API is not compatible with the jBPM3 (or 4) API. Running jBPM3 processes requires the jBPM3 runtime, and I don't think any migration stratgey for this (like the common base class you propose) is foreseen by anyone - at this point.
As Bernd points out, migrating running process instances is going to be even harder than migrating process definitions. This is already the case when upgrading between minor versions (e.g. 3.2.2 -> 3.2.3), so between major versions (let alone a complete overhaul such as jBPM5) will be pretty impressive!
2. Migrating data will also be hard, partly due to the aforementioned API changes. But when you try something like that, be sure to separate you business data from the process execution data. That way, you should be able to make any transition as smooth as possible.
Like Bernd says: we're very interested about all migrations - successful or not. We're very much committed to making the transition from jBPM3 (the current productized version) to jBPM5 (the next version that will be part of the SOA-P) possible.