Exception Handler - Configuration

To set up an "Exception Handler"you need to define it within a flow and apply it to the modules. You may also need to set up the syslog server and email notification.


How to access

On the flow editing page, select the "Exception Handlers" button.


Goals

Set up exception handling for a REST module.

  1. [ Step 05 ] Run the flow


Step by Step

Step 01: Create the HTTP Error Handler Exception

Click "Add Exception Handler".

The screen appears:

  • Define a name for your Exception Handler, for example HTTP Handler. This name will be seen in the module configuration.

  • Set a scope of availability of your EH.

    • Flow: Viewed and available only in the flow you are editing

    • Integration: Viewed and available for all flows of the Integration you are editing

    • Space: Available for any flow of any integration in your organization

  • Click "Add Rule" to create a new Exception Rule.

Screen for entering Handler data

After clicking "Add Rule", the second part of the settings (Handler Rules) will appear:

  • Define a name for your Handler Rule, such as Client/Server Error Responses.

  • Set retries to 1. The aim is to allow the platform to try the call 1 more time, eliminating any occasional communication errors.

  • Set the waiting time.

  • Define the regular expression that identifies any HTTP client or server errors. To do this, we use a regular expression that finds any 3-digit sequence starting with 4 or 5. Note that any characters are important for a regular expression to work, including spaces.

“status”: [45]\d\d

You can find regular expression validators on the internet, e.g: regex101: build, test, and debug regex

  • Select the notifications that this ER will generate, for example syslog and Local.

  • Define the message generated in these notifications, for example: HTTP Error 400/500. This message can be filtered in syslog or local logs.

Essa Regra do Handler pode ser sumarizada pelo quadro abaixo:

Name

Retries

Delay

REGEX

ANY

Notification

Message

Send parameters

Client/Server Error Responses

1

0

“status”: [45]\d\d

syslog

local

HTTP Error 400/500

Next, Handler default rule:

  • Specify the notifications that will be generated, for example syslog and Local.

  • Specify the notification message, for example: HTTP FATAL ERROR.

  • Select Send parameters in the message?. This option will include all the context information of the call in the notification message, allowing you to identify exactly the parameters used.

  • Choose the Final Action (Continue, Continue loop or Stop).

  • Click Save to apply your settings.

Step 02: Create the Generic Error Handler

A lot of errors are unpredictable. We can define an EH to handle them in a standardized way.

  • Create a new EH with name Generic with scope Integration

  • Add the following Exception Rule:

Name

Retries

Delay

REGEX

ANY

Notification

Message

Send Params

Generic

1

0

syslog

local

UNKNOWN ERROR

  • Observe que selecionamos o campo ANY. Com essa opção qualquer exceção será tratada por essa regra. Tipicamente essa opção é aplicada apenas uma vez no final de uma sequência de EHs

    • Notice that we have selected the ANY field. With this option any exception will be handled by this rule. Typically this option is applied only once at the end of a sequence of EHs to handle all errors that were not specifically defined earlier.

    • Set the Default Action

    • Select Syslog and Local as notification mechanisms

    • Select Send parameters in the message?. This option will allow us to investigate the details of the unknown error that generated the exception.

    • Select the final action with "Stop". In this way the flow will be stopped, because we are dealing with some serious error that our flow is not prepared to respond to.

    • Click "Save" to finish your settings.

Step 03: Apply Exception Handlers in the Module

Enter the edit mode of the module that will receive the Exception Handlers. Note that both EH created are available for application in the module.

  • First select HTTP Handler and then select Generic.

  • Note that they are inserted into the Selected Handlers field in the order in which they were selected. This order also determines the order in which exceptions will be evaluated and is therefore critical to the correct operation of the EH stack.

Exception Handlers applied to the module

Step 04: Set up syslog and email notifications for the Exception Handler

When creating a rule in the Exception Handler, you can choose which message(s) you will receive. However, simply selecting the message type is not enough to ensure you receive the notification. To receive all notifications, follow these steps:

  1. Go to "Settings" in the flow editing area.

  2. Click on the "Alerts" tab.

  3. In "Log Settings," enter the syslog server address and/or the email addresses that should receive the notifications.

  4. Finally, click "Save changes."

Step 05: Run the flow

Execute this flow against some service that is programmed to respond with an error code (400) or make the error through some wrongly configured parameter.

  • Execute the flow against a service that responds to error code, for example 400.

  • Notice that the flow completes successfully despite the exception, since it was handled with a continue action.

  • Note that the locally generated log messages point out that the EH HTTP Handler was responsible for handling the exception.

  • Note that two requests were generated, one retry, with their respective notifications. The third error message was generated by Default Action and includes the details of the call that generated the exception.

  • Additionally you can run this flow against a service that is unavailable. In this case we will not get an HTTP code, but some other kind of error. The example below was generated against a server with the service disabled.

  • Notice the Connection Refused error in the detailed message.

  • Note that the handling of this error was done by EH Generic.

  • The flow was stopped by generating an ERROR as programmed in the Handler through the Stop action of the Default Action.


Next step:

Exception Handler - Cases


Last updated