I have a RestAPI call that returns Exception and on exception and wanted to retry that RestAPI, let’s say maximum 5 times. I was thinking of using a ‘Processes’ resolve the issue.
What I would like to know is, is ‘Processes’ is the right approach? Is there a better approach than ‘Processes’? If ‘Processes’ is a right approach, is there any better way of implementing the same (I am counting retry manually in the code). What I came to know that there is a built-in retry mechanism in outsystems?
Thanks in Advance
Hi Sachin,
What is the context of this API call? Is it directly triggered by a user? Is it called in a Timer? I assume it's not already part of a BPT process?
That said, why would the API method fail in the first place? What are the most common causes of failure? Of the most common exceptions are things like "404 not found" or "403 authorization", then retrying wouldn't help at all.
API is being called on a button click. Api can fail due to multiple technical reasons such as api's behind the api are failing. Called Api is timed out or behind Api's are timing out or unhandled exception.
In case Api is failing technically then we need to manage it (retry will not help), but if Api is going in sleep mode or timing out then retry would help. Hence wanted to give a retry.
In that case, I would indeed recommend having the button trigger a process and run the API call within that process. Provide the attempt number as input to the process (set to zero on the initial call).If the API returns an error code, you can use that code to determine if you want to do a retry (as Kilian mentioned, it does not always make sense to try again). If the error code/message warrants a retry, increase the input attempt number and use it as an input for the next trigger of the process. Finally, before calling the process again, you should implement some logic to check if the maximum number of retries has been reached.
I'm not entirely sure if that's what you mean, but if one's going to use asynchronous processing, always use asynchronous processing, not only when something goes wrong. So the button press triggers a BPT process or timer, that handles everything. Don't go for a hybrid option where the first attempt is made synchronously and all other attempts are asynchronous, unless you know 99% of the calls will succeed and you need to directly inform the user of it.
My suggestion was indeed to go for a fully asynchronous solution where the button triggers the process and if the API returns a certain error code the process retriggers itself a couple of times until a successful reply is received or until x unsuccessful attempts.
Hi,
The button is synchronous, but only in case of exception process is being launched and then within process call ung my Api. So, eventually, my api is being called 5 time asyncrously. Is it a bad design?
Yes, it is bad design, because it adds extra complexity, that is probably not necessary.