Outsmart fickle networks, firewall changes, and down servers in your web services integration

[Dawn Jurek]

Here's a quick test—do you know how to avoid this scenario? You're building a web services integration to a ServiceNow table. The integration seems to be working fine during testing, so you pull the trigger on implementation and—BOOM—it blows up (not literally - figuratively). The blowing up part is bad enough, but you can't even figure out why it's suddenly not working.

So do you know the answer? In this eighth installment of our best practices series, we look at why web service integrations can fail, and how to set them up so that you can figure out what went wrong.

Why did the web services integration go boom?

Networks, by their very nature, experience issues now and then. Network outages, changes in firewall configurations, and servers going down are just a few of the things that can result in web service requests or responses not being received.

Planning for the unexpected is important because things often work fine when you're building the integration, but issues can occur after implementation. And if you haven't incorporated error handling, when an issue occurs, the integration blows up instead of gracefully handling the situation and notifying administrators.

When building your integration, ensure that you know whether or not your requests are successful—and if they're not successful, you know why, so that you can troubleshoot.

Tips for handling network failures when interacting with a remote system via HTTP

Here are some tips for handling network failures when interacting with a remote system via HTTP—for example,   SOAPMessage, RESTMessage, and GlideHTTPRequest:

• Use asynchronous communications for web service requests. That way, the client—for example, a web browser or ServiceNow instance—doesn't have to wait for a web service response in order to render objects. When requests are sent synchronously (not recommended), the code making the request has to wait for the web service to respond. If the code was triggered by a business rule, the ServiceNow user interface—for example, a form—won't render until the request is complete. Thus, synchronous communications tie the performance of the ServiceNow user interface to the external service, which may make the instance appear slow to the user.
• Determine an acceptable duration between request and response as well as an acceptable number of retries before the request is treated as an error.
• Define ECC (External Communication Channel) Queue retry policies for outbound web services. This approach leverages the system to handle retries for you, so that you don't have to provide for them in your code.
  • ECC Queue Retry Policy is a ServiceNow plugin that is not activated by default. It must be activated by ServiceNow personnel, so it does not appear in the System Definition > Plugins module. You can request this plugin through HI.
  • Retry policies for outbound web services run only if you're running web service calls asynchronously or routing them through a MID server.
• Protocols used by web services expect acknowledgement. So when you send a web service request, you should get a response status code indicating whether the request was successful or unsuccessful. See https://httpstatuses.com/ for a list of HTTP status codes. Handle these in your code. If you get a successful status code, such as 200 or 201, fine. But if you get something else, flag it for retry, review, or some other action.

Check out how Google Chrome handles lack of response network errors

You can test this out yourself. Just follow these steps:

1. With the Chrome web browser, log into your ServiceNow instance.
2. Turn off your Wi-Fi.
3. Click the refresh icon and you'll get an error message. Press the up arrow, and it becomes a game. You can keep playing until you crash and it ends.

Web services integration best practice

When consuming web services, don't automatically assume the request will succeed. Instead, expect the unexpected—such as occasional network failures or timeouts—and plan for these situations in your code.

--

Behind the scenes here at ServiceNow, the Knowledge Management and Multimedia teams work closely with subject matter experts to disseminate critical information to our customers. We've found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series aims to target those topics so that you and your organization can benefit from our collective expertise. If you have a best practices topic you'd like us to cover in this series, please let us know in the comments below.

See Annotate scripts and customizations with comments for the first installment on script comments.

See Limit the number of users with the Admin role for the second installment on user roles.

See Where to avoid linking to a reference field when configuring a list for the third installment on list configuration.

See Developing on your production instance for the fourth installment on development.

See When to create a new table vs. when to extend for the fifth installment on application development.

See How to clone to a target instance that has in-development applications for the sixth installment on cloning.

See Why you should never use external iFrames - and the one exception to this rule for the seventh installment on using iFrames.

To access all of the blog posts in this series, search for "nowsupport best practices series."