Exception Handler

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).

"Exception Handlers" can be applied to any type of module except for "Triggers."

Concept

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.

Organization of Exception Handlers on the Skyone Solutions

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.

ERROR: treatment_error
KNOWN_STACK:
component_error
execute_operation_error
http_operation_error
treatment_error <--
TREATMENT_INFO:
{
  "responseHeader": {
  "status": 400,
  "properties": {
    "content-type": "application/json",
    "content-length": "36",
    "server": "Werkzeug/2.0.2 Python/3.8.10",
    "date": "Sun, 26 Feb 2023 15:33:15 GMT"
    }
  }
}

We can create a rule to filter this message using only the status code provided. The regular expression will be:

"status": 400

Within the same ER, you can define the number of additional attempts Skyone Studio will make and the interval between those attempts, as well as the notification generated each time the expression is detected.

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.

Exception Handler Processing Diagram

Exception Handler Processing Diagram

Every module call can result in an exception. When this occurs, Skyone Studio checks if there is an Exception Handler (EH) configured for the module.

If none exists, Skyone Studio handles the exception using the traditional method.

Traditional Exception Handling

Skyone Studio follows this behavior regarding exceptions when no EH is configured:

  • REST Modules: The error is logged in the execution logs and becomes available for handling by subsequent modules. The flow continues execution with the next module.

  • Other Modules: The error is logged in the execution logs, and the flow is interrupted, indicating an execution failure.

Exception Handling with the Exception Handler

  1. Selects the first EH from the list of EHs applied to the module.

  2. Selects the first ER from the list of ERs within the EH.

  3. Evaluates the regular expression of this ER against the message of the exception being analyzed.

  4. If a match is found, Skyone Studio checks if any notification needs to be generated and executes it. Then, Skyone Studio checks if any retry specifications exist. If so, it verifies if the retry counter is still positive. In this case, Skyone Studio waits for the specified delay time before decrementing the number of retries and returning the flow to make a new request.

  5. If a match exists and the number of retries reaches zero, Skyone Studio proceeds to the Default Action. In the Default Action, it is possible to specify a different notification and take one of three flow actions:

a) Continue execution to the next module.

b) Interrupt execution with the corresponding error generation.

c) Continue to the next iteration of the innermost loop where the module is located.

  1. If there is no match on the first ER, Skyone Studio moves on to evaluate the following rules.

  2. If there is a rule flagged as ANY, Skyone Studio executes it last in the ER list and guarantees its match regardless of any regular expression.

  3. If no match is found in the rules of an EH, Skyone Studio moves on to evaluate the next EH.

  4. If no ER from any EH results in a match, Skyone Studio will handle the exception using the traditional method.

Next Steps:

PreviousFlow Canva: overviewNextException Handler - Configuration

Last updated