Hi,
as hozawa already stated, in this case you will have to create your own policy. And the how to is dependent on how you have integrated the API.
For most of my interface integrations i use a self build framework. The core functionality is as follows:
There are multiple triggers that trigger the interface. Instead of directly calling the REST API these triggers transform the current record to match the API definition. Those transformed records will then be stored within a table containing the data as a json object.
The actual API call is stored within a related table and contains the follwowing information:
- Which API to call
- Credentials
- Mid-Server
- Original JSON input (or XML input if it is a SOAP interface) -> this is a reference to the table mentioned above
From that queue table the actual REST call is made. The reponse of the rest call is stored within an input queue similar to the output one. And on that table i can define a retry policy.
Lets say i get a response with HTTP 500 (timeout). I can then trigger a retry on the referenced json object. This in return will then trigger the creation of an API call record, which triggers the API, which in return creates a new input queue record, which then again goes through the same retry policy checks.
This is good for data consistency and maximum transperancy while keeping an overall very reusable structure. However, it is not the best performing one.
To get a great performing REST API retry, you can do the same thing within the REST API scripted call. There you have to evaluate the response of the REST API and based on the evaluation just re-call your REST API call function.
HOWEVER: no matter which way always ensure you are not creating an endless loop of retries.
Hope this helps.
Regards
Fabian
