How to handle new releases when we have active process instances?

[ppalacean]

Hi all,
we have a setup where in a single web application we have: all the bpmn files, the Java delegate classes, the model classes that are used for Java objects put on the process and the DTOs used by REST API calls or to map their response. A new deploy just removes the old application and deploys the new one, so old delegates, model classes, DTOs are no longer available (being replaced with the new ones with the same name).

We will do the first release into production soon, but this got us thinking how would we handle the next release into production since we don’t want running process instances to fail after a new release because:

• we changed the logic implemented in the delegates
• we changed the contract of the REST API and the request/response bodies
• we added some variables on the process that the delegates would use later but these variables would not exist on the currently running instances
• we have de-serialization issues if we changed the model classes and the de-serialization is no longer possible.

Are there some rules to follow to avoid these issues?
I’ve read about Process Migration but this is not solving the problem.

Best regards,
Paul Palacean

[techavidity]

Please refer the old thread we talked about Process definition update.

How to update process definition?

Hi, I’m struggling to figure out how I can update the XML of an existing process definition using the process engine. We are embedding a process engine and I am using the process engine APIs directly. I only see in the RepositoryService a method to create deployment. The only update methods I can see to process definition are to update the active/suspended state and not the XML. I tried looking through all documentation and code for the redeploy rest endpoint, but that does not allow to specif…

[tmetzke]

Hi @ppalacean,

Whenever possible, we recommend that you avoid to version other artifacts beyond the process, case and/or decision definitions. If you have to do so, there are various options to do that:

1. Keep the artifact backwards compatible, meaning to extend the functionality of e.g. a method in MyClass.java in a way which can still deal with “old” process instances.

2. Introduce a switch for different versions, meaning to extend the functionality of e.g. task-form.xhtml in a way which can still deal with an “old” process definition.

3. Introduce a new artifact for different versions, meaning to change the functionality of e.g. task-form.xhtml by adding a new version to the application and referencing it from the new version of the process definition, while the old version will continue to use the first version of the form. Of course, this approach would be applicable for other artifacts, too, as e.g. MyClass.java.

Hope this helps you in deciding on how to approach your future updates.

Best,
Tobias