How to retry sending the REST message again in case of Bad HTTP response

[Sulabh Garg]

Hi Community members,

In bidirectional integrations, if we are sending data to third party systems (Via REST messages) and if we receive the HTTP status codes (e.g.: 500) as acknowledgement then what is the best way to retry sending the REST message again after some specific intervals so that no request is skipped.

Use case - Once request generated, we need to send the data to third party application and we may have huge volume of requests generation, so we are planning to setup some error control.

Thanks in Advance.

[Maik Skoddow]

For Integration Hub there are Retry Policies: https://docs.servicenow.com/bundle/quebec-servicenow-platform/page/administer/flow-designer/concept/...

In case you implement the REST Request outside Flow Designer you have to built your own logic.

Kind regards
Maik

If my answer replied your question please mark appropriate response as correct so that the question will appear as resolved for other users who may have a similar question in the future.

[Sulabh Garg]

Thanks Maik,

Yes, its outside integration hub and flow designer.

[Maik Skoddow · Accepted solution]

Hi @Sulabh Garg ,

in that case, you have to implement a suitable error handler by your own.

I could image to create a custom table which acts as a queue for outbound requests. The records not only contain a configured RESTMessage object, but also some additional parameters like retry count and callback. A scheduled job could scan that table and execute the REST requests accordingly. In case of a successful response, the callback method is invoked.

Sounds like some efforts, but could be used many times and would be really helpful.

Kind regards
Maik

If my answer replied your question please mark appropriate response as correct so that the question will appear as resolved for other users who may have a similar question in the future.

[Sulabh Garg]

Thanks Maik,

I understand the approach, Instead of custom table can we use the Outbound HTTP Logs table (sys_outbound_http_log) as we already have few parameters there including Response status, Request and response body etc.

As custom table could have the licensing implications.