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.
Normalization of data. If you are a DBA you know immediately how painful it can be to get rid of duplicates! I used to cry myself to sleep every night in frustration...well, not really, but I came pretty close.
For me, as a ServiceNow Admin and Developer this pain-point centers a lot around Manufacturer and Model. Let's say I have a computer made by a fictitious company called: Omni-Widgets. Omni-Widgets let's their manufacturing floor personnel put in anything they want into their BIOS for the company name. For example:
- O.W.
- O. W.
- Omn.Widg.
- Omni-W, Inc.
- Omni-Wid
- Omni-Wdgts
- Omni-Widgets, Inc.
- Omni-Widgets Incorporated
And so on. With something like Discovery in place this would end up with all of these generating a record in the core_company table! Arrrrgh!
With Field Normalization it is possible to reduce these down to a single value of my choosing.
The same pain-point impacts with Model as well.
ServiceNow provides a plug-in that can help alleviate this pain: The Field Normalization plug-in. The application provides a mechanism that can rectify existing data, AND intercept and change data about to be written down. Once I set up the rules in the application I never have to worry about this sort of name duplication again. Nice!
As a developer I then do not have to worry about handling all of the various names, but can then depend on a single value being there! Bliss!
So code like the following would actually be reliable. If multiple values were present then dependability would be out the window. I couldn't rely on what value would be returned for sys_id!
var manufacturer = 'Omni-Widgets';
var sys_id = getManufacturerIDByName(manufacturer);
gs.info('---> manufacturer id: ' + sys_id);
function getManufacturerIDByName(manufacturer) {
var manufacturerRecord = new GlideRecord('core_company');
manufacturerRecord.get('name', manufacturer);
return manufacturerRecord.sys_id;
}
The same would hold true for model. If normalized it is simplicity itself to pull back a single value. If un-normalized I would have to figure out a way to deal with the myriad variations that could be present!
var modelName = 'x27549';
var model_id = this.getModelIDByName(modelName);
gs.info('---> model id: ' + model_id);
function getModelIDByName(modelName) {
var modelRecord = new GlideRecord('cmdb_model');
modelRecord.get('model_number', modelName);
return modelRecord.sys_id;
}
For a developer the consistency of data is all important. It reduces the need for extra code to deal with exceptions. Thus reducing the code footprint, and the extra maintenance. Coding for exceptions with data can also introduce unreliability. For Asset and CMDB management it reduces the need for complex reports that might miss certain CIs because the make or model had an exception that wasn't taken into account. Keeping it simple with normalization just plain makes life easier for all around!
Suggested reading:
Normaliziation and Transformation
Enjoy!
Steven Bell.
If you find this article helps you, don't forget to log in and mark it as "Helpful"!
Originally published on: 08-29-2016 07:24 AM
I updated the code and brought the article into alignment with my new formatting standard.
1 Comment
