ServiceNow CAD – GlideSystem

1. GlideSystem Introduction

Hello, and welcome to section Five, where we’ll be covering the Glidesystem API. We’ll start this section with an introduction to Glidesystem, followed by the Show me the code slide. Then we’ll go over the Glidesystem API diagram. Next, we’ll cover a list of common Glidesystem methods, followed by dissecting some of the most important methods out. Then we’ll cover the concept of events in ServiceNow and do an event demo as well. Then we’ll jump into ServiceNow, where we’ll actually write some code using the Glidesystem API. Finally, we’ll end this section by discussing where we can use the Glide System API and cover the API documentation.

The ServiceNow docs state the Glide System API provides a number of convenient methods to get information about the system, the current logged in user, et cetera. The Glide System API is server side, so you cannot access Glidesystem on the client side. As a developer, generally you’ll use Glidesystem to access information about the system or user data.

You reference the glide system API by GS. The glide system API does not need to be invoked like the glide record API did. It’s just automatically available to you at any time within a server side script. There’s also a number of helper methods available to us within the Glide System API. All right, so let’s check out some code. In the first example, we want to print a list of all incidents where the caller is the current user. So how can we dynamically get the current user?

Well, it turns out there is a Glide System method that will return that information to us. So all we have to do is use this. In the add query. Glad record method. We simply add GS, get user ID and service now handles the rest. This method actually returns the sys ID of the current user. Easy enough. In the second snippet, we’d like to create a user greetings message for the service portal. We want the message to say Good morning, Mark, good afternoon, Mark, or Good evening, Mark, depending on the time of day. Instead of using Mark, we also want to dynamically use the name of the current user.

Well, it turns out there’s a Glide system method that will return the user’s display name that is stored in their user record. So here on line eleven, we simply add GS Get User Display Name, which will return the current users display name to us. Now, let’s take a look at the Glidesystem API diagram. As stated before, Glidesystem is actually referenced using GS within our scripts. Its properties have to do with user data, session data, as well as some date data. Some common methods include gitmess, message, event queue, beginning of last month, Get User has roll, ETCA. In the following videos, we’ll take a deeper look at these methods.

2. Common GlideSystem Methods

Hello and welcome back. In this video we’ll take a deeper look into some common glide system methods. All right, so we’ll actually be going over the first five of these methods here within the next few slides. So for the time being, let’s go ahead and skip down to the 6th one git session. The Git session method will return the user ID that ServiceNow uses to keep track of sessions inside of the system. This can be important when dealing with security or things like the service portal. The next method is Print, which we should be familiar with this by now. It simply prints something to the screen, kind of like a console log within a browser. The next five methods are used for system logs. These can be helpful when debugging scripts. We’ll go into these in more detail in the 9th section of this course, where we’ll actually be covering debugging in depth.

But for now, just know that they will log messages to certain places within the system log. Next is the Generate Guid method which will generate a globally unique ID for us, which is commonly referred to as the SysID within ServiceNow. This can be helpful when we need to generate a SysID or some other type of unique identifier, possibly in a custom application. Again, this system ID or Guid is a 32 character hexadecimal string. The next method, Get user will return the current user object to us. We can even chain additional functions onto this. As we’ll see in the demo video, the has roll method will take a string argument the name of the role and test whether or not the current user has this role. This is used all throughout the system and is quite powerful when factoring in security in your application. We then have the Is logged in and is mobile methods which can be helpful in service portal scripts. Next is the Nil method, which is very helpful when testing whether or not a value is null. We’ll take a look at this method in more depth here. In just a few slides, the set redirect method will redirect the user to the provided URL string.

