Originally, ServiceNow's name was GlideSoft. While that was a long time ago, there are still some indicators of the company's history, such as in the naming of ServiceNow's scripting API suite: the Glide API.
Scripting is an important part of ServiceNow, and many different types of records support scripting in one or more fields. Some scripts execute server side, and some execute client side. Whether a script executes on the client or on the server, determines the API that it has access to.
Server scripts, executing on the server as they do, have access to a different set of programming interfaces than client scripts, because client scripts execute within the browser. Thus, only scripts which are included in the webpage and sent from the server to the browser can be executed or called from within client scripts. Since it would be impractical and have a negative impact on performance to send over the entire scripting library from the server to the client for inclusion in each page, only a modified subset of the API is included. Luckily though, one of the things that this subset includes, is an API class for interacting with server-side scripts from the client! This API is called GlideAjax. More on this API later.
Additionally, it's important to be aware that the server is running Mozilla Rhino; an open-source implementation of JavaScript, written entirely in Java. Rhino is embedded into the ServiceNow servers, in order to provide the JavaScript API on the server. As such, this grants special access to certain Java-specific functionality (and Java-specific headaches!) for server-side scripts, that client-side scripts don't have.
Similarly, scripts which execute client side have access to a specific scope of their own. Since they're executing within the user's browser, they'll have access to JavaScript ES6 syntax (unless the user is on a very old browser), whereas ServiceNow's implementation of Mozilla Rhino only supports up to ES5 on server-side scripts (or ES3 if you're running Geneva or earlier).
While a complete description of the entire ServiceNow API is outside the scope of this book (you can find this information at http://developer.servicenow.com/), there are some significant differences in the APIs for client, and server-based scripts. You cannot, for example, use the g_form API from within a server side script. Similarly, you cannot use the gs (GlideSystem) API from a client-side script.
Tip
As you saw earlier, there are some short-hand references to APIs such as GlideForm. The g_form object is a reference to GlideForm, so you can consider the two to be interchangeable. Similarly, g_list is a reference to GlideList2 or GlideListV3 depending on the List version that's loaded in the page. gs is a reference to GlideSystem, and g_user is a reference to GlideUser. These APIs use interface references beginning with g_, because they have no constructor methods that would be invoked by using the new keyword.
While we're going to go into much more depth on the glide API in a later chapter, let's start by learning the APIs and objects that are available on the client and the server respectively. You'll notice that some objects exist on both the client and the server, but behave differently on one versus the other.
Client-side APIs are available within the browser, and load with the ServiceNow page. Let's go over some of the more commonly used client-side APIs that are available (though not an exhaustive list):
g_form(a reference to the GlideForm object) allows you to access, set, and get values from form elements and fields. This object has methods to add field messages, set fields to mandatory, visible, or read-only, and so on.g_user(a reference to the GlideUser object) has methods that allow you to check if the current user (the logged-in user who loaded the page on which the script is running) has a given role, and contains properties that give you access to the user's name and ID.g_list(a reference to the GlideList2 or GlideListV3 object, depending on what list version is loaded) has methods to get, set, or change the list filter, group the list by a specified column, or set the number of records to display per page. Theg_listAPI is available from UI context menus, and client-side list UI actions.g_menu(a reference to the GlideMenu object) is used in UI context menus, in the onShow script. It has methods to control the menu items that do or don't show up in a UI context menu in ServiceNow.- GlideRecord is probably the most-used method in the glide API, because it is the means by which records in the database are generally accessed, read, and modified.
- The client-side version of GlideRecord has vital performance implications. You can read more on these implications, and how to avoid negatively impacting client performance in the Where scripting is supported section of this chapter.
- GlideAjax is one of the most important client-side APIs, as it allows you to execute server-side code (specifically, client-callable script includes), and receive a response back to the client. It does this asynchronously, meaning that unlike synchronous queries and scripts that execute or retrieve data from the server, it does not lock up or slow down the user's browser while it executes.
- GlideAjax is the most performance-efficient way to execute server-side queries and code from within client-side scripts. More on this in the next couple of chapters.
Just like on the client, scripts that execute on the server have a particular set of APIs that they have access to. The server-side API suite is broader than the client-side API, because making an API available on the client requires sending code from the server to the client, which can slow page load times. The server has an extremely low-latency connection to the database, which makes more robust scripting possible and much more efficient.
Tip
There are two sets of APIs: scoped, and legacy. Scoped APIs are mostly a subset of the legacy API. They are the only APIs available within scoped applications, and do have some limitations. These limitations, however, are becoming fewer and fewer with every new version of ServiceNow. Most of what you'll likely do within ServiceNow will be in the Global scope, so you won't need to worry too much about this difference.
Let's briefly look at some of the APIs and objects available on the server:
- GlideAggregate: This is an extension of the GlideRecord class, used for creating database aggregation queries such as
SUM,COUNT,MIN, andMAX. For example, you can run a query with a given filter (say, all items associated with a given ticket), and get aSUMof the cost of these items in order to determine the total cost of the parent ticket. - GlideDateTime: This is a class meant to help with the usage of
glide_date_timefields, as well as comparing one date and time to another date and time, or formatting a date/time from a string into a date/time object that can be used for time zone conversion and date/time calculations. - GlideDate: This is very similar to the
GlideDateTimeclass, but is just for dates without times associated to them. - GlideRecord: This is probably the most ubiquitous class in ServiceNow, and it is both a server-side and client-side API. It is vastly different in behavior and capability on the client, but on the server it is a powerful and efficient means of querying the database for a given record or set of records. As you can imagine, getting and setting data in the database is something you might need to do quite often in a platform like ServiceNow.
- GlideElement: This is a class referencing a specific field on a client-side GlideRecord object. To put it another way, you do not construct GlideElement objects in your code. Instead, each GlideRecord object contains one property (a GlideElement object) for each field on that record. This API provides methods for interacting with these fields and their values.
- gs: This is a reference to GlideSystem (which has no constructor method). It provides methods with all sorts of useful system functionality, including getting system properties, logging information to the system logs, and checking user permissions.
Tip
Objects that are meant to be instantiated have a constructor method. This method must be called using the
newkeyword. When I writevar gr = new GlideRecord('table_name');, thenewkeyword calls the constructor method of theGlideRecordclass. This constructor is often a function in the class called initialize, or it is a function itself which becomes the constructed object, which takes the argumenttable_namethat we specified in our call. The constructor then modifies properties of the object and returns the resulting constructed object to our variable (gr, in this case). - GlideSession: This is a server-side object that corresponds to the currently signed-in user's session. It provides methods to get the roles associated with a user, as well as set and retrieve data associated with their particular session. You can get an instance of the GlideSession object for the current user's session by using the
getSession()method of the GlideSystem API like so:var userSession = gs.getSession();.
Server-side scripts that operate on a specific record (such as business rules or advanced conditions fields), also often have access to a pre-defined variable called current. This is an instance of the GlideRecord object which contains the record upon which the script is executing (or perhaps we should say: the record that triggered the script to run).
For example, imagine you have a business rule that executes on the Incident [incident] table, and it is triggered whenever the State field's value changes. If you then go to the Incident table, open up a record, and change the State field value, then the business rule will execute. When it does, in the context of the script that that business rule runs, the current object will correspond to the record that you just modified.