How do I pin child BPMN file version to parent BPMN version?

Modeling in Zeebe
#1

Hi there,

We’re evaluating Zeebe for a large bank and so far we’ve been pretty impressed! But we ran into an issue while exploring BPMN process evolution.

The BPMN documentation says:

The new instance of the defined workflow will be created of its latest version - at the point when the call activity is activated.

This is a problem for my development team. If I implement a change in a child BPMN that makes it incompatible with older versions of the parent BPMN, then we see two issues:

  1. Since files deployment is not atomic, the new parent version could arrive first, be picked up and used with an older version of the child BPMN,
  2. An incomplete, old workflow instance based on an older version of the parent BPMN will pick up the new incompatible child which will break the workflow.

We could abandon using subprocesses in child BPMN files but that would cause massive duplication. Any idea how we can keep using subprocesses/call activity but avoid the problem stated above?

Thanks!

#2

With a script it is possible to deploy 10+ workflow per sec.

#3

Hey MaximMonin, thanks for your reply.

Trusting in the speed of deployment of the BPMN files as a fix is the same as trusting in sleeping as a viable solution to fix race conditions. We don’t just want to reduce the probability of the issue, we want to know if there are plans to make the issue impossible.

Plus if the script chokes or we lose connection to the Zeebe server in the middle of the script, we’re in trouble again. Trusting in the reliability of networks is a no-no.

#4

Hi @karmo64,

Thank you for raising this up. It is a valid feature request.

Possible options are:

  • specify the version of the child workflow
  • specify the workflow key of the child workflow
  • use the version of the same deployment

Feel free to open a new issue and describe which option would fit best for you.

Note that you can deploy multiple workflows at once (depending on the client).

As a workaround, you could add a version marker in the BPMN process id (e.g. child_v1). If the new versionv of the workflow is not compatible than you increase the version marker (e.g. child_v2).

Best regards,
Philipp

1 Like
#5

Thanks for your reply @philipp.ossler,

Option 3 sounds awesome. If there was a

zbctl create release --name 1
zbctl deploy child.bpmn --release 1
zbctl deploy parent.bpmn --release 1
zbctl publish release --name 1

OR

zbctl publish release  --name 1 child.bpmn parent.bpmn

then:

  1. We wouldn’t have to worry about failures mid script since the release was never published and so no workflows got started with processes in that release.
  2. Publish would be an atomic operation so it won’t be possible for the parent process of a release to ever exist without child processes.
  3. And as long as option 3 is in place, all existing workflows before the release will complete with the child process versions with which they were deployed.

If Option 3 is too opinionated, specifying a workflow’s child workflow version resolution strategy (i.e. SpecifiedChildVersion, ParentVersion, default: LatestChildVersion) could be more flexible.

But if all this feels like bloat, option 1 would be okay also but require more tooling on our end. My team and I were already looking into process naming suffixes so it was reassuring to hear you mention it. We were basically going to build a release tool that:

  1. Search for all process IDs of all modified BPMN files and their dependent files.
  2. Update all those process IDs with a suffix that is the next release version and,
  3. Deploy a map of process ID to process ID+suffix into something like Redis.
  4. All systems that start workflows would read Redis to determine the latest process ID+suffix they need to use.
  5. The publish to Redis would be an atopic operation because we’d store the whole release in one Redis entry.
  6. We would leverage option 1 to provider a stronger guarantee that a bug in our tool couldn’t lead to a process in one release being used with the child process of another release.

I don’t know much about option 2 because I don’t know what the workflow key is sorry lol.

And yes, I can put all of this in an issue.

3 Likes