[UPDATE] – Released a new version of the node switcher
Completely new UI
Automatically recognises ServiceNow instances behind custom URLs (eg, recognises developer.servicenow.com as https://devportalprod.service-now.com)
Works on instances where stats.do page is restricted
As ever, let me know if you’re having any issues with it
There’s a new feature I’ve just learnt about in Kingston.
Using the GOTO feature for searching (image below), the out of the box query that is run is a greater or equal to search.
ie, if I was on the sys_user table, and for the field “name” I searched for Ahmed, it would find all names >= Ahmed. This would return “Ahmed Hmeid” but would also return “Bob Smith” and “Carla Jones” just because they’re alphabetically greater.
I’ve always had issues with this because
1) I didn’t search for Bob so don’t want Bob in my results
2) it’s not very efficient
Pre-Kingston, you could change the default query to be “greater or equal to”, to “contains”.
While this gave better results, it produced far more performance issues because “contains” queries cannot utilise the indexes at all.
Now in Kingston, you can change the default query to “starts with” (finally). This is generally what people expect when they type in the GOTO field. This approach is far more efficient for a better user experience. It also will give more accurate results based on what the user expected to see.
One of our customers is going through some rationalisation and simplification of their ServiceNow implementation. One of the many things we’re looking at, is reducing the number of fields available on CMDB and Task table. I couldn’t find any out of the box method to determine field usage, so I decided to attack this with a little background script.
The script goes through the base class that you pass in as an argument, and gathers all the fields available on that class. It then loops through these, discarding OOB fields by default.
It will then create a row for each extension class, the first column being the class name, followed by the total number of records directly on that class, followed by all the fields available on the table and their usage.
Once completed, it’ll create a CSV file and attach it to your user profile on the sys_user table.
A word of warning, it can take quite a while to run so either run it as a background script and get yourself a coffee, or run it as a fix script/scheduled job so you can continue working. Also consider running this outside of your core business hours.
I checked it on our customer’s CMDB table (1.5mil CIs) and it ran in 30 minutes and while the memory and CPU impact were minimal, running code during operational hours isn’t ever a good idea.
