Scenario Documentation on Async Parallel Gateways?

Camunda 7 Topics Discussion & Questions
1

Looking for better docs or some more example with explanations of the engine’s implementations around Parallel gateway async.

Working with some clients and they are having a hard time understanding the engine’s configuration possibilities for parallel gateway async. The forum has several posts about it, there is reference to it in the Parallel gateway docs, the Transactions in process docs, there is the original blog post that explains the feature in a sentence or two, and there is the original JIRA ticket.

Is there any docs or repos with further explanation of the configuration scenarios for async parallel gateways?

The forums seem to indicate the easiest/fastest ways are to set async before with exclusive=true on the “joining gateway”. @camunda can you confirm this as a common practice?

Anyone else have any good text to share?

Thanks!

2

Hi @StephenOTT,

could you provide link to materials that you refer? In my understanding those concepts are completely separate. Parallel gateway, described here https://docs.camunda.org/manual/7.5/reference/bpmn20/gateways/parallel-gateway/. Is producing or joining multiple tokens in a process. While async before\after defines transaction boundaries and save states of the process. Could you please speculate a bit more on your question.

Cheers,
Askar

3

Let me sum up the essentials from my pov:

  • parallel running transactions bound to threads which are executing processes pathes that are joined by a parallel gateway will (partly) run into optmistic locking exceptions. Hence the “loosing” transactions will be rolled back and will need to be retried.

  • it can be either an API triggered user transaction or an internally triggered job executor transaction executing a process path. while a user thread can just be retried by that user, “async” makes sure that it is camunda’s job executor which will continue the process path at that point and therefore you can make use of its retry capabilities.

  • “async before” a joining gateway will make sure that it is camunda’s job executor which will continue the “final” transactions running the pathes into the joining gateway. It will therefore ensure that those transactions are not rolled back to before any “business” steps in the process which might have caused non-transactional side effects.

  • with “exclusive=true” the job executor can be configured to run only one such exclusive job on a process instance. With this default turned on you will reduce internal optimistic locking exceptions to a minimum.

Hence you can conciously decide whether you actually “need” an “async before = true” for your joining gateway or not, depending on whether you have non-repeatable side effects which are not rolled back in your process engine’s transaction and depending on whether all your user transactions have robust retry capabilities. As I do not see any particular “harm” in configuring “async before = true” for a joining gateway, I would see it as a good practice in case you don’t want to think about all those details…

As I am currently documenting all this in another context, I would also appreciate any feedback on my comments from camunda core developers. Many thanks!

4