Script examples

Now we've looked at some server- and client-side Glide classes, we can take a look at some examples of using these methods and properties in some slightly more complex blocks of code to achieve our goals in ServiceNow.

Let's start by having a look at some GlideRecord examples.

This time, we'll use GlideRecord multiple times, one inside another. This is a technique you will no doubt use quite often as you progress with your scripting. It has certainly served me well over the years.

In this example, we'll take a look at creating a problem record for every critical priority incident:

var incRec = new GlideRecord('incident');
incRec.addQuery('priority', 1);
incRec.query();
while (incRec.next()) {

    //Critical incident found, create a new problem record
    var newProblemRec = new GlideRecord('problem');
    newProblemRec.cmdb_ci = incRec.cmdb_ci;
    newProblemRec.short_description = incRec.short_description;
    var newInsertedRecord = newProblemRec.insert();

    //Update the incident with the problem reference
    incRec.problem_id = newInsertedRecord;
    incRec.update();
} 

In the preceding example, we've found all critical incidents using a GlideRecord query. Once we find a matching incident record, we create a new problem record using insert, copying the configuration item and short description fields from the incident over to the problem record also. Once the problem record has been inserted, we store its unique value in the newInsertedRecord variable so that we can add that value into the incident record-related problem field. This ensures the two records are linked and that the incident will appear in the related list on the problem record.

We can see what this script would look like in a scheduled job in the following screenshot:

We will take an in-depth look at scheduled jobs in Chapter 6, Advanced Server-Side Scripting. This figure gives you an idea of seeing the layout of Glide classes in a ServiceNow script field.

Using a GlideRecord inside a GlideRecord is incredibly useful, as we can create, update, or search within a GlideRecord query while loop.

If we know the sys_id of a record, there is a shortcut called get we can use to obtain the record directly. We can use our user-based methods to show a quick way of getting the user record.

The following script uses this get method to quickly access the user record we require:

var userRec = new GlideRecord('sys_user');
userRec.get(gs.getUserID());
userRec.title = 'Manager';
userRec.update();

Using the get method, we have quickly retrieved the currently logged-in user's user record, also using our GlideSystem method to get the user ID. We could also put a sys_id contained in quotes here for the get method parameter. The example then sets the title of the user to be a manager and saves the record. Running this code will make any logged-in user have a manager as their title.

This technique saves us having to use a full GlideRecord query to get the user record that we need. This means not having to search through the user table, which saves resources and also extra lines of code.

We can see what this example code would look like in a business rule in ServiceNow:

We will take an in-depth look at business rules in Chapter 5, Introduction to Server-Side Scripting. They are often used for server-side scripting. We would also need to add a value to the table field so that our business rule knows which table to run this script against.

We can also use some of the techniques we've learned in this chapter to send specific messages to users. Let's assume we want to give users a different message depending on what roles they have:

if (gs.hasRole('admin')) {
    gs.addErrorMessage('Error with solaris server');
} else if (gs.hasRole('itil')) {
    gs.addErrorMessage('Server error');
} else {
    gs.addErrorMessage('An error has occurred, please contact your administrator');
}

This server-side example will display an error message to a user based on what roles they have. This can be useful to display additional information to users who will understand it and it will keep the details simple for users who do not have as much technical expertise.

This code adds error messages that are displayed to the user when the form loads at the top of the screen. By using the if statements, we will only ever display one message to the user and, in our example, the most suitable one for the role of that user.

We can also set some values on a form based on whether it is a new form or not. Perhaps we want to make all new incident forms have an inquiry/help category, but not change any incidents that already exist.

We can see the script we would need for this as follows:

if (g_form.isNewRecord()) {
    g_form.setValue('category', 'inquiry');
} 

With this client-side script example, we would only set the category field to inquiry/help if it was a new record. Remember that this would only set the field on the screen on the client side and would not save the field as this value until the record was saved.

This type of code can be very useful for setting up records in a certain way whilst they are being created. Sometimes it can be that fields are not shown on creation of a new record and are only viewed once the record has been created.

We can see this code in a client script in the following screenshot:

We will look at client scripts further in the next chapter and they are usually the main source of client-side scripting in an instance.

If we wanted to only run script when the record is not new, we can simply place a exclamation mark in front of the if condition to negate the expression and give us the option to add code for updating existing records.

The if statement would instead look like this:

if (!g_form.isNewRecord()) {
}

As you can see, we can use many of the methods we saw earlier in the chapter together to achieve the scripting goals we are looking for.