I have a implementation of Activiti that has a growing number of bpmn flows that are deployed and used to manage the permit application process for the Government of Puerto Rico. As much as possible the coupling between a flow design and web interaction is minimal however every now and then an existing flow needs updating for a feature change or bug fix.
When a flow update is deployed as expected a new version is created and any of new permit application will use the latest and greatest version while all currently running instances continue as they were. If there is a required interaction change between the web application and the particular flow what is the recommended approach to ensure application and flow interaction compatibility is maintained across all versions of a deployed process.
My initial plan is to handle it much like a API change, ensuring that any interaction points are backwards compatible with a deprecation note/warning and a housekeeping task that deactivates that version of the flow when all instances have completed. Some of our process instances have complex flows and take months to be completed
Are there any suggested approaches or clever flow design patterns that would better handle this situation or even allow the upgrade or transfer of currently running processes to an newly deployed flow.
the upgrade or transfer of currently running processes to an newly deployed flow.
see org.activiti.engine.impl.cmd.SetProcessDefinitionVersionCmd
Are there any suggested approaches or clever flow design patterns that would better handle this situation
There are many possibilities to handle this situation - versioning of services, bounding services with process definitions (jBPM class loader), decoupling services from process definitions… . It really depends on what is the best solution for you.
