One of the major goals of the ServiceNow IT Operations Management portfolio is bringing business context to IT tools and processes. Service Mapping is one of the main ways this is achieved. By mapping a business service with our automated "top-down-approach," we are able to discover all the components that are strictly related to a particular service. This enables us to do a number of very powerful things. All of the relationship data between the CI's are stored in a table ("svc_ci_assoc") and we can query, report on, and visualize many aspects of the relationship between them. This offers us a number of powerful ways to think about IT (this is by no means an inclusive list):
- Understanding the impact of various types of tasks such as incidents, problems, or changes. We can see not only what components are being affected, but also can see ancillary services being affected by shared CI's.
- Leveraging this data in conjunction with Event Management to view the current state of their environment through a business-centric heat map of the mapped services.
- Understanding the total cost of ownership for delivering a business service. By automating the mapping of all CI's in a service, we can report on a number of different aspects of that infrastructure. For example reporting on all CI's within a business service that extend from the hardware class (check out this excellent blog post by my colleagues Vinh and Richard on how to achieve this: https://community.servicenow.com/community/blogs/blog/2016/06/06/database-views-for-cmdb-reports)
One of the things customers often ask me is "how can I include all of this rich service-aware metadata in our incident email notifications?" They assume if they've mapped their business services with Service Mapping already there must be a way to include information like the affected business services in the email notification.
Well, of course there is! What we need to look at are Email Notification Scripts which will let us query the CMDB for all the necessary relationships to feed into the email templates.
Let's take a look at the out-of-the-box email for an incident.
This happens to be an incident spawned through Event Management, but will work regardless of how the incident is created. We can see a few important fields are included: Caller, Category, Severity, and Priority. We also have a link to go directly to the incident — that's neat, we should see if we can leverage that for our use case.
If we take a look at the out-of-the-box email template for incident_additional_details we see the following:
This is a fairly simple format. We can see that we have the ability to reference incident fields by using the ${field} syntax. Let's start with something simple and add the affected CI in the email template. All we need to do is add a line in the function to reference the cmdb_ci field.
Now let's see what the email looks like:
Great! Now we will have our CI's added to all new incidents being created. What we ultimately want is to add a list of all the business services being affected by a particular incident. It would also be nice if each list element were a URL that took us straight to our service map. Let's look at the data model to better understand how we might go about achieving this.
Here is a screenshot of the svc_ci_assoc table, which holds the relationship data for CI's and the business services they participate in.
Pretty straightforward. What we need to do is query the table with the CI from the incident. Then we can get both the business service name for the URL <a> tag, and the sys_id to compose the URL for the service map.
First we create some empty arrays to store the values we are retrieving. Then we query the svc_ci_assoc table passing in the CI value we said we would need. Since this email script applies to incidents, current is the current incident being processed, and current.cmdb_ci will give us the CI within the incident. From here loop through all the records and push the appropriate values into the arrays (take note that we are coercing the values into strings).
Now it should just be a simple matter of composing the URL for the service map. Let's take a look at a sample URL for one.
https://my-instance.service-now.com/$sw_topology_map.do?sysparm_bsid=f2df02b0d711120035ae23c7ce6103a0&sysparm_bsname=Inventory%20Management&sysparm_plugin_mode=assurance
If we break down the composition of this URL we have a few things.
- The protocol
- The ServiceNow instance
- Some static URL information
- The sys_id of the business service
- The key for the business service name key value pair
- The value (name) of the business service, URI encoded
- A static key value pair (for our case at least)
We should have all this information from the earlier query so let's put it all together.
Here, we loop through all the business service sys_id's we added to one our initial array, and for each one we compose the URL and push it to another array affectedServiceUrls. By using the gs.getProperty function, we can dynamically retrieve the name of our instance. We are also calling the encodeURI function to encode the name of the business service since it contains spaces.
From here it's as simple as printing out a new line in the email template just as we did earlier with the single CI, except now we should have a list of URLs for all our affected services!
Take a look at what our email looks like now.
Great! This seems to be exactly what we were looking for. Let's test the URL and make sure it works correctly.
It sure does! Now users can be brought right to the affected business service straight from the incident notification. This should definitely help drive lower MTTR!
Enjoy!
