Exception Handler - Configuration
Last updated
Last updated
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.
On the flow editing page, select the "Exception Handlers" button.
Goals
Set up exception handling for a REST module.
Step by Step
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.
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
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.
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.
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.
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:
Go to "Settings" in the flow editing area.
Click on the "Alerts" tab.
In "Log Settings," enter the syslog server address and/or the email addresses that should receive the notifications.
Finally, click "Save changes."
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:
[ Step 01 ]
[ Step 02 ]
[ Step 03 ]
[ Step 04 ]
[ Step 05 ]
You can find regular expression validators on the internet, e.g:
It's essential that the "Flows" option is enabled in "Element Notifications." Read the article "."
