In a recent project, I was faced with several versions of a process model and a lot of instances for each version. This increased the work of keeping every case in mind for example when it came to new backend developments (which are centralized and have to work for all versions). I had the idea of simply migrating all older instances to the latest version to keep life simple.
I checked out Camundas Version Migration Plugin for Cockpit because I was hoping to get some order in the mess. Here is what I did.
First of all, I installed the plugin. For that, I cloned the project and simply built the jar using mvn install. After that I found the jar in the target folder.
I put that jar into the lib folder of camunda on my tomcat (../apache-tomcat-7.0.62/webapps/camunda/WEB-INF/lib/) and started the server. The cockpit plugin appears as a newly added tab in instance view, see picture below.
If you havent had a strange feeling about version migration in your stomache already, you will have it now, reading „you are playing with fire!“. I strongly recommend reading the linked Risks and Limitations section, you can find on git.
Brave as I am, I started playing with fire.
My first step was to deploy a simple one-usertask-process and to start several instances for migration:
Done that, I slightly changed the process model and deployed it in a version 2. I just added another usertask. After deployment, I started the migration:
After migration, I was directly transferred into the model view of my V2, seeing the successfully deployed instance. So far so good.
Now, I improved the model by adding a check on a process variable which did not exist in previous versions:
Well, migration worked, but as you can imagine, after completing usertask 2, I was left with this message:
Don’t panic! This is not an migration error, but a normal process-model-isn’t-very-sophisticated-error. The instance just rolled back to the last transaction – usertask 2. After adding the demanded variable (simply use cockpit/tasklist) the process instance ran just fine.
As you might have noticed, I also added a service task, calling a delegate. I even used that same delegate as a execution listener on usertask 2 (event type: end) where the activity/token was waiting atm. After migrating instances to that version I successfully tested that delegate-call as well.
Then I intentionally broke the recommended limitations and tried to migrate an instance, waiting at usertask 1 to a version not containing any activity going by UserTask_1. As planned it did not work:
But hey! My instance was still not burning. The migration simply was not successfull. The instance still lived in its original version.
I am keeping on playing around with business process migration and will share new knowledge. Until then:
Short conclusion:
- The subject of process migration is more stable than I thought
- Adding stuff won’t break the migration (and /or instance), as long existing activities can be found in the new version as well.
- If you mess up, you are beeing warned, the migration does not go on (no guarantee :-))
- If you did not think about needed variables in later switches, the instance will just roll back as we are used to it (no guarantee :-)).
- The Plug-In lets you migrate only on instance level. That means a lot of clicking but also more security.
- Carefully check the delta between an older version and another. Find whats new and add that. Use API, Cockpit, Tasklist for variables
- Carefully check if it is better to migrate all older versions (V1, V2) directly to the latest (V3) or to migrate from version to version (V1 -> V2 -> V3).
- Always keep that the examples above are pretty basic. You should always test production migration with similar complexity (e.g. number of activities), before pushing the button.
Before I am going to migrate instances of productive processes, I will carefully investigate them looking for existing activities (including boundary events), variables and so on.
I will test the constellations on other stages first.
I will only do that for instances of currently implemented processes because I fear the risk of overlooking / missing details of older implementations… until customer forces me 🙂
Happy migrating,
Stefan
