NOTE: MY POSTINGS REFLECT MY OWN VIEWS AND DO NOT NECESSARILY REPRESENT THE VIEWS OF MY EMPLOYER, ACCENTURE.
DIFFICULTY LEVEL: INTERMEDIATE
Assumes having taken the class SSNF and has good intermediate level of knowledge and/or familiarity with Scripting in ServiceNow. This was originally done with the Istanbul instance. It is remarkable that it still holds true for Vancouver!
Have you ever wondered how a senior developer, in the ServiceNow platform, comes up with the application information that they do? What process do they follow? How is it they chase down information in the platform?
Sometimes it is necessary to really dig, into the platform, to find the information you are wanting to display for the user. In this two-part article you will investigate where certain system information is stored, how to interpret what you have found, and then script it to retrieve the data.
Scenario
As an Admin it is possible to retrieve system information via the stats.do page. This page is not to be found in the UI Pages or UI Macros list views. So it appears to be built-in, or constituted on-the-fly. But where is the information found on this page actually stored? And, how can we access it and turn it to our own purposes?
Pre-Requisites
There are a couple of areas that we will be working with that we will be using in the following labs. You might want to brush up on them before continuing:
Fix Scripts: ServiceNow Scripting 101: Two Methods for Code Development
Also: ServiceNow Studio
Analysis & Investigation
First let's go take a look at the page in question.
1. Navigate to System Diagnostics > Stats > Stats. The Stats.do form will be displayed.
You will notice at the top that there is a lot of useful information here. Build name, build patch, build date, url, and a lot more. This is the "cluster" information. There are typically two servers clustered together for each ServiceNow instance. This allows for fail-over in case something should happen to the "active" node of the cluster. This will give us something to focus our search on where this information lives: cluster.
Optional: If you are ever interested in what open source software is being used by the ServiceNow platform just click on the link: Open Source Software. This contains all of the various open source titles AND their current versions. It makes for interesting reading. For insomniacs. Like me.
2. In looking for "hidden" information like this it is sometimes fruitful to go and see what applications are not active. Since we are interested in anything that might have the title "cluster". We, first will see if there is perhaps something already available in the nav menu.
NOTE: Another place to look would be to search out the UI Pages, UI Macros, or Script Includes to see if there is any reference to "cluster". This would be my usual search order for something like this. Tedious. I know. You can also use the Search capability in the Studio to do a search, but OOB it doesn't pick up everything.
3. Type cluster in the nav filter.
You will see that there are only entries under Configuration (CMDB), and MID Server. Neither of these are pertinent to our quest!
Next let's see if perhaps there is something we could use that just isn't turned on in the menu.
4. Navigate to System Definition > Application Menus
5. Modify the list filter to search for everything with the word Cluster in the Name field, and make sure that active is false (default is true). We notice that there is an application listed by the name of System Cluster. And it is not active! Looks promising.
6. Click on the System Cluster entry. Scroll to the bottom of the form and you will note that there are five modules contained here. Since we know what is being displayed in stats.do is the current cluster node status, the link Node States looks promising. It shows there is a table called: sys_cluster_state.
7. In the nav filter type in sys_cluster_state.list. The list view for that table will be displayed. This is where the cluster node state information lives! Ah, better and better! Only one cluster node is displayed (the one we are logged into; and I am using my PDI which only has one anyway), and it has a system id that looks like the one we saw in the stats.do page!
8. Open the record. The Node State form will appear. This contains the patch info under the Assigned version field. Okay, we are cooking with gas now!
9. Since you are logged in as an Admin right-click on the Assigned version label. You will find that there is NO field there! Right-clicking on Additional details does not show us a field either. This is generated information that is tacked onto the end of the form. So let's go find out what is actually being referenced for this information to be displayed. Whenever you see something like this you will need to suspect it is actually a UI Macro that is being referenced and not a field.
10. Right-click on the form header to the display the context menu for the form.
11. Navigate to Configure > Form Layout. The form layout form will be displayed.
12. Notice that there is an oddly named field: Cluster State Summary at the end of the "Selected" list. This is not a real field (column); you won't find it in the "Available" fields. It is more likely to be a UI Macro. To be sure, we will check the table dictionary for this table (sys_cluster_state).
13. Click on the Cancel button.
14. Navigate back to sys_cluster_state.list.
15. Right-Click on the list view header bar to get the list view context menu.
16. Navigate to Configure > Dictionary. The Dictionary Entries for the table will be displayed.
17. Add Column label to the list view fields.
18. Search for Column Label of Cluster State Summary. Not there. That pretty much clinches it. It has to be a UI Macros. UI Macros provide a way of creating your own container to build a specialized display like this and tack it into a form. Thus such a container would be my first guess.
19. Alrighty then. Navigate to System UI > UI Macros.
20. Search for name: cluster. Bingo! There is one: cluster_state_summary!
21. Open the cluster_state_summary record. The Macro form will be displayed.
22. In the XML section of the macro we observe that there is a section of code that actually shows where the information is being retrieved from! Outstanding! The idea, not the code. I mean, three-letter-variables??? (variable naming)
Ah ha! We notice that this information is being kept in the sys_cluster_state table in a field named stats. It was there all along! The UI Macro just takes some of the data and formats it nicely for display. So it appears we may have our code example to retrieve the patch information we want!
We shall, um, appropriate it for our own uses. BTW, this code is not Scope safe. The "$" and XMLDocument are not allowed. So, we will have to find another way to do the same thing in our code.
23. Copy ALL of the code inside the <g2:evaluate> tag (to the end of </g2:evaluate>). Just the code, and not the tags. Paste this in your favorite editor for safe-keeping (we will look at it now, and reference it as we construct our code).
var g_xmlDoc = null;
var g_url = "";
var g_baseRecord = new GlideRecordSecure('sys_cluster_state');
if (g_baseRecord.get('$[sys_id]')) {
g_xmlDoc = new XMLDocument(g_baseRecord.node_stats.stats + '');
g_http_url = 'http://' + g_xmlDoc.getNodeText('//servlet.hostname') + ':' + g_xmlDoc.getNodeText('//servlet.port');
var ngr = new GlideRecordSecure('sys_trigger');
ngr.addQuery('system_id', g_baseRecord.system_id);
ngr.query();
g_jobs_assigned = ngr.getRowCount();
}
And that is it for our investigation/analysis stage of things!
Obviously when you get comfortable with where information might be stored in the platform you can skip some of these steps. What I endeavored to show here were the "exhaustive" steps so that you would get the idea on what is involved to actually track the desired data down.
In my next article I will be showing how to utilize the material we have located, and incorporate it into something for our own use!
Enjoy!
Steven Bell.
If you find this article helps you, don't forget to log in and mark it as "Helpful"!
Originally published on: 4-9-2017 08:18 AM
I updated the code and brought the article into alignment with my new formatting standard.
1 Comment
