Request Retry
Retry logic is configurable per Integration and controls how Unifi will automatically retry errored HTTP Requests.
Retry logic is configurable per Integration and controls how Unifi will automatically retry errored HTTP Requests.
The retry functionality is like a first line of defence when it comes to error handling. It builds in time to allow the system to deal with potential issues in the first instance and saves the analyst or administrator having to step in at the first sign of any problems. This can be useful in scenarios where, perhaps the external system is temporarily preoccupied with other tasks and is unable to respond in sufficient time.
Rather than fail or error a Transaction at the first unsuccessful attempt, Unifi will automatically retry and process it again. The number of times it attempts to do so and how long it waits (both for a response and before attempting to retry again) are configurable parameters.
Although the retry logic itself is applied at the HTTP Request level, the settings to configure it can be found on the Integration. This means that they can be configured uniquely and specifically for each Integration. Unifi will automatically retry errored Requests according to those settings.
The fields that can be configured are as follows:
In Unifi Integration Designer, navigate to and open < The Integration you wish to configure >.
Click the ‘Integration’ icon (this will open the Details page).
Navigate to Error Handling > Timeouts.
The Timeout fields that can be configured for the Integration are as follows:
| Field | Description |
|---|---|
Navigate to Error Handling > Retry.
The Retry fields that can be configured for the Integration are as follows:
Retry is automated in Unifi. Should the number of retries be exhausted, the Transaction will be errored and any subsequent Transactions are queued. This prevents Transactions from being sent out of sync and updates being made to bonded records in the wrong sequence.
It will require a user with the Unifi Manager role to intervene, investigate and correct the error before manually restarting the queue.
There are a number of UI Actions available to help and subsequent sections will look at each of those in turn.
In the next section, we'll look at the first of those UI Actions, the Replay feature.
| Field | Description |
|---|---|
Retry delay
The amount of time in seconds to wait before trying an outbound request again.
Retry limit
The number of times sending an outbound request is attempted.
Sync timeout
The amount of time in seconds to wait for a request to be accepted by the external system.
Async timeout
The amount of time in seconds to wait for an asynchronous receipt.
MID server timeout
The amount of time in seconds to wait for the MID server to respond (only applies to connections using MID servers).
