My team is using the Activiti 5.19 engine embedded in a Grails 3.1.4 WAR deployment (Spring Config). Our application is being developed against development and pre-production Apache Tomcat stacks. We have been very pleased with the engine and what it has to offer. As we approach a production release, I have been contemplating an issue that we have encountered. The issue in a nutshell is how to keep our Grails application code in line with BPMN process definition versions. We use the Grails application to get input from our users, complete task, fill out forms related to workflow, and update workflow status instance variables. I know the process definitions complete at their current version, but our application code changes over time. A good example of this is form processing for a new Task definition in a parent process definition. The application code must change to process the Task, but previous incarnations of the process definition (and application code) didn't have the task/processing defined. I hope this problem description is clear. I have read information from the Activiti in Action book suggesting Java Service classes and BPMN versioning solutions via OSGI - is there anything I should be looking in terms of strategies or technologies that would help us keep our Grails application code in line with BPMN process definition versions? Does anybody have any experience like this, or can somebody point me public code/reading that may help with this scenario. Thanks for the opportunity to ask this question - it is my first in this forum, please let me know if I have made a posting error in any way.
I know the process definitions complete at their current version, but our application code changes over time. A good example of this is form processing for a new Task definition in a parent process definition. The application code must change to process the Task, but previous incarnations of the process definition (and application code) didn't have the task/processing defined.
Two ideas come to mind for this.
One is you can have your application code do a check on the process definition version. So when you release new Grails code you can have that Grails code be aware of which version of the process a particular task belongs to.
Another approach is when you upgrade the Grails app you also migrate all of the existing process instances to the new version. That may be easier or more difficult depending upon what specifically is changed. Actually there are at least two sub-options within this (both listed in Process Instance migration ). You could programmatically update the old process definition by looking it up through the repositoryService and applying changes, which would immediately apply to all the running instances but can be tricky code to write depending upon the changes to the model. Or you can programmatically close the exiting instances and create new ones that 'match' them, porting across the values of the variables and moving them through state if needed. I think there is actually a third option, which is to use an Activiti feature to migrate but that comes with disclaimers as again it depends on the process definition whether it will work for you - see There are a motive for not exist a exposed API for 'SetProcessDefinitionVersionCmd' ? and Process instances migration