Activiti Process Versioning: Best Practices

[sangv]

Please redirect me to another post if this question has already been asked.

Context: We are using activiti in an environment that follows versioning. So when an application gets deployed for the first time, it will ship out with version 1.0 of business processes and rules. In the future, we may deploy version 1.1 and change our application configuration to use the new process (and rules). This works fine but I have some questions about best practices.

i) A process has a processDefinitionKey and processDefinitionId (which by default is the {processDefinitionKey}:{version}:{generatedId}). It seems that to control the version of process being executed, we would have to use the processDefinitionId

runtimeService.startProcessInstanceById(processDefinitionId, paramMap);‍

The questions are, is there an easy way to set the processDefinitionId to something that is intelligible to the app instead of what activiti generates by default (using the BMPNDeployer)? I would not want to write a custom BPMNDeployer only to change the processDeploymentId. Also, can the processDeploymentId be updated after deployment.

Secondly, was there a reason a generatedId was added to the processDefinitionId. I would think that a combination of {processDefinitionKey}:{version} would have been unique enough.

ii) The other approach that we thought was to have the processDefinitionKey have versioning build in. So for example OrderProcess version1 would have processDefinitionKey of "OrderProcessVersion1" and OrderProcess version2 would have processDefinitionKey of "OrderProcessVersion2". Then we could start the process by key

runtimeService.startProcessInstanceByKey(processDefinitionKey)‍

Is this approach preferable to approach i. How do these approaches compare in the maintainability of the apps as the number of versions increase?

iii) Any other recommendations?

[jbarrez]

It depends on your strategy with 'older' processes.
By default, when you deploy a process definition with the same key, this process will get the previous version + 1.
All process started using the startProcessInstanceByKey() method will now use the latest version, while the 'old ones' are phased out.

The other approach is to do it yourself in the key … but that would also mean that you will have to change the code that calls these processes every time you do an update.

[sangv]

Thanks for the reply.

We would be potentially working with long-running processes that can take more than a year to complete (our processes are in the banking/mortgage industry). So our approach for older process is to keep them running for users that have already started on them. For new users that are getting into the process, we will have a versioning strategy that determines if they are eligible for the new process or the old process. What this means for us is that we cannot 'phase old' older processes. With this being our usecase, is looking up the correct process definition version with processDefinitionId still the best approach?  Is there an injection point to custom create our processDefinitionId after deployment that is intelligible to the application (meaning can we inject a naming strategy/convention to the BPMNDeployer)?

Thanks,
Sang

[jbarrez]

If I understand it correctly, why can't you just use the key for the purpose you describe?
Since you do the check which process to start at the beginning, the key is perfectly useable for that.