How to Use Extended Script Includes in ServiceNow Scripting

Using Extended Script Includes in ServiceNow is a great way to reduce the code in your scripting

ServiceNow script includes can be extended so you can add new methods and properties as well as override functions in the (parent) script include being extended. Think of them as the closest ServiceNow scripting with JavaScript has when it comes to inheritance in object-oriented programming.

Note that the functionality described using JSUtil is only available in scripting running in the global scope and server side

Here we'll walk you through an example of using extended script includes and how you can call them from a typical place you would use scripting in ServiceNow, noticeably server side business rules on a table.

Create your base (parent) script include

First create the base script include that contains all the functions and properties that all extended script include should have by default. This is the script include that is your "parent" class that your other script includes will extend.

For example, we create a base script include that logs info messages with the current UTC date and time:

var SaiborneUtil = Class.create();
SaiborneUtil.prototype = {
    initialize: function() {
    },
	
	logInfo: function(message) {
		gs.info(new Date().toUTCString() + ": " + message);
	},

    type: 'SaiborneUtil'
};

Create your extended (child) script include

Next create your script include that will extend the base script include. This script include will be the "child" class that may contain functions that override the base and additional functions and properties the base class doesn't have.

For instance, you may want a base script include to do functions related to the task tables and then have child script includes that handle specific task tables like incident, change request and problem.

Continuing with our base script include example, we create a SaiborneExtendedUtil script include that extends the SaiborneUtil script include. In our child SaiborneExtendedUtil script include, we'll override the logInfo() function to log info messages in the user's local time as well as add a new function to get the count of script includes that start with "Saiborne" and end with "Util":

var SaiborneExtendedUtil = Class.create();
SaiborneExtendedUtil.prototype = Object.extendsObject(SaiborneUtil, {
    initialize: function() {
    },
		
	logInfo: function(message) {
		gs.info(new Date().toLocaleString() + ": " + message);
	},

	getUtilCounts: function() {
		var gr = new GlideAggregate('sys_script_include');
		gr.addQuery('name', "STARTSWITH", 'Saiborne');
		gr.addQuery('name', 'ENDSWITH', 'Util');
		gr.addAggregate('COUNT');
		gr.query();
		if (gr.next())
			return gr.getAggregate('COUNT');
		else
			return 0;
	},
	
    type: 'SaiborneExtendedUtil'
});

Call your script includes in your scripting

Now that you have your script includes created, you can call them in the appropriate spot as needed.

Say you want to call your script includes in a business rule to do some processing when a record is created in the task table and its child tables. However for the incident table, you want it be slightly different.

So using our created script includes, we want to log in the user's local time for incidents while for all other task tables we'll log it in UTC. You can create a business rule on the task table as follows:

(function executeRule(current, previous /*null when async*/) {
	// use child util class for incident table to log info local user time
	// and for all other task records we'll log info in UTC
	if (current.getTableName() == 'incident')
        adapterClassName = 'SaiborneExtendedUtil';
    else
        adapterClassName = 'SaiborneUtil';

    var klass = JSUtil.getGlobal()[adapterClassName];
    var sbScriptInclude = new klass();
    sbScriptInclude.logInfo('New record created in ' + current.getTableName() + ': ' + current.getValue('number'));

})(current, previous);

Test out and see your script includes in action

Now when a task record is created, you'll see an info statement in the System Log, with the incident record being in the local time while all other task records will be in UTC.

For example, say we create a change request:

And then create a new incident:

If you look in the System Log you'll see the two different info statements created, with the incident one showing in the local time (in my case that's PDT) since the SaiborneExtendedUtil script include is being called. The change request one shows in UTC time since it calls the SaiborneUtil script include which logs in UTC.

Now create your own extended script includes

The example provided is a basic one to help get you started on creating extended script includes and using them in your ServiceNow scripting. For example, you can make the above code even more dynamic by naming your extended script includes to match tables (i.e. the IncidentUtil script include that extends the TaskUtil script include). That way you can reduce your code even further and just pass the record's table name in dynamically when calling the script includes.

Extending script includes provides a great benefit since you can leverage the same functions and override functions as necessary without having to write redundant code in cases where you have objects that are similar but do have some slight differences. This is generally why you want to use inheritance and extending script includes is the closest implementation of it in ServiceNow.

Feel free to reach out to me if you want to discuss this or anything else further.

---

Saiborne offers software consulting services to help companies meet their business objectives and get the most value out of their software products. We specialize in ServiceNow solutions with our certified experience including development of apps released to the ServiceNow Store with our previous companies. Contact us to find out how we can help you with any ServiceNow needs.