Articles on: App Integrator

Errors Handling

Set up the error handling of a specified request in this tab. All transactions will be considered successful if you leave this tab empty.

The tab consists of filters to specify the response rule. When rules match, the transaction will have an error and the error text will be displayed.

You can create several separate blocks at once. Each block may have its own error text. The block consists of filter groups and is triggered only if all filters are completely matched.

Consequently, you can either create several blocks containing one filter condition and a specific error text, or one block with several filter options.



Error type

Select the error type. Available values:

Default - Standard error. If the data matches the filter, the transaction is considered an error.

InvalidCredential - The conditions of this type indicate that the user has invalid connection in the bundle.

ExpiredToken - In this type of error, you need to specify the response text in the filter, which means that the access token has expired and needs to be updated. If your authorization asks to update the access token at expiration, this type of error is required. Exactly when the block type matches the conditions, the application will make a request to update the token (setup in the authorization) and save the updated token in the connection. Thus, re-request with a new access token (after updating) will be made. If the error appears after the update, then the transaction will be considered an error and the error text will be displayed according to the mapping.


Error message mapping



Enter the error text in this field to display in the bundle log. Enter both a static value and a mapping to the response variable. Mapping is to be written inside two braces {{ }} , at the beginning you need to write data. (if the required variable is in the response body) or headers_._ (if the variable is in the response headers).

For example, if the response error text looks like this:

{


"response":{


"error":"Error text"


}


}


mapping will be the following: {{ data.response.error }}



Condition filter



Set up the condition to indicate the error request to the service. In the left field, write the mapping to the key of the variable that you want to follow (mapping should also start with data. or headers._)._ Select a conditional operator and in the right field specify a variable value that indicates an error. You can also set the headers.http-code value in the left field. This key will track the HTTP response code and you can write, for example, 400 in the value.

Within one block you can create an unlimited number of conditions by setting the operator between conditions (AND / OR). Each condition can also be converted into a group of conditions, for precise definition. Example:

status = error AND (result = error1 OR result = error2)

Examples



Example 1.

Let's take the JSON from the error mapping example. In case of error JSON comes in this form, and there is no response.error variable upon successful requests, you can fill in the filter to make it respond to the fact of such field appearance. Enter the mapping data.response.error in the left, put the “Equal” operator, select from the list “Empty value” the parameter

Thus, if there is no field in the response, the request is correct. When this variable appears in the response, the transaction is an error.

Example 2.

The response comes with a variable that clearly indicates that an error has occurred

{


"status":"error",


"reason":"Error occur..."


}


In this case, the path to the variable with the error text {{ data.reason }} is specified in the message mapping and in the filter data.status = error

Updated on: 07/12/2022

Was this article helpful?

Share your feedback

Cancel

Thank you!