I am challenged by versioning java delegates in process archives.
Situation:
Archive “processV1” containing:
process100.bpmn (process-key: “process”)
JavaDelegate100.class
Some process instances are started, everything fine. Now I have to fix some bugs in the process definition and the delegate class, which should only affect NEW process instances. The process-key stays the same. The new process version is a substitution for the old process version. So I create archive #2:
Archive “processV101” containing:
process101.bpmn (process-key: “process”)
JavaDelegate101.class
Now I have a problem: Somehow the old instances in the old process version do not work any more. The java delegate class “JavaDelegate100” cannot be found. I suppose that the engine sees only the classloader of the new process archive since the process keys are the same. (If I also put JavaDelegate100.class in archive #2, everything works)
Can anyone help me understand the problem? Is my way to understand and handle the process versioning wrong?
I’ll try to explain the behavior you see. Whenever you deploy a process application, a new deployment is created (or not, if no processes have changed). In addition, a new process deployment resumesprevious deployments. The process engine has an internal registry of which deployed application contains the resources (e.g. classes) for which processes. Resuming means, that the process engine creates entries in this registry for previously existing deployments (overwriting existing registrations). A deployment qualifies as a previous deployment, if it contains processes with the same key (by default; this is configurable). For details, see this section of the docs: https://docs.camunda.org/manual/7.6/user-guide/process-applications/the-processes-xml-deployment-descriptor/#process-application-deployment
Now the way you attempted to handle multiple class versions, you had two deployed applications A1 (containing version 100) and A2 (containing version 101). First, A1 is deployed, the engine registers A1 for the new deployment d1. Then, A2 is deployed, the engine registers A2 for the new deployment d2. Since d1 qualifies as the previous deployment for d2, it also registers A2 for d1, overwriting the existing registration. In consequence, the JavaDelegate100 class is no longer found.
Your solution to the problem, i.e. having a single deployed application with both classes is the way I recommend. Having multiple process applications covering the same deployments at the same time should be avoided.
thanks for the immediate and detailed reply. So it is as suspected before. For me it was important to use the solution preferred by camunda. Then I will handle multiple process versions within one single archive and carry the whole version history of the delegate classes now.
if it is mainly about minor bug fixing, you could also try to keep your new version of the delegate class compatible with the old version of the process. That would mean that your already running process instances can work with the new version of the class (without any change of behavior) and that you also don’t have to change the reference to the delegate in your BPMN model.
Regardless the way you choose, you can clean up some of the historic code (JavaDelegate100.class or old snippets in JavaDelegate101.class) as soon as you can ensure that all old process instances have finished and that you don’t need to start new ones in those old versions.
Can you confirm the only way to handle versioning of Java classes associated to the BPM processes (Java delegates) is packing them all together inside the same process application WAR archive and coding the version number as part of their names?
It doesn’t seem a very scalable / maintainable solution.
Moreover, while the camunda database holds multiple versions of the same BPM process; process applications WAR files are only allowed to contain one single version of each BPM process. That means, the process application archives (and code base) ends up out-of-sync with the BPM versions stored in the database.
Does the enterprise edition offer better versioning capabilities?
Can you confirm the only way to handle versioning of Java classes associated to the BPM processes (Java delegates) is packing them all together inside the same process application WAR archive and coding the version number as part of their names?
It doesn’t seem a very scalable / maintainable solution.
Moreover, while the camunda database holds multiple versions of the same BPM process; process applications WAR files are only allowed to contain one single version of each BPM process. That means, the process application archives (and code base) ends up out-of-sync with the BPM versions stored in the database.
Does the enterprise edition offer better versioning capabilities?
If you need parallel execution of more than one version of the process model by business requirements, then you have to go the way as Ben described above.
Hello @Ingo_Richtsmeier,
Thank you for the link, but it seems that the Camunda migration covers for the process model, not for Java Delegates versioning.
@all, does Camunda (enterprise or community version) have a solution for Java delegates versioning? I agree with Asanchez that packaging all the Java classes (olds and news with different names) is not too scalable / maintainable solution.
Thanks for sharing your insight!
Byung