Speeding up ServiceNow Instance Upgrade Reviews

What is ServiceNow you may ask? In summary the company can be described as a provider of enterprise cloud computing solutions that define, structure, manage and automate services for global enterprises. If you would like to learn more you can click here. Anyways, on to the actual blog post.

As with many developers, I look for ways to speed up tedious tasks. One example is with Upgrade Reviews. Every six months or so a new release happens with ServiceNow. The most recent release is named Jakarta which follows Istanbul. As you might guess, the version naming aligns with the alphabet!

When an instance is upgraded, it logs all the details of each record in a table called sys_upgrade_history_log. Some records in this table will have the disposition marked as ‘skipped’. If you customized a record affected by an upgrade, you must resolve the differences between the upgraded and customized versions of the record. It is best practice to go into each record and review the specific changes for example, a script that has enhancements to a popup feature. To compare these modifications it’s helpful to also have Out Of The Box (OOTB) instances of Istanbul and Jakarta. This provides a clean baseline of each system for comparisons. To explain my review process, I would observe the differences with my assigned instance and compare what I found with the differences of the OOTB Instances. Sounds simple right?

I began reviewing each record one by one. For this particular instance there are about a thousand records to be reviewed. One thousand? After starting I thought eh, how bad could this really be.

It was taking a lot longer than I thought to review each record. I had all the instances open on separate windows to save some time but it still took a decent amount of clicking around on each instance to locate the record being reviewed. I started with the higher priority records first which usually include some complex scripts that need to be compared. I would take each script value from each instance and use a nifty web tool to visually see the differences, and from there, mark if the original record should be retained, merged with, or marked for further review. After reviewing I would reset and then begin to click into each instance for the next record. Very tedious. There has to be a better way.

Sure enough, I found a way thanks to information online and my millions of years of hacking experience. I have outlined my process below.

Thankfully, ServiceNow offers the ability to use REST calls to most parts of an instance. Knowing this I could write a script on my own device to perform GET requests to each record of each instance. Cool right? Let’s break it down a little bit more. Each record has a naming convention of the table name followed by the 32 character unique identifier that is in fact unique across all instances everywhere.

sys_upgrade_history_log Record Examples

I initially wanted to perform a GET request on sys_upgrade_history_log but this particular instance wouldn’t allow it on this table. Instead I exported every File name to a .csv file that I could read with the CSV Python module (import csv) in my script. I would then parse the File name and append it to each request.

In a short amount of time after starting this project I could successfully grab the JSON of each record. The objects are compacted to one line when returned so I needed to find a way to make the output more easily readable. The Python JSON encoder and decoder (import json) allowed me to pretty print the output. After that, another issue I discovered was the unreadable script object due to actual newline characters. I solved this by replacing some characters in the result to make it more readable.
(...).replace(‘\\n’,’\n’).replace(‘\\t’,’ ‘).replace(‘\\r’,’’)

Diff File between two instances

Finally I had clean output. From there I performed a diff across whichever instance output needed. I would then write the results to a file on my desktop. This list of diff files was easily review-able and involved no loading time since all the information has already been pulled. It may seem confusing at first to read but let me attempt to explain it. The < sign show the lines on the original file and the > sign show the corresponding lines on the file being compared. No more copy and pasting into the online Diff Checker tool! After reviewing the differences, I would then mark the resolution of the specific record on the primary instance. Super simple!

Overall this method increased my productivity and saved a huge amount of time. I have since used this method on another Upgrade Review and it has worked flawlessly with just a few modifications to my script. I hope this can help someone that might need the info. Thanks for reading!

If there is something that needs more explanation or you would like to share your opinion feel free to comment or reach out to me personally.