jBPM 6 comes with an excellent deployment model based on knowledge archives which allows different versions of given project to run in parallel in single execution environment. That is very powerful but at the same time brings some concerns about how to deal with them, to name few:
While there might be other concerns, one of the most frequently asked question is such situation is: can I migrate active process instance?
So can we do process migration with jBPM?
While the first two options are simple, the third one might require some explanation. What is node mapping? While doing changes in process versions we might end up in situation that nodes/activities are replaced with another node/activity and by that when migrating between these versions mapping needs to take place. Another aspect is when you would like to skip some nodes in current version (see second example).
- shall users run both old and new version of the processes?
- what shall happen to already active process instances started with previous version?
- can active versions be migrated to newer version and vice versa?
While there might be other concerns, one of the most frequently asked question is such situation is: can I migrate active process instance?
So can we do process migration with jBPM?
The straight answer is - YES
... but it was not easily available to be performed via jbpm console (aka kie-workbench). This article is about to introduce solution to this limitation by providing ... knowledge archive that can be deployed to your installation and simply used to migrate any process instance. I explicitly use term "migrate" instead of upgrade because it can actually be used in both directions (from lower to higher version or from higher to lower version).
So there are quite few things that might happen when such operation is performed. All depends on the changes between versions of the process definition that are part of the migration. So what does this process migration comes with:
- it can migrate from one process to another within same kjar
- it can migrate from on process to another across kjars
- it can migrate with node mapping between process versions
While the first two options are simple, the third one might require some explanation. What is node mapping? While doing changes in process versions we might end up in situation that nodes/activities are replaced with another node/activity and by that when migrating between these versions mapping needs to take place. Another aspect is when you would like to skip some nodes in current version (see second example).
NOTE: mapping will happen only for active nodes of the process instance that is being migrated.
Be careful what you migrate...
Migration does not affect any data so please take that into account when performing migration as in case there were changes on data level process instance migration will not be able to resolve potential conflicts and that might lead to problems after migration.
To give you some heads up about how does it work, here comes two screencasts that showcase its capabilities in actions. For this purpose we use our standard Evaluation process that is upgraded with new version and active process instance is migrated to next version.
Simple migration of process instance
This case is about showing how simple it can be to migrate active process instance from one version to another:
- default org.jbpm:Evaluation:1.0 project is used which consists of single process definition - evaluation with version 1
- single process instance is started with this version
- after it has been started, new version of evaluation process is created
- upgraded version is then released as part of org.jbpm:Evaluation:2.0 project with process version 2
- then migration of the active process instance is performed
- results of the process instance migration is the illustrated on process model of active instance and as outcome of the process instance migration
Process instance migration with node mapping
In this case, we go one step further and add another node to Evaluation process (version 2) to skip one of the nodes from original version. So to do that, we need to map nodes to be migrated. Steps here are almost the same as in first case with the difference that we need to go over additional steps to collect node information and then take manual decision (over user task) what nodes are mapped to new version. Same feedback is given about results.
Ready to give it a go?
To play with it, make sure you have jBPM version 6.2 (currently available at CR level from maven repository but soon final release will be available) and then grab this repository into your jbpm console (kie-wb) workspace - just clone it directly in kie-wb. Once it's cloned simply build and deploy and you're ready to migrate any process instance :).
Feedback, issues, ideas for improvements and last but not least contribution is more than welcome.
