Retry
Important
This article describes alternatives and workarounds to mimic the Retry error handling directive.
Celonis platform does not offer the Retry error handling directive. Two alternative solutions can be employed to mimic its functionality.
Using the Break directive
In the Advanced settings enable the "Allow storing of Incomplete Executions" option.
Attach an error handler route to the module.
Link the Break directive to the error handler route and configure it e.g. like this:
Drawbacks:
The minimum retry interval is one minute.
If the module is processing multiple bundles and the processing of a bundle fails, the partial execution (only the bundle that caused the error) is moved to the incomplete executions folder and scheduled for retries according to the Break directive settings. However, the current execution continues and the module continues to process the subsequent bundles. At least you may enable the "Sequential processing" option in the Action Flow settings to prevent the Action Flow from executing again until the execution stored in the Incomplete executions folder has been successfully resolved.
Using the Repeater module
Employ the Repeater module and set its Repeats field to the maximum number of attempts.
Link the potentially failing module to the Repeater module.
Attach an error handler route to this module.
Link the Tools >Sleep module to the error handler route and set its Delay field to the number of seconds between the attempts.
Link the Ignore directive after the Tools > Sleep module.
Link the Tools > Set variable module after the potentially failing module and configure it to store the module's result in a variable named e.g. Result.
Link the Array aggregator module after the Tools > Set variable and choose the Repeater module in its Source Module field.
Link the Tools > Get variable module to the Array aggregator module and configure it to obtain the value of the Result variable.
Insert the Tools > Get variable module between the Repeater module and the potentially failing module and configure it obtain the value of the Result variable.
Insert a filter between this Tools > Get variable module and the potentially failing module to continue only if the Result variable does not exist.
Here is a sample Action Flow where the HTTP > Make a request module represents the potentially failing module (you may create this Action Flow easily from the retry template.
Note
Please note: If the result of the potentially failing module is too complex to be stored in a simple variable, you may employ data store to store/retrieve the result. The Data store would contain just one record, the record's key can be e.g. Result.
Drawbacks:
This workaround might appear a bit too complex and it is also more demanding in terms of operations.