I recently had the fortunate opportunity to present at our local ServiceNow Meetup (aka SNUG) here in Queensland, Australia. The topic was based on my previous post Understanding Connection & Credential Alias. I had planned to only focus on the architecture (and benefits of such) as per the article's contents. However, the live audience was enthusiastic and keen to discuss the topic a little further, hence this post!
So what did we talk about? Well, we covered MID Server Capabilities and error-handling techniques such as the Retry Policy. You may recall that we add our Connection records via the related list linked to our Alias record. In doing so we have an option to tell ServiceNow to use a MID Server when making the outbound connection (by default, the connection would be made from the cloud instance). Once selected, you can then choose options relating to the MID Server connection (see below).
The first thing you'll want to do is determine whether you want ServiceNow to automatically select an active MID Server (assuming you have more than one), or whether you want to be more specific. You can nominate a specific MID Server or MID Server Cluster. As these Connection records are not deployed anywhere else, this "hardcoded" approach is ok. Just remember though, if the nominated MID Server is down when your integration runs, your integration will fail. For this reason, it is better to use either the Auto Select MID Server option or its equivalent for MID Server Clusters. That way you'll have fail-over redundancy. The last thing I should mention here is the option for specifying MID Server Capabilities and/or Applications. These are just ways to fine-tune the list of available MID Servers for your purposes. For example, you may want this integration to be executed by a specific group of MID Servers and no others. You could do this by selecting one or more Capabilities and/or Applications that correspond to the desired MID Servers.
Now, let's talk about error handling. The Retry Policy is a quick and easy way to handle temporary outages that may occur when your outbound integration is attempted. For example, let's say the API was momentarily down due to high traffic or a server reboot. If you define a Retry Policy with appropriate trigger conditions (say Status Code not 200 or Connection Timeout), the Flow Action Step executing your integration will keep retrying the connection as per the Retry Strategy (see below for an OOTB example known as the Default Retry Policy). In this case, it will retry every 10 seconds up to 3 times.
I should mention that the Alias record only specifies the "Default Retry Policy", meaning unless told otherwise, the Flow Action Step will use this policy. This is very handy from a maintenance perspective as you can create a single policy for a whole range of integrations. Just be sure to select it on the Aliases in question! So how do you overwrite the "Default Retry Policy" you ask? We do that by specifying it in the Flow Action Step (see below).
If you require more advanced error-handling techniques, you'll likely need to use a loop inside a Flow/Sufblow when calling the Flow Action. You could build your own explicit retry mechanism as well as do cool things like capture the response details from each attempt and then copy them all into an Incident record. This might save the support team some time as they'd otherwise have to troll through the Outbound HTTP Request logs or Flow Executions!
Well, that wraps up this post. I hope you found it valuable!
