Best way to model a large split up process with loops

Hi,

We have a business process that is just too large for one process, so we’ve split it up into one super process with call activities that start child processes.

By now we have the “default” path.

Now we are debating the best way to incorporate looping behavior /error handling, between these child processes. In our case most commonly some later child process detects some error in the data and the process must return to a specific point inside an earlier child process.

We could model it with “error boundary events” on the call activities, an explicit connection to the previous call activity and then handling the new entry point inside the previous call activity. But this feels like it will quickly get verbose and rigid.

We could also do it with message or signal events, but are somewhat suspicious that we will run into problems once we have multiple deployed versions of this process that messages get sent to the wrong versions or that it becomes hard to follow the logs/process state/process variables.

Ideal would be being able to send signals under a “process and all processes callable by it” context, (I remember logic like this working with subprocesses).

The way I see it we can either have one large “orchestrating” superprocess;

  • one clear root process instance, so state of process is easily visible / “drill-downable”
  • easy logging
  • quickly becomes verbose with errors/loops
    Or multiple smaller processes that start each other via messages/signals
  • most flexible
  • versioning/logging/process variable headaches?
    (or some mixture I guess)

What is the best practice/best approach/ are we missing or misunderstanding bpmn model elements/camunda features ?

Well your grappling with a really common design choice. You need to decide what’s more important between:

  1. Explicitly modeling loop functionality to make it obvious to readers what happening.
  2. Hiding a certain amount of logic in order to maintain the readability of your over-all model.

Loop behavior can be modeled in a multitude of ways and without knowing more about your model it’s hard to suggest a particular tactic. But knowing that you’re dealing with Parent-Child processes it’s obvious that you should foremost be considering Error and Escalation events in order to communication back to parents. The benefits are pretty obvious -

  • No need to correlate communication explicitly.
  • The event will propagate through multiple levels of children if not consumed.
  • Easy to follow in History of the process.

In truth that’s usually the best tacit, but if this “looping behavior” starts to become very complicated. I.e. after any Call Activity it could loop back to ANY other call activity, that’s a little harder for BPMN to deal with. You could try something like this:

Although i would like to suggest you take a look at CMMN for much better flexibility.