Web Service calls fail. That's just a fact of life.
If you are making an outbound web service call from your ServiceNow instance, you may be able to use the ECC Queue Retry feature to have the outbound web service call retried upon failure. This won't work for every outbound web service call, because this is only available for ASYNC calls. Async web service calls are made using the ECC Queue as the "holding place" while waiting for the response to be returned from the web service back to your ServiceNow instance.
Example of using ECC queue retry policy to check for a specific failure condition
We will go through an example using REST asynchronously and have an ECC queue retry policy check for a specific failure condition. When that failure condition is found, the REST call will be automatically tried again (3 times, with 1 minute between checks, for our example).
Let's get started with a REST Message that is part of the demo data provided with your instance "Yahoo Finance." The documentation provides an example of calling this REST message through a ServiceNow script, and making the call asynchronously.
var requestBody;
var responseBody;
var status;
var sm;
try{
sm = new sn_ws.RESTMessageV2("Yahoo Finance", "get"); // Might throw exception if message doesn't exist or not visible due to scope.
sm.setBasicAuth("admin","admin");
sm.setStringParameter("symbol", "NOW");
sm.setStringParameterNoEscape("xml_data","<data>test</data>");
response = sm.executeAsync(); //Might throw exception if http connection timed out or some issue with sending request itself because of encryption/decryption of password.
response.waitForResponse(60);// In seconds. Wait at most 60 seconds to get response from ECC Queue/Mid Server //Might throw exception timing out waiting for response in ECC queue.
responseBody = response.haveError() ? response.getErrorMessage() : response.getBody();
status = response.getStatusCode();
} catch(ex) {
responseBody = ex.getMessage();
status = '500';
} finally {
requestBody = sm ? sm.getRequestBody():null;
}
gs.log("Request Body: " + requestBody);
gs.log("Response: " + responseBody);
gs.log("HTTP Status: " + status);
Notice the 10th line of this example: response = sm.executeAsync()
If this was response = sm.execute() then the request would not go through the ECC queue, and the retry policy could not be used.
I have created a "fix script" with this code, so I can easily execute it when I want, and can make quick changes to it. It could also be executed through "scripts - background".
After executing the script, the response message is placed in the ECC queue as an "input" message that is in "Response to" the "REST Probe" (outbound REST Message).
This example was successful, but now, it it time to break something. Notice we added a new statement to change the endpoint
try{
sm = new sn_ws.RESTMessageV2("Yahoo Finance", "get"); // Might throw exception if message doesn't exist or not visible due to scope.
sm.setBasicAuth("admin","admin");
sm.setStringParameter("symbol", "NOW");
sm.setStringParameterNoEscape("xml_data","<data>test</data>");
sm.setEndpoint("http://not_valid.com"); //Clearly, this is not a valid endpoint, so we should get an exception
response = sm.executeAsync(); //Might throw exception if http connection timed out or some issue with sending request itself because of encryption/decryption of password.
Notice we added a new statement to change the endpoint.
When I execute the fix script again (with the invalid endpoint), we get a different response in the ECC queue:
Using this failed response, we can create an ECC Retry Policy:
After testing the script with the "retry policy" now in place, we can check the ECC's "Queue Retry Activity" module.
This shows us that the failed REST message was retried 3 additional times. After it failed for the 3 retry, it was marked as "Failed" and no additional reties happened.
To summarize, ServiceNow has the capability to retry actions that are placed in the ECC queue. This typically is used for SOAP and REST outbound web service calls. Web Service endpoints may be unavailable for a number of reasons, so having a way to automatically retry those calls a few times can be the best way to handle these faults. Since the ECC queue is used for asynchronous communication, the platform can send the same request multiple times, to facilitate the retry. As the administrator, you can be very clear about which failures you want to retry, how many times you want to retry, and how long you want to wait after a failure is returned before you send the next request.
5 Comments
