AnsweredAssumed Answered

Activiti Process Versioning: Best Practices

Question asked by sangv on Sep 14, 2011
Latest reply on Sep 20, 2011 by jbarrez
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


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?