If you’ve ever had performance issues within ServiceNow, chances are you’ve gone to look at the performance dashboards to see if anything looks “funny” there. If not, you then check the stats.do page.
Recently I’ve been working on automated monitoring, spotting a situation arising before the customer notices the system is going into slowdown.
While doing this I’ve discovered a new table with a whole load of metrics to read from. Continue reading
Within ServiceNow, anyone can go to any table by manipulating the URL or via the navigation menu.
I.E, if you want to go to the incident table, even if you haven’t access to the incident module, you can just:
Having ACLs in place makes sure that the actions that you don’t want to happen don’t happen (create, write, read, delete). However, what if you just want to stop navigating to that URL in the first place?
You can stop users getting to the page via the navigation menu by editing the ‘NavFilterExtension’ UI Script (it has very good comments in there and easy to edit to do what you want).
I accidentally stumbled across a neater solution, again using ACLs.
Continue reading
Update: Just to add that these Tomcat logs are node specific. So if you want to watch another user’s transactions, you need to be on the same node as that user. To switch nodes, you can use my Chrome Extension that’s on the store. More info is here
When trying to debug an issue, you add alert statements, log statements and info messages to a script attempting to understand what’s going wrong.
Often you can find the root cause relatively quickly. But other times, no matter how hard you look, something seems to be failing at a lower level. This is where the Tomcat server logs come in handy.
Accessing these usually requires downloading the log file and tracking down the exact time to find the issue.
The easier option is to watch the logs being written in real time with this simple Out of the Box UI Page and loading up whichever action your performing in one window, and watching the logs on the other window side by side: Continue reading
A few days ago I posted custom functionality on how to set the value of GlideList variables. Today I had a request from a colleague to find out how to create an equivalent function to g_form.clearValue(variableName) on a GlideList. Again, it turns out this hasn’t been implemented for the new variable GlideList (amongst other functionality). I assume these will all be added over time in the future release, but for now, I wrote a quick function that can be used to replicate the functionality:
A colleague showed me last week how to turn a List Collector variable (slush bucket) into a GlideList variable like on forms. I don’t know how long this option has been around for [edit: Was introduced with Helsinki] but it’s super easy (and I was very impressed because I’ve wanted to catalog GlideList fields in ages). All you do is create a variable of type List Collector as normal and then set the ‘Variable Attributes’ field to ‘glide_list’.
And that’s all there is to it, navigate to the catalog form and you’ll see the Glide List variable. I thought that was the end of it but then the next step was to populate the variable using a client script. It turns out g_form.setValue doesn’t work as expected. What next then?
Let me start this one off by saying I’ve developed a Google Chrome extension and would love you all to download it, try it and if you like it, rate it (and of course tell me about the inevitable bugs within it!).
You can download the extension here: Node Switcher For ServiceNow – Now that’s out of the way, you’re obviously thinking why should you and what does it do?
A colleague of mine at Engage ESM, Łukasz Krzaczkowski, has created a new Google Chrome extension called SwissNow. It comes with many useful features to make your ServiceNow life easier.
These include:
