2. Why a Script Include?

This is some of the basic understandings of Script Include, and how they are used within the ServiceNow environment.  This article is not written for Senior level developers or architects.  We are going to lower this down to entry level and junior level.

To begin check out the ServiceNow Docs for Script Include.

The purpose of this article is to help one understand how great Script Include really are!

So, lets begin.

First, notice the picture above.  A hurricane/typhoon and how large they are.  They bring high winds, lots or rain and lots of clouds.  They make a great impact.  Though their impact can be deadly and cause a lot of damage.  But in this case, lets look past the damage and we will just focus on the great impact.  A hurricane can be seen for miles.  It can be seen at your house and at your workplace.  It can be seen across multiple cities and even multiple states or countries.  This is the concept of "Cloud Computing".  What can be done at home on your personal PC can also be done at your workplace on your work PC. 

Gone are the days of having to write something on your work PC,  saving it locally, copying it to a USB drive, taking that USB drive with you and continuing to work on it at home.  A Script Include is ServiceNow's version of Cloud Computing (so to speak).

A Script Include is that Hurricane that can be seen for miles away.  Inside of ServiceNow world, a Script Include can be called from anywhere you can use a script.

We've all started a client script before and realized that,  "oh, that's a server side API, we cant do that from a client side script".  We've all needed to write a script that we remember just writing that last week in a Business Rule,  so you go copy it from the Business Rule you created.  Maybe you are writing a Fix Script to perform an action and you realize,  hey Susie Q from our team did that  a few weeks ago, so let me go find that script and copy/paste it.  Then if something in that code needs to be changed, you may end up changing it in multiple places.

Enter the Script Include.  So lets dive in.

These scripts are great for re-usable, small, purpose built chunks of code.

It's absolutely not uncommon to do a GlideRecord Query to get a User Record.  I find myself writing similar code all the time.  ServiceNow is built around users and we always need information about one of the users.  Similar, groups are a very important part of roles and permissions.

You could constantly be writing GlideRecord queries like these:

var grUser = new GlideRecord("sys_user");

grUser.addQuery('sys_id', ID);

grUser.query();

if(grUser.next()){

//do something with the user

}

var grGroup = new GlideRecord("sys_user_group");

grGroup.addQuery('sys_id', ID);

grGroup.query();

if(grGroup.next()){

//do something with the group

}

You could be writing these queries over and over and over and over again. In Business Rules, Client Script (though you should not be writing GlideRecord queries in client scripts,  we'll talk about this later), UI Actions, Scheduled Jobs,  etc...  etc....   etc.......

So what can we do?  Lets create a "global" Script Include.  I'm going to recommend that you create a Script Include where you put everyday functions.  Things that you build and test and that you know they work, that can be used again and again and again.
I encourage you to create this, use it and constantly update it with new functions that your business uses.

So create a new Script Include that is in the global scope so it can be called from anywhere and any scope.
We'll name it "everydayCode".

It should be accessible from all application scopes. 

#######################################

var everydayCode = Class.create();

everydayCode.prototype = {

    initialize: function() {},

    getRecord: function(table, encodedQuery) {

        var grRecord = new GlideRecord(table);

        grRecord.addEncodedQuery(encodedQuery);

        grRecord.query();

        if (grRecord.next()) {

            return grRecord;

        }

        return null;

    },

    getUser: function(encodedQuery) {

        var grUser = new GlideRecord('sys_user');

        grUser.addEncodedQuery(encodedQuery);

        grUser.query();

        if (grUser.next()) {

            return grUser;

        }

        return null;

    },

    getGroup: function(encodedQuery) {

        var grGroup = new GlideRecord('sys_user_group');

        grGroup.addEncodedQuery(encodedQuery);

        grGroup.query();

        if (grGroup.next()) {

            return grGroup;

        }

        return null;

    },

    type: 'everydayCode'

};

#######################################

As you can see the "getRecord" function takes 2 parameters,  the table to query and the encoded query to use.

The "getUser" takes 1 parameter which is the encoded query to use.

The "getGroup" takes 1 parameter which is the encoded query to use.

So,  with the example here,  you don't necessarily need to use the getUser, or getGroup.  You could use the getRecord.  You're asking yourself,  ok, I have the Script Include, now what do I do?  I'm glad you asked.

Lets say you're writing a Business Rule and you need to get information about a user that was provided in a field.   In your BR,  you can do something like this:

var everydayCode = new global.everydayCode();

var user = everdayCode.getUser('sys_id=' + current.(user field));

var group = everdayCode.getGroup('sys_id=' + current.(group field));

Explanation:
var everydayCode = new global.everydayCode();

new  is how we begin the script include call.

global. is the scope in which the script include is in.

everydayCode().  is the name of the script include

getUser  is the method(function) in the script include to call.

(parameter(s))  a bit of data passed in, separated by a comma for each parameter This could be a GlideRecord object, an array, a string, an integer, etc....

So you make the script include call a single time, and then can use multiple methods within the script include.

Looking at this example, the "getUser"  is very specific to the "sys_user" table and the "getGroup" is very specific to the "sys_user_group" table.  But what if I need to get other records.
Rather than create a function for every single table in the instance, you create a generic function to return data based on parameters passed in.  that this is where the "getRecord" comes into play.

You can do this multiple ways.

var table = "cmdb_ci";

var query = "asset_tag=" + current.asset_tag;

var record = new global.everydayCode().getRecord(table, query);

OR

var everydayCode = new global.everydayCode();

var cmdbCI =  everydayCode.getRecord('cmdb_ci', 'sys_id=' + current.(variable));

var location = everydayCode.getRecord('cmn_location', 'sys_id=' + current.(variable));

var user = everydayCode.getRecord('sys_id', 'sys_id=' + current.(variable));

So,  looking at the code above,  While you are performing multiple GlideRecord queries, you aren't writing and re-writing the GlideRecord query,  you're just calling a Script Include and passing in the required parameters.

This is how you can effectively leverage a re-usable method (function) in a script include.

You can use this approach on any server side script.

When it comes to a client script, or catalog client script it gets a little more complicated.  You need to use GlideAjax.  But the concept is still the same,  small re-usable chunks of code.  But for performance reasons, do not use a GlideRecord directly in a client script.

Some very good reasons to use Script Include:

1. Re-usable
2. Central place for code
3. Can be called from anywhere in the system
4. It's easy to test the code
5. When you change it, it's changed everywhere that is calling that method.

Questions?  Let me know below!