As a systems admin, chances are you’ve got a whole host of monitoring tools and data sources to keep track of: ServiceNow, SCOM, Splunk, Solarwinds, plus your APM and CI/CD tools too. With SquaredUp, you can get a single pane of glass, surfacing your ServiceNow ITSM data alongside data from these other techstacks too! For an introduction on how to get the full picture of your ServiceNow data, head over to Part 1 of our ServiceNow Tile blog series.
In this part of the series, we will be explaining in detail how the tile works, plus going over some tips and tricks.
The core of this integration is SquaredUp’s Web API tile, slightly modified with some pre-populated queries, that allow you to easily request information from ServiceNow without having to build your own API request.
Before we can configure anything in SquaredUp, we must first allow access into ServiceNow by using an Application Registry for an OAUTH API endpoint for our external client (SquaredUp), which allows us to read the information from SquaredUp (more info here).
And this is important: SquaredUp only reads from ServiceNow and does not make any changes. If you are looking to send data to ServiceNow, stick with me, I’ll talk about this a later in this article.
Once the permissions are configured in ServiceNow, we can configure a provider in SquaredUp, a simple setup of “where we’re going” and “how we’re authenticating” to gain the data. There’s a dedicated type to create a new Web API provider for ServiceNow.
Now we can go ahead and create a new tile, choosing our ServiceNow tile (this will show, even if you haven’t configured the provider!).
Select one of three ways to display the data – Donut, Scalar, and Grid. Each has their ideal use cases, as mentioned in part 1 of this series.
We can request data from ServiceNow either un-scoped (no objects defined) or with a scope (listed objects, groups, or classes). The first is great for high-level insight, the latter is best for refined views, think Service Desk, or an application team.
The provider will prompt you to select which provider you have created – You can have multiple ServiceNow providers, if you’re a CSP or MSP for example, and this will only display the providers that have used the ServiceNow type.
The ServiceNow tile allows us to query either Incidents or Changes. Both table options give us the ability to use our existing filters from ServiceNow, such as active/closed, and the grid display lets us choose our views created in ServiceNow, allowing us to only display the columns we require.
Sounds limiting right? Just incidents or changes. But wait, there’s more! Using SquaredUp’s Web API tile allows you to query any table in ServiceNow, giving you access to any custom tables your org has created, as well as some of the other useful out of the box ones – Like the CMDB.
And this is another important area – How does SquaredUp relate the scope that you specify from SCOM, to your data from ServiceNow? Well, it’s fairly simple: SquaredUp uses the display names of the objects you scope and adds this to the query automatically and asks for related cmdb_CI objects with the same name in ServiceNow.
A big question on your mind: How do we ensure we have our CMDB populated in ServiceNow so that this scoping works? I’ll only say this once more: Stick with me, I’ll talk about this later!
Let’s spice things up a bit.
So you’ve queried the ServiceNow API for asset information, which is great, but there is going to be a whole lot more information for a CI than you want to place in a dashboard. You’ll notice the last section in the configuration is for a Row Link. What’s a row link? Well, it’s a simple URL that can be parameterised using data returned from the API, including the sys_ID – And guess where the sys_id appears? That’s right, in the URL! So we can look at a CI in our ServiceNow instance and pull most of the URL and paste it here. Then select the property from the mustache picker.
One click now takes you to the CI in the service now portal – A minor time saver, but one that reduces the clicks required to get to information, which in turn could reduce your mean-time to resolution.
A property seldom used in SCOM is the ticketID. This simple property allows you to specify a value from your ticketing tool, sometimes automatically if using a tool to raise tickets from your alerts from SCOM, sometimes manually by your Service Desk. This helps you see if a ticket has been raised for an alert, and those of you who have automation in place to do this, will be happy to hear you can link directly from your alerts to ServiceNow using SquaredUp’s ticket template! A small change to a config file on the SquaredUp server allows you to link off to your ticketing of choice (if you’re here, it’s probably ServiceNow), and when a ticket ID is added to an alert, you can jump to the ticket with one click from SquaredUp’s alert drilldown.
Linking out to ServiceNow is great, but did you know that all URLs in SquaredUp are unique? For example, an alert has a specific URL: https://squaredupserver/squaredupv4/drilldown/scomalert?id=e000c158-d9da-413f-9899-b5b63f4e4a3c
You can add this to your tickets so your Service Desk can link back to a great portal to examine the monitoring data related to the alert! If automating the ticket creation, this can be added easily as it’s just a property against the alert, possibly something you already sync to ServiceNow.
Even a performance drilldown is unique, and any comparisons or specific time ranges are included:
Why is this useful, you may ask: Well it’s simple – During troubleshooting, wouldn’t it be great if you could examine performance and then come back to a specific view? Exporting the data is great, but a live link that you can change date/time ranges and comparisons may be even better.
Hopefully all of this sounds good to you and you’re itching to get going with the SquaredUp ServiceNow tile. The good news for you, is that this isn’t all you can do with SquaredUp! To learn more about all the other ways SquaredUp can help you up your monitoring game, check out our ‘Do it with SquaredUp’ page.
Okay, so I’ve been hinting pretty heavily throughout the article above that it would be fantastic to have data synced from SCOM to ServiceNow, but this is generally seen as a huge task; whether manual or automatic, it’s not seen as something that can be achieved overnight.
You’d need great knowledge of SCOM and ServiceNow to set this kind of thing up, and there are vendors out there who will charge you an arm and a leg, possibly your first born, just to set this up for you. And even then, it requires a fair amount of time and resource to set up.
Well, to quote my favourite cartoon professor: Good News Everyone! Cookdown has integrations for just these circumstances and you won’t need to sell one of your doomsday devices to get it. You can:
Sync your alerts bi-directionally using Alert Sync
Automatically populate your CMDB using discovered objects from SCOM using Cookdown Discovery!