Workflow Versioning

[Jose Suero]

I have touched on this topic before but wanted to see if there's any new ideas regarding this. 

I have running serverless workflows that change constantly, so I created a process to "upgrade" to new version" which tries thru DB queries to pull workflow data, delete old correlation, post to api to create a new process on the new version but starting on the node where the old version is at.

This has brought a whole bunch of problems since I'm manipulating the data in a way that Kogito was never designed for. 

I understand the "recommend" solution is to have different deployments per version, which for my project would be completely unmanageable, since we plan to have dozens of workflows that need to constantly adapt to changing business needs.

Right now one of the biggest issues is that when version changes the old running processes "disappear" since Kogito can no longer find them.

 I have considered just keeping a separate file for versions but this comes with having to make sure no one on the team pushes changes to this old file by mistake, and creating or querying workflows on the "right" version needs yet more things to take into account.

I would be happy if old processes could finish on old versions, and new processes can start from new version, maybe by adding workflow definition at db level instead of just files.

Or there was an "official" way to upgrade versions, maybe an api that receives an id and a starting point and it moves the data correctly (and transactionally) to the new version

Any thoughts on this?

[Cristiano Nicolai]

Hi Jose, 

Thanks for bringing that up. This is a topic that needs improvement. I'll go through some items here.

Regarding processes that "disappear", that's done by design so we can ensure multiple services from different versions could run in parallel, sharing the same db without impacting each other. The last thing we would like to happen is for data from version x to run using the definition of version y without proper handling/migration. On the other hand, you have some flexibility in handling this. By default, the process version is set based on the Maven project version, meaning it rolls out with a new bump in the deployment version, but you could also change this behaviour and use the process version itself, defined in the bpmn/sw file. That way, you have more fine-grained control over whether a version needs to be changed. To change that, you can set the following in your application.properties:

kogito.workflow.version-strategy=project

kogito.workflow.version-strategy=workflow

Another aspect related to storing process definitions is that Data Index will start storing that in the upcoming releases, including the workflow file. I can see this evolving to a service that could query Data Index and migrate the instance to a new version.

Another alternative is to implement that manually in your project for now, so you may keep only new and previous versions in the project, so when you deploy it, it migrates. That should be feasible to do.

 

--
You received this message because you are subscribed to the Google Groups "Kogito development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kogito-developm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kogito-development/d5d3721a-1ce9-4c77-a83c-825ab66ef262n%40googlegroups.com.

--

Best regards,

Cristiano Nicolai

[Arif Mohammed]

Does it mean that, in Kogito when we deploy a new version of process, it automatically migrates older version of process instances to new version ? Unlike in jBPM where we have to migrate the instances explicitly.