We're currently designing a BPT process that needs an alternative flow to handle errors (in this case a retry). I was expecting that in case of the normal flow, the alternative flow would be executed. It now seems however, that both the normal flow and alternative flow are being executed.

In the following example, Alternative Start RetrievalFailure is triggered on a certain status change that is set in CerDataRequest. What we see is that both the RetrievalFailure flow and CerTerminate are executed. I would expect CerTerminate to not be executed in this case:



What should we do to get the desired result?

Hi Killian,

First of all I would like to note that the Automatic Activities already have retry mechanisms (for when exceptions are raised inside), but the retries are faster (first retry is set to instantaneously, and then the period between retries increments exponentialy based of the number of errors).

The green arrow to the conditional start means that the RetrievalFailure activity will be available to be started after the CerDataRequest finishes. So both CerTerminate will always occur and RetrievalFailure can optionally occur.

Second note: wait cyles in processes should be avoided as much as possible. Each transiction creates one activity "instance", and the number of instances in a process instance is by default 10000. So keep that in mind when creating processes that can indenfinitly be in cycle.

A valid implementation of what you wanted (disregarding the issue with the cycles, if they are not meant to need many retries) can be done like this:



A better implementation would be to use the OnClose callback on the Wait Activity to actually perform the retry code.
This is because if the OnClose of a Wait Activity throws an exception the Timeout property will recalculate the new retry date. If the date is still in the future the activity will continue in the Waiting state.



This is how I would probably model the process, that way the Automatic Activity and the correspondent Retry action is very explicit in the execution.
Another alternative (for example if in 99% of the times if always fail on the first try ...It is not relevant for the process flow to have the "normal" action at the beginning) is to implement all just relying on the Wait Activities, having a condition to delay or not the timeout:




Regards
João Rosado

Hi João,

Thanks for this clear and thorough explanation! My confusion stems from this sentence in the platform help:

Whenever an entity record is created or updated with an  Entity Action you may use the  Conditional Start process activity to start alternative flows to your normal process flow. A typical usage is to handle exceptions to the normal process flow.

I read that as the alternative flow being a replacement of, instead of an addition to, the normal flow.