Exception Handler
Last updated
Last updated
Several problems can happen when interacting with external systems. These problems can be caused by communication failures or problems at the application level. However, we need to be prepared to react to the most common problems automatically or to identify and report unexpected problems. To handle all possible exceptions we will use "Exception Handlers" (EH).
An "Exception Handler" is a bundle of Exception Rules with the same default action. The EHs are applied to each module within a flow. You can apply multiple EHs in the same module to cover several types of exceptions.
Exception Rule - ER
The unit of exception identification and handling is the Exception Rule (ER). The ER contains the definition of the type of ERROR that is being handled. All errors observed in a flow result in some kind of error message. The ER allows us to specify a regular expression that is applied over this message to filter out a specific type of error.
For example, a REST request that returns a 400 error will present an error message as below.
We can create a rule to filter this message using only the status code provided. The regular expression will be:
In the same ER, we can define the number of additional attempts the platform will make and the interval between these attempts, as well as the notification generated each time the expression is found.
Default Action - DA
ERs allow specifying the number of retries and the interval between them. However, when the additional attempts fail, we can define a Default Action that is executed at the end of the attempts.
The three available actions are:
Stop: The flow is completely halted.
Continue: Even after an error occurs, the flow continues, and the error is logged.
Loop: Instead of proceeding with the flow, this action makes the process return to the beginning of the flow.
For each of the above actions, it is also possible to define specific notifications and their destinations.
Exception Handler (EH)
We can create several ER within an EH. With this we can group in the same EH several rules that have the same default handling or Default Action (DA). For example, we can create two specific rules to handle the HTTP response codes 404(Not Found) and 403(Forbidden), but in case of failed retries, both will be handled by the same DA.
Modules
In the module configuration within the flow we can specify which EH will be used. Multiple EH can be stacked and will be inspected in the order they were selected.
The ability to specify multiple EH in a module allows us to cover all exception handling with a set of EH that have been created to handle specific exceptions.
Processing
The diagram below illustrates the EH processing mechanism.
Every module call can encounter an exception. When this happens, the platform will check if there is any EH configured in the module. If there isn't one, the platform will handle the exception in the traditional way.
The platform follows the behavior below regarding exceptions in the absence of an EH:
REST Modules: The error is logged in the execution logs and becomes available for handling by subsequent modules. The flow proceeds to the next module.
Other Modules: The error is logged in the execution logs, and the flow is interrupted, indicating execution failure.
In the presence of one or more EHs, the platform follows these steps:
Selects the first EH from the list of EHs applied to the module.
Selects the first ER from the list of ERs within the EH.
Evaluates the regular expression of this ER against the exception message being analyzed.
If there is a match, the platform checks if there is any notification to be generated and executes it. Next, the platform checks if there is any retry specification. If so, it checks if the retry counter is still positive. In this case, the platform waits for the specified delay time before decrementing the retry count and returning the flow for a new request of the call.
If there is a match and the retry count reaches zero, the platform proceeds to the Default Action. In the DA, it is possible to specify a distinct notification and take one of three flow actions:
a) Continue execution to the next module.
b) Interrupt execution with the respective error generation.
c) Proceed to the next execution of the innermost loop where the module is located.
If there is no match in the first ER, the platform proceeds to evaluate the following rules.
If there is a rule with the ANY flag, the platform executes it as the last in the list of ERs and ensures its match, regardless of any regular expression.
If no rule in an EH results in a match, the platform proceeds to evaluate the next EH.
If no ER in any EH results in a match, the platform will handle the exception in the traditional way.
Next Steps:
