Adding sys_id to a report, the easy way

Hi All, long time no post. Figured I’d ease back into this whole blogging thing with an easy post, to start to get the gears turning again!

Little known fact, is that you can actually export in a list the sys_id field, and even add it to a report. The quick and dirty way to do this, is to just export the XML of the sys_report record, update the field_list field and then import back the XML.

There might be a number of different reasons why you want the sys_id in a report, so you can easily match back up to the unique identifier in ServiceNow for the record. It could even be used to reverse craft the URL as well.

Here is an even easier direct user friendly way to add this capability on all List view reports using a UI action. First users need to navigate to the sys_report table and identify their report, then they can just click this simple UI action!

The UI action has two simple lines of code:

current.field_list += ",sys_id";
current.update();

Download and try this UI action in your instance!
AddSysIDToReport sys_remote_update_set_cd2f7e39c3a30210d419de1d050131ab.xml

Node Switcher UI Page!

If you aren’t familiar, when you log into ServiceNow, you are assigned a node dynamically, to serve all your transactions. There many be many situations where you may want to switch to a different node. There isn’t any functionality available to the general public for this (though I know you exist hop2node!)

I developed my own node switching tool as an alternative to Chrome Extensions, since many companies have security restrictions for those. This page instead acts as a native tool within ServiceNow!

A number of you might be wondering how I was able to get this to actually work…. Or even if you aren’t I’m here to explain anyways!

Step 1 - Figuring out how to get the node IP address cookie value for all nodes. For this I had two big hints:
This little tool on the ServiceNow Share: Generate Node BigIP - Switch Between ServiceNow Nodes

https://developer.servicenow.com/connect.do#!/share/contents/4214057_generate_node_bigip_switch_between_servicenow_nodes?v=1.0&t=PRODUCT_DETAILS

This gave me the biggest hint, that part of nodes name on typical deployments, includes the last numbers for the IP address of that node. That saves so much time from a lookup perspective, since you just need to get the ballpark initial parts of the IP address first, since the nodes should be in the same data center.

The next part, which is the even harder part, most tools make use of querying stats.do to get the node IP address. However, that page is pretty long, parsing it isn’t as reliable, and most security advise is to lock down that page. I got a tip from Ahmed Hmeid from ServiceNow Gems to use SOAP against InstanceInfo.do. This is the same way the MID servers get the instance details. Basically just have to spoof a MID server!

Step 2 - Figuring out what the user’s current node is. This part was also harder than I expected. The value of the node stored in the cookie is an HTTP only flag cookie, which means it can’t be read client side at all. However, there are two server side workarounds!

var request = GlideTransaction.get().getRequest();
result.user.node_cookie = GlideCookieMan.getCookieValue(request.getCookies(), 'BIGipServerpool_' + this.instanceName);

result.user.node_name = (GlideServlet.getSystemID() + '').split(':')[1]; //get the second half of the node name

Step 3 - Mechanism for switching the node. Since it’s a special cookie, you can’t just use any normal client side function to change it. I found out though after a bit of digging, that Processors have the ability to write cookies! There is an undocumented function called g_response.addCookie which can set and override even HTTP only cookies.

var cookie = new Packages.javax.servlet.http.Cookie('BIGipServerpool_' + instanceName, node_id);
cookie.setPath("/");
g_response.addCookie(cookie);

All together the flow looks like this: UI Page Pre-Load > Script Include > SOAP > UI Page > Processor > UI Page. I’ve also added some other data enrichment in the script include to grab node metrics as well.

Closing Thoughts

I hope to one day package this up and post it on the ServiceNow share. Just a couple more things I have to get cleared up first (like getting it to work with other node naming conventions, simplifying the MID server user requirement, etc.). Developing this tool was quite the ride and challenge, but I’m happy with the result!

10 UI Pages That Need to Be Talked About

There are a number of tiny little pages in ServiceNow, for users, developers, and administrators alike that could be made use of. Here is my top 10!

1. cancel_my_transaction.do
   This is one that anyone can make use of, to cancel their current running transaction before it times out. Accidently run a crazy report, load this page and it will cancel it.

