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!
Picking up where I left off in my previous article (Mini-Lab - Analysis Example: Chasing Down Hidden Data - Part 1); we have finished our analysis, and located the patch information. Now we will make use of it.
Tasks:
- Create a Fix Script to do a proof-of-concept (POC) to retrieve the patch information and store it in a variable for further use.
- Create a UI Action on the Incident Form that will place the patch information into the work notes field. This will be how we will demonstrate a practical use.
So, let's get moving with development!
Development
Remember the code snippet we found in the previous lab?
var g_xmlDoc = null;
var g_url = "";
var g_baseRecord = new GlideRecord('sys_cluster_state');
if (g_baseRecord.get('$[sys_id]')) {
g_xmlDoc = new XMLDocument(g_baseRecord.stats + '');
g_http_url = 'http://' + g_xmlDoc.getNodeText('//servlet.hostname') + ':' + g_xmlDoc.getNodeText('//servlet.port');
var ngr = new GlideRecord('sys_trigger');
ngr.addQuery('system_id', g_baseRecord.system_id);
ngr.query();
g_jobs_assigned = ngr.getRowCount();
}
It appears from this code that the information we want is in the sys_cluster_state table, and is found in the stats field. Further since the XMLDocument object is used to pull the data from the field we can infer that the data there is XML. This STILL does not give us our patch info, but we are one step closer!
- In the nav filter type: sys_cluster_state.list. This will again display the list of cluster nodes.
- Click on the Gear icon on the list view header bar. The list of available fields will be displayed.
- Add the Node stats field and click OK. The list view should now show the stats field.
- Click the Node Stats field link. This will jump you to the Node Stats form.
- In the Stats field select all and copy out the XML. Paste into your favorite XML formatter/editor.
6. Make a note of a couple of things. Click on the tri-lipse (hamburger) in the upper left of the form to get the pop-up menu and do a Show XML
a. Table that the form is based on is: sys_cluster_node_stats
b. Close the XML pop-up and right-click on the Stats field to get the field name: stats
c. Right-click on the Node ID field and get the field name: node_id
d. Record the value of the Node ID (this was mine): ce409ab2fafd74fa60cdbcebe05dc28d
7. Remember that in the stats.do page the name of the field was "Build tag". This will probably be where it is in the XML. A quick look at the XML in our editor shows that spaces are replaced with periods. So, I infer that it will probably something like: build.tag or build_tag.
8. Since a quick look at the XML shows naming to be either underscore or dot naming convention we do searches for Build Tag. So, in your editor search for the word build.tag. You will find it close to the end of the file, AND it will appear to have the patch info!
Note the name of the XML field the "patch" data is contained in. It should be: <glide.build.tag>. This is the field we will retrieve our version and patch information from. We also see that the build date is right before it and is contained in: <glide.build.date>. We can grab that as well!
9. Now let's create a Scoped application to contain our new scripts in. Navigate to System Applications > Studio. The Studio Application List form will be displayed.
10. Click on the Create Application button. The Create Application form will be displayed.
11. Fill out the form with the following:
Name: System Functions
The Scope field will auto-fill
12. Click on the Create button. The Create Roles form will be displayed.
13. Click on the Continue in Studio (Advanced) link. This will return you to the Application list to select our new app.
14. Select our new application: System Functions. The Studio will be displayed.
15. Click on the Create Application File button. The Create Application File form will be displayed.
16. In the Filter field type Scheduled Script Execution. The Filter Results will show Fix Script and it will be high-lighted.
17. Click on the Create button. The Scheduled Script Execution form will be displayed.
18. Fill out the form with the following. In the script we will be using the information we recorded in step 6:
Name: Retrieve Patch Info (POC)
Run: On Demand
Script:
var stats = {};
var nodeID = 'ce409ab2fafd74fa60cdbcebe05dc28d';
var clusterState = new GlideRecord('sys_cluster_node_stats');
if (clusterState.get('node_id',nodeID)) {
// parse the stats field (it is XML)
//gs.info(JSON.stringify(gs.xmlToJSON(clusterState.stats.toString()))); // debug
stats = gs.xmlToJSON(clusterState.stats.toString());
// Retrieve the version build and patch
versionAndPatch = stats.xmlstats['glide.build.tag'];
// Retrieve the version build date
buildDate = stats.xmlstats['glide.build.date'];
gs.info('---> \nVersion and Patch: {0}\ndate: {1}', versionAndPatch, buildDate);
}
So there is a lot going on here:
a. We grab the record for our node.
b. We then pull the stats record (which is in XML) and use the nifty GlideSystem xmlToJSON function to turn it into usable JSON.
c. To drill down to the values we want we have to "dot-walk", but we can't if the field has dots already in it. This is the way you get the information out of the JSON with those kinds of fields. Remember that JSON has two ways of referencing: 1) dot-walk, 2) object array
19. Click on the Submit button to save your work.
20. Click on the Execute Now button to run the Scheduled Job.
21. Navigate to System Logs > System Log > All and filter Message for "--->"
Your results should look something like this:
22. Eureka! It works! Um, well that came out wrong. Maybe, Vancouver! It worked! 😃 Please don't moan too loud. I do try to lighten up this material.
24. So, now that we have what we were after; the build version and date, what do we do with it?
Create a UI Action that pumps it into an incident's Work Notes, of course!
25. Back in the Studio click on the Create Application File button.
26. Type UI Action in the Filter field. The UI Action should appear in the Filter Results.
27. Click on the Create button. The New UI Action form will be displayed.
We will be using the script we just developed in the Scheduled Job and we will be adding a couple of lines. One to set the Work Notes value, and the other to update the current record with the information.
28. Fill in the form with the following:
Name: Add Patch Info
Table: Incident
Form button: checked
Active: checked
Show insert: un-checked
Show update: checked
Comments: Add latest instance version, build, and patch info to the Work Notes field.
Script:
var stats = {};
var nodeID = 'ce409ab2fafd74fa60cdbcebe05dc28d';
var clusterState = new GlideRecord('sys_cluster_node_stats');
if (clusterState.get('node_id',nodeID)) {
// parse the stats field (it is XML)
//gs.info(JSON.stringify(gs.xmlToJSON(clusterState.stats.toString()))); // debug
stats = gs.xmlToJSON(clusterState.stats.toString());
// Retrieve the version build and patch
versionAndPatch = stats.xmlstats['glide.build.tag'];
// Retrieve the version build date
buildDate = stats.xmlstats['glide.build.date'];
current.work_notes = gs.getMessage('Version and Patch: {0}\ndate: {1}', [
versionAndPatch,
buildDate
]);
current.update();
}
29. Click on the Submit button to save your work.
Testing
Now that we have finished our new utility up, let's go test it!
- Navigate to Incident > Open, and open your favorite incident from the list view. You should now see the new Add Patch Info button at the top of the form.
- Click on the new Add Patch Info button. Two messages will appear at the top of the form informing you that Execute and Write operations have been given cross scope privileges for your application. This is normal, and automatically added to your System Functions application. This is in case you ever decide to publish it; the application will have the correct privileges.
3. Scroll down to the Work Notes field and note that the Version, Build and Patch information along with the Patch Date were added to the work notes. Cool beans!
4. You may want to now inactivate that UI Action as it has served its purpose.
5. You may now also want to close your Studio as we are done with the application.
Analysis
The reason we are using a Scheduled Job to do our modeling is that unlike Fix Scripts it is not automatically executed on deployment! Terrible functionality now for Fix Scripts. For a little bit deeper dive see my article here: ServiceNow Scripting 101: Two Methods for Code Development.
We parse the XML using gs.xmlToJson functionality to be able to more easily access the values we need. This is much much better than doing the old XMLDocument2 parsing. Both are scope-safe.
Remember to use gs.info instead of gs.log as it is also Scope safe.
There you go! As you can see things can get somewhat convoluted, but this is a good example of "chasing-the-chain" down to the desired data.
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-13-2017 03:10 PM
I updated the code and brought the article into alignment with my new formatting standard.
3 Comments
