Thoughts on monitoring ServiceNow integrations (part 4): Bringing it all together

[Richard Smith]

We now have all our integrations documented, recorded in ServiceNow both in terms of the details of APIs, applications providing and consuming those APIs, and we have alerts that are flowing to the ServiceNow administrators when things go wrong.

This is in some ways better than a single pane of glass to look at all integrations. We are being called into action immediately when we spot an integration anomaly. But what if we want that single pane of glass anyway?

For this, we need to make few minor changes to and extend ServiceNow's core capabilities a bit. And here, this is by no means the only, or even a recommended one size fits all solution. It's just the obvious way that occurred to me, to do it.

Extend the integration table for code re-usability

Add some attributes to the digital integration table in order to record thresholds. Perhaps minimum or maximum frequency (i.e. denoting that an integration run at least every 24 hours, or must not run more than once every 24 hours, etc). It might be minimum record counts, or maximum, or max durations for processing.

This is potentially a useful step for a couple of reasons. First, it helps simplify some of our integration checks. For example, we might now be able to create a single scheduled job that checks for a certain class of integration and validates when it last ran, was in bounds.

Second, it lets us CHANGE the frequency, maximum data expected, timings, etc - without editing our scripted checks. We can modify the integration record and it tells us, not the code, what its thresholds are.

Extend the integration table for tracking

At some point, when we receive an event, then an alert, and perhaps an incident against an integration record - we can also trigger the automatic setting of a RAG status field we created, from Green, to Amber or Red. We might rely on that flag returning to green automatically as alerts or incidents resolve and close. We might also want the ability to force this value back to a specific status.

Create a Dashboards

The easiest way to then surface this information, a single pane of glass, is via a dashboard. Looking at data related to the integration records; where they are relevant/directly connected to ServiceNow.

That might include:-

• A triplet of numeric gauges, representing red, amber and green - a count of the integration records with each status against them
• A list of integrations sorted by RAG status, or multiple lists representing each state
• A list of alerts/incidents open against integration records
• In the record level view of an integration record, a related list of active alerts and/or incidents

1. Intro
2. Governance & Preparation
3. Building blocks
4. Bringing it all together