2. loading_transactions.do
   This one isn’t so hidden, you can get to it via System Diagnostics > Active Transactions (All Nodes). This one is for admins to see all the current running jobs, and ability to kill them.

3. connection_test.do
   Have someone complain about ServiceNow being slow? Have them run this little page, and see if it’s really their connection that is slow instead!

4. cache.do
   This page really ought to be hidden away better… but if you ever need to flush your ServiceNow instance cache, this is the way.

5. cache_inspect.do
   There are some “hidden” ServiceNow elements that are only visible in the instance cache. Here is how you can find them!

6. stats.do, threads.do and replication.do
   I think most people know about these pages, but these give you a wealth of information like current node, running processes, memory, transaction performance, etc. For instances with Read Replica databases, replication.do is helping to track that as well.

7. xmlstats.do
   This is basically a beefed up version of stats.do, to provide the raw data. This page has support for specifying particular ‘includes” so you can view a smaller subset.

8. channel.do?sysparm_channel=logtail
   If you ever want to see the system tomcat logs for the instance in realtime, in your browser, this is fun to watch. Very mind opening how fast and how many things happen in the instance at once.

9. side_door.do
   This is the basic mechanism to use to bypass single sign on in case of a break-glass situation to login to ServiceNow.

10. $m.do
    A little bit of a blast to the past, but you can pull up the old mobile app interface right in your browser!

Honorary mentions: email_diagnostics.do, mid_tools_form.do, governor.do, and some others I can’t remember…

Workflow Tips: Start with a Timer Activity

It’s beginning to be a well known tip, but I’m surprised at how many people still don’t know about this simple trick!

The trick is to include a 1 second timer activity at the beginning of your workflow, or anywhere after a user interaction can happen (approvals, close task, etc).

The way this works is that workflows are started typically based on a user interaction, and then the first activity runs as the user in the user’s session. Depending on the script executed, this can run long on the user session causing a bad experience where the user has to wait on the activity to finish executing. By adding the one second timer it instead breaks off from the user session and queues the workflow to run in the background as a scheduled job.

Besides running in the background, another key benefit is that the scheduled job is run by a system user. This can also sometimes resolve some access errors, and for updates that occur, it will be written to the activity log as the System Administrator instead of the actual user who kicked off the workflow activity.

On the flip side, it’s also considered bad practice to have to many timer activities, and activities in the workflow in general, so it’s good to use this tip in moderation!

ServiceNow KB covering the topic: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0647534

Enabling Dark Mode in the Code Editor

If you’ve developed any significant period of time within ServiceNow. You’re likely very accustomed to the coding editor utilized for displaying code snippits. Your eyes might still be bleeding if you’ve looked at that full screen all white editor for more than a couple hours.

Today we’re going to look at how to add your own theme to the code editor, and how the development could be expanded from there!

ServiceNow actually made use of an open source web code editor called CodeMirror. Thankfully CodeMirror has a robust theming system built in.

Check out their theme demo site to play around and find which theme you like most.

Once you’ve picked out what theme you want navigate to their theme repository and download the CSS file. Next you’ll need to open up the text editor like Notepad++ and replace the CSS class, example: ‘cm-s-mbo’ with the ServiceNow class ‘cm-s-snc’.

Next navigate to your ServiceNow instance, to the table ‘content_css’. Create a new record and paste in your CSS code.

Finally we’re going to load our custom CSS code via an onLoad client script off the sys_metadata table. This will apply the client script code to any configurable record.

var cssId = 'myCss';
if (!document.getElementById(cssId)){
  var head = document.getElementsByTagName('head')[0];
  var link = document.createElement('link');
  link.id = cssId;
  link.rel = 'stylesheet';
  link.type = 'text/css';
  link.href = 'https://' + window.location.host + '/<sysid here>.cssdbx';
  link.media = 'all';
  head.appendChild(link);
}

Finally open up any record with a script and enjoy the change. Pro tip, if not all your coworkers like the theme, you may consider configuring some rules in the client script.

Worth the effort.