This is commonly used within record producers after a user inserts in the new record. A lot of the times we would like to redirect them to that newly inserted record. In addition to git property, we also have the ability to set a property with Set property. All right, now let’s look at some common message and log types. So let’s start by add error message and add info message. Here we see two messages the add error message which is shown in red and the add info message which is shown in blue which are actually shown to the user on the client side. Now let’s take a look at three different log methods GS log, GS Warn and GS Error. Here on the left we can see the application navigator and that these three methods actually map to modules here. Also on the right, we can see a log entry on the log table. So anytime you use GS Log and a script, you can find these log messages by navigating to the Script Log Statements module under System Log.

 If you use GS Warn, you can find these under the Warnings module. And finally, if you use GS Error, you can find these in the Errors module. The Log Warn and Error methods can be helpful when you would like to diversify the type of messages you receive from scripts. So if there’s a serious problem in a script that would not allow it to continue running, you would use something like an error. Whereas if you were just simply printing something to the log table, you could just use a log method. All right, now let’s discuss Glidesystems get message method. Because Service now supports a number of languages, we need a way to grab translations for specific messages. Well, the Get message method does just this. Let’s say we have the word welcome on the Service portal, but we’d like it to say Ola. If the current user has Spanish selected as their default language. Well, using the Sys underscore UI underscore Message table, we can do this very easily. Gitmessage accepts one argument the ID of the message typically just the full message as a string. Then behind the scenes it uses the current user’s language and queries the Sys UI message table where it finds that specific translation.

By default, if no mapping or language is found, it will use the system default language, which is typically English. So in the diagram below, we can see that my current language is set as English. And on line two, when I use GS Git message and I pass in the variable message as an argument, it would query the Sys UI message table and find a key of welcome with a language of English and send me the message value. It’s very common to use this when dealing with translations and customer facing portals like Service portals. All right, now let’s move on to the Glide System get property method. Oftentimes when we are scripting, we need to reference some type of value found elsewhere in the system. Well, we can use System properties to store these values. On the sys properties table. The Git property method accepts the name of the system property as a string and returns the property’s value to us.

It’s best practice to use properties instead of hard coding something like Sysids or other values into scripts. Instead, you should create a new system property for a SysID and then reference that value in the script. It just adds an additional layer of abstraction so we don’t have to edit the actual code. If that value were to change, you can simply go into the Sys Properties table and update that value within service. Now, so in this example, we would like to grab the value of the Glide UI buttons underscore bottom property.

So we call the Get property method and we pass in this name as a string. Now, ServiceNow will go to the Sys Properties table and retrieve this value for us. In this case, a boolean of true. All right. And we’ll end this video by taking a look at Glide Systems Nil method. Oftentimes we would like to find whether a variable has a value assigned to it or not and then perform logic on that. But because returned variables like glide record fields are actually objects in service now we can’t just simply test for a blank string or a false value. For example, say we have a variable field which has a value and display value property.

Now, let’s pretend this field variable is actually a glide record field, like the number on an incident record. Well, if we wanted to test whether the field contains a value or not, we cannot simply do field equals a blank string, like what we see here on line six. This would actually return false because field is an actual object with properties as opposed to just being a string data type. So instead of using something like this, we can leverage Glide Systems Nil method. So now on line four, we use Gsnil and then we pass in the glide record field. In this case, incidentgr short description.

3. Events in ServiceNow

Hello and welcome back. In this video, we’re going to put the Glide system API on the side right now and discuss an important concept in ServiceNow events. In this video, we’ll go over how events and ServiceNow work, go over a brief demo, and discuss how this fits with Glidesystem. So what is an event? Well, events can be many things. User events can be things like mouse clicks, mouse movements, or key presses. So say you’re playing a game in your browser. The game needs to be able to record these events and act upon them. For example, a left mouse click would fire a weapon, and a right mouse click would reload. System events generally have little to no human interaction.

These can be things like time. Simply, time passing could be an event. Once something reaches 10:00 p. m. , perform this action. System events can also be database operations, as we’ll see here in a second, such as any Crud operation that we would have against the database. System events can also be caused by network activity. For example, say there’s a third party web service that’s interacting with our application. Well, if we receive network activity from this service, then we could act upon this. All right, now let’s take a look at events in ServiceNow. I would like to point out that this topic was discussed in my Service Now 101 administration course.

So if you have access to that course, and this isn’t making complete sense, I recommend checking out the video and ServiceNow 101 as a refresher. All right, so events in ServiceNow can be triggered by Crud operations on tables. In the world of ServiceNow, we act upon these triggers using business rules, so we can say if a new incident is inserted, then perform this logic or run this script. Events can also be triggered by workflow activities. So say we have a workflow for a catalog item. Well, if the catalog item is finally approved by the approver, this would in turn trigger the approval workflow activity and continue within the workflow process. Finally, events can be triggered by scripts, so we can have scheduled jobs or web services or so on. Events and ServiceNow must be registered. And we’ll go over what that means in more depth here in just a second.

But this is essentially informing Service now of a specific event. So with that, there are three main components to the events in service now. The registry, where it’s actually registered, an event action such as a script action or a notification, and the event log, where once the event is executed, the system creates a log entry for that event. All right, now let’s explore these three components in more depth. So first we have the registry event component. So here we have a screenshot of an event in ServiceNow. ServiceNow 201. Hello, world is the event name.

Normally we apply a table, but for the purposes of this example, we’ll leave the table field empty. And then it’s best practice to populate the fired by and description fields on an event as well. The event registry record isn’t where we’re actually performing any type of logic, it’s just a way to let service now be aware that this event is out there and exists. So now let’s take a look at event actions. So an event has occurred, let’s act upon this.

So, the two most popular event actions in service now are script actions and notifications. On the left we see a screenshot of a script action. And a script action is just simply a server side script that runs when a specific event is triggered. So we can see here that we select an event name in the drop down. In addition to script actions, we can have notifications fired when an event is triggered. So maybe we would like an email to be sent to a group of users when a knowledgebased article is about to expire. As shown on the right, we can see that we specify the actual event name within the notification record as well. And finally we get to the third component, the event log.

So this is a log of all of the events that happen in ServiceNow. The log shows the name of the event as well as two parameters that you can pass in, which we’ll take a look at here in a second and some additional information about what happened with that event. All right, now let’s break down the process of the event queue. So, because events can be so many different things, we might have a number of events that are happening. Service now handles this with something called an event queue. It’s essentially a queue data structure. So it’s first in, first out of events that happen within the system. So if we take a look at this, on the left we have our triggers, in the middle we have our event queue, and on the right we have our event actions. So here in the event queue, we go to the first event, the login event, where it’s processed. And let’s say that login event actually triggers a script action. So the system would run that script action and then log this to the event queue. Next would be the create record event in this specific queue. So once the crud operation occurs, let’s say an email notification happens, such as a new incident has been created that would also generate a log to the event log. And then finally we have a save record event.

Maybe this was on a workflow activity and this triggers an email notification. So again, the system would process this and then log a record to the event log as well. All right, so let’s revisit script actions. As I stated before, script actions are server side scripts that are invoked via registered events. So any event and service now can call upon a script action. The scope of the script action includes the current object or the current glide record object, as well as an event object which contains param one and param two properties that we can pass in different values for. All right, so why are we covering events in section five glide system? Well, it turns out that there is a glide system event queue method which we can use in scripts, and this will actually add a specific event to the event queue to be processed. The event queue method has four parameters.

First, the event name. Second, the glide record object. And the third and fourth are optional parameters that palm one and palm two that we just discussed. So on the right, let’s say we have our event queue of login event create record, event save record event, and then we have a custom event we would like to add to the event queue. Well, we can do so by calling the GS event queue method and passing in the arguments by calling this script that would add our custom event to the event queue, where the events would then be processed.

All right, now let’s put all this together and take a look at an actual demo. This is going to be a very simplistic example, but I think it’ll help you conceptualize what’s going on here. So for the purposes of this demo, we are simply going to log the text hello, world to the system logs. So first we have to create an event registry record. So here under the registry, we create a new event and we’ll call it ServiceNow 201 hello, world. Again, we’ll leave the table blank for this example and then fill in fired by a description. Next, we want to create a script action.

So this is where we’ll actually perform the log to the system logs. So we’ll create a new script action, we’ll give it a name, and then we’ll select that event name we just created in the event registry. And finally, in the script section, we’ll just do a simple GS log hello world. And as a second argument, we’ll do mark’s logs as the source. Next, we’ll head over to the background script where we’ll actually add the event to the event queue via the GS event queue method. You can see here we’re passing in the name of the event ServiceNow dot 201 dot hello dot world. So once we’ve ran that, we can head to the logs and we see that our hello, world is logged to the system. Events and ServiceNow go beyond the scope of this course, but I wanted to give you a general understanding of events and why we would want to use the GS event queue method within scripts.