I am dealing with long running cases, so I wonder what is “best practice” for instance migration, let’s say when my case model gets new activities that I want to be available for running instances as well.
My case models contains long running process tasks, so cancelling and re-creating the case instance is not an option, besides that I would loose the complete history of the case instance…
As far as I can see, this is not supported by Camunda migration API. Is there any way I can migrate case instances at all? Simply ugrading the version would be fine for the beginning, I don’t need sophisticated migration steps.
I found this old discussion with @BerndRuecker, where he pointed out a possible solution, writing my own command. But I think the issue is still persistent, even if I write that commant, the database (silently) won’t be updated anyway…
I think the situation is still unchanged - even if I haven’t double checked. So it will not be impossible to implement it yourself, but also not easy. You can also vote for the JIRA issue: https://app.camunda.com/jira/browse/CAM-7344. At the moment it is not planned and not on the roadmap. If you have a running EE subscription it would be also good to create a support ticket for the feature request.
meanwhile I created my own small CaseInstanceMigrator, which changes the version of CaseExecutions and Tasks. Because I am unfamiliar with MyBatis, I built it with JPA and it works fine when I run it standalone, outside the engine. But I am not able to produce HistoryEvents, because I am outside of any Camunda Context. When I run it inside a Camunda Command, it does not a thing - I assume JPA resp. Hibernate does somehow clash with the MyBatis stuff inside the engine.
This will serve as a workaround for some time, but I might have a look into the Camunda core and provide a simple version of a Case Migration API. Hope you will be happy to accept contributions on that area
It is a solution that is based on Spring Data and JPA and designed to work in a Camunda Spring Boot setup. But I guess you will get the idea. I even managed to make it work as a command inside Camunda.
Meanwhile I figured out, that it is not sufficient in terms of History, eventhough it creates HistoryEvents, it does not migrate the history. That is not an issue for runtime, but case monitoring in the Enterprise-Cockpit is based on History, so it will not show you the whole truth anymore. I am currently enhancing the solution with a complete history migration, but it is not yet done.
Any ideas or thoughts are appreciated! And go voting for the existing feature request, as having case migration as a core feature obviously would be the safest way: https://app.camunda.com/jira/browse/CAM-7344
My first approach now is to solve an urgent problem … but I will need to make something more robust. In this way, I will share any ideas or thoughts about implementation … special about history.
