All ServiceNow CAD certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the CAD ServiceNow Certified Application Developer practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

GlideRecord

1. GlideRecord Introduction

Hello and welcome to Section Four. Now that we've reviewed where we can apply scripts and introduced the concept of an API, it's time for us to look at our first ServiceNow API, the Glide Record. We'll start this section with an introduction to Glide Record, followed by a quick analogy to help solidify our understanding. We'll then jump into the "Show Me the Code" section, where we'll go over a brief snippet of code to show you what exactly the API looks like in a scripting environment. After that, we'll cover a very important topic in ServiceNow called dot walking.

Next, we'll cover the Glide Record API diagram, where we'll take a look at some of the properties and methods associated with Glide Record. We'll then look at a list of common GlideRecord methods and discuss the functionality behind them. After that, we will discuss the stages of a glide record, and then we'll walk through the acronym Crud and how it applies to the glide record. Once we've covered these topics, we can finally jump into Service Now and actually start writing some code and background scripts.

After the demo, we'll discuss Glide recordsecure and the Glide aggregate API. And finally, we'll end the section by discussing when we can use these APIs, a little bit about best practices, and then going over the API documentation. Finally, at the end of this section, you'll find exercises as well as quizzes for you to try.

All right, so before I introduce the Glide Record, let's first talk about a fundamental concept about web applications, or really just any application that persists data. This means that it stores data indefinitely. So let's say we have our application server here on the left and our database server on the right. Let's say we would like to access data that is stored in the database.

For example, we'd like to access data about a specific incident. Well, because Service now uses MySQL as its database, and since MySQL is a relational database management system, we'll have to write some SQL in order to retrieve the data. But it turns out that SQL can be a bit tricky and just really not very fun to work with. So we, as the developer, want an easier way to access and interact with this data.

It turns out we can do so by introducing an API specifically designed to do just this. Here we have what we'll call our database API now, which kind of acts like a middleman. As the developer, instead of writing SQL, we can access data in the database by interacting with the API via JavaScript. Because we've introduced JavaScript, now we have the power of a full object-oriented programming language at our fingertips. This gives us a level of abstraction that helps with security, ease of use, and powerful helper functions. Well, it turns out this database API is called Glide Record, which is what we'll be discussing in this section. Glide Record is the most common API you will use as a ServiceNow developer.

This API is accessible to the developer on the server side and is used for any type of database operation, commonly summed up with the acronym Crud. Crud is an industry term used to refer to the four functions of persistent storage, which are create, read, update, and delete. Anytime you need to read an existing user record, create a new incident, update an existing problem record, or delete a change, you will use the GlideRecord API to perform the database task.

As mentioned before, this API generates the SQL for us, so we as the developers don't have to worry about writing SQL from scratch. We can think of the glide record as having two stages. In the first stage, we build out the actual query, so we'll select a table we want to query on and start to build out the filter that we apply to the SQL. For example, we could say we want to show all priority 1 incidents that were created within the last two weeks.

Again, we can create this filter, and this happens within the first stage. Once the first stage is complete, the actual SQL statement is sent to the database, where the records are received back from the database, and you can think of the second stage starting at that point in time.

Now, in the second stage of our guide to records, we can think of this as a collection of records or a list of records from the query table. This is where we do the actual processing of the records. So, for example, if we wanted to update specific fields or even delete certain records, we could do so here. In this stage of the glide record, you can think of it as an ordered list of records.

For example, when we view a list of incidents on the incidents table, Glide Record is being used behind the scenes to query the database and retrieve the data related to a specific filter of incidents. Alright, so before we go any further, I'd like to first introduce you to the Show Me the Code slide. Now, I understand this slide may be a bit overwhelming to some of you, but don't worry; we'll cover all of these topics later on in this section.

The goal of this slide as well as the "Show Me the Code" slides in future sections is to give you a practical example as soon as possible, providing you the student with a holistic approach.

Now, I could talk for hours on the theory and concepts of glide recording, but that wouldn't do you, the student, much good in learning this topic for the first time. This is why, when I've taken programming courses in the past, I've always enjoyed instructors who take a moment early on when introducing a new concept to show some actual code.

So if you do not understand a certain concept in this slide or in future slides, show me the code slides. Feel free to skip this slide and power through the rest of the section. All right, so in this example, we'll start simple. We'd like to display a list of all priority-one incidents. Now, let's walk through this line by line. On line 1, we are instantiating an object by calling the new keyword along with the function Object() { [native code] } Glide Record.

We pass in one argument, which is the system name of the table we'd like to query. This is simply a string type. We then assign this to a variable named Incident Glide Record. Note that it is best practise to give meaningful names to variables, such as "incidence gr," instead of simply "gr." Throughout this course, when I am teaching the concept of a glide record, I will typically use the name of the table or record that I will be querying from, along with a capital G afterward, to signify that this is a glide record object. However, you are free to create your own convention as long as it is related to and has some type of contextual meaning to what you are doing.

So, now that we've assigned the Glide Recordobject to the Incident Gr variable, we can begin calling methods on it. On line two, we can call the Add query method, which accepts two arguments. First, a string containing the name of the record field we want to filter on. The second argument is the system value. This add query method is very similar to what you would see in the Service GUI interface or back end. Now, when you apply a certain filter to a table, even on the Internet table, if you click the filter icon, you can apply these conditions to the filter.

Well, it turns out that this GUI interface is actually using the Glide Record API in the background and using something very similar to what we've defined here on line two. On line three, we perform the actual database query operation, which generates the actual SQL for us, sends it to the database for it to get processed, and then returns the records to us in a JavaScript object. It's the query method that ends stage one of the glide record and starts stage two of the glide record, where we can then think of everything after this line as a list of records, in this case incidents. On line four, we can use a JavaScript while statement to loop through all of their returned records.

We use the Glide Record Next method to determine if there is another record in the array. If so, we continue to line five. So finally, on line five, we use another ServiceNowAPI glide system, which is referenced with GS, in order to print the incident number to the screen. Note that we are able to access the number field by simply adding a period followed by the name of that field. All right. Now let's take a step back, and I'll provide a very simple analogy for Glide Record. This analogy will be buying groceries at a grocery store, and the process is as follows:

First, we'll select which grocery store we'd like to go to. This can be analogous to selecting a database table to query. Second, we'll grab a shopping cart in the store. The cart can be thought of as the Glide Record Object. Third, we'll place groceries in the shopping cart. The groceries can be thought of as records on the table.

Every grocery item has unique characteristics such as its name, price, and color. These item attributes can be thought of as field values for a record, like the caller on an incident record. Finally, it's time to check out at the cashier. This last step can be thought of as performing some kind of action on the records, whether they are for display, updating, deleting, or even creating new ones.

All right, so let's kind of apply this analogy to a real-world example. So, using our first example from the "Show Me the Code" section, we'd like to print to the screen all incidents with a priority of one. While these steps may vary depending on the glide record methods that you are using, there are typically four steps involved in this process. just like we saw in the analogy.

The first step is selecting a table to query. In this example, it's the incident table. In the second step, we build our filter if required. Again, in this example, it's priority one incidents. The third step is where we tell ServiceNow to make the actual query against the database table along with our arguments.

This is when the Glad record actually generates the SQL, runs it against the MySQL database, and processes the return rows into a Glad Record object. Again, this kind of marks the end of stage one and the start of stage two. Finally, the fourth step is where we would process these records, whether we were just querying them, deleting them, or updating them.

We're simply printing the numbers to the screen in this example. We'll talk more about the stages in the third video in this section. However, for now, you can think of steps one, two, and three as being in the first stage, the build query glad record stage, and the fourth step in this diagram as being in the second stage, the process records stage. It's important to note that any ServiceNow table, any of the 2400 out-of-the-box tables, or any new tables that you create can be queried using this Glide Record API.

2. Concept: Dot-Walking & API Overview

Hello and welcome back! In this video, we'll go over the concept of "dot walking." We'll introduce the Glide Record API diagram, and we'll also go over a scripting example where we map out the API. All right, so dot walking is a very important and powerful concept in ServiceNow and is used all throughout scripting. So it's crucial that we cover this topic. Now, as I've stated before, Service

Now is based on a relational database system. So we have the concept of primary and foreign keys. If you don't know what these are, don't worry about it. The topic is out of the scope of this course. But just know that these keys are used to form relationships between tables. If you'd like to know more on primary keys, check out the Dive Deeper notification below and click on that Wiki article.

Alright, so for example, let's say we have four tables. Table A has a total of four fields, three of which are string fields, and the fourth is a special kind of reference field. Table B has a total of five fields, three of which are string fields and two of which are reference fields. Table C has only three string fields. And finally, table D has two string fields. Let's start by looking only at tables A and B. We can say that as long as field one and table B are always unique, this could be used as our unique key. Put another way, if we can guarantee that field one is always unique, we can use that as a reference in table A, which is going to reference that specific record in table B. Now let's take a look at tables B and C.

We can also have a reference to Table C, which is stored in Table B. In addition, we can also have a reference to table D, which is stored in table B. It turns out that we can have as many references to other tables as we want, if that makes sense. This is very common in the world of CMDB and asset tables. So why are these reference fields so important anyway? Let's say we query table A in a Glide Record script, but we want to access a field from table B. Well, we can do this since table A has a reference field to table B. All we need to do in the script is use a period or dot to walk to the next table. We can even dot-walk from table A to table C or D since table B has a reference field for table C as well as table D.

To solidify our understanding, let's look at a real-world example. In this example, we will be querying the Incident table. However, we would like to find the caller's location. It just so happens that this will include three separate tables inside of ServiceNow. The first table is the Incident table, which we will be using for our initial Glide Record query. The second table is the User table, which has a system name of Sys underscore User. And finally, the third table is the Location table, which has a system name of Cmn underscore Location. So on the incident record, there is a reference caller field. As you can see, businessman Bob has already been populated. Below are some additional details about this field.

We can see that to access this field, we can use Incident Caller Underscore ID, where Caller Underscore ID represents the field name, which is shown here as the field. This field is stored on the incident table, which is a type of reference that references the sysable. Now if we click the information icon next to the related record, we'll be taken to the UserRecord, which is stored on the Sysr table. We can see that on the user record there is a field called location, which in turn references the location table named CMMN underscore location.

Finally, if we click the information icon on the Locationfield of the user record, we will be taken to the actual location record on the Cmn_location table. Here we can see that the name field on the Location table represents the physical name of the location, in this instance, Columbus, Ohio. Also, it's important to note that this is just a string field and not a reference field. So now let's look at what this code would actually look like. On lines one and two, we're using the glide record git method. We'll go more into the git method in the following slides, but just for now, know that this is grabbing a specific incident record via its Sys ID. The important thing to note here is that we are on the Incident table, yet we can still print the name of the location the current caller is at by simply writing Incidentgr Caller ID location name. This prints Columbus, Ohio, to the screen to recap.

Dot walking is a powerful technique that can be found throughout ServiceNow. It is possible due to the nature of relational databases; we are able to leverage reference fields to grab values from other tables without actually querying each table. We'll use dot walking throughout the rest of this course. All right, now let's go over the Glide Record API diagram. If you know what UML class diagrams are, then this should look familiar to you. But if not, don't worry; we'll cover everything you need to know. So this is an API diagram that I'll be using throughout the rest of this course. for any API we discuss. You can see that at the top we have the name of the API, in this case Glide Record.

And the green ovals on the left represent properties or general topics associated with this API, while the rounded rectangles on the right represent the methods or functions associated with this API. It's important to note that oftentimes the properties associated with an API are actually private and are only accessible through getter methods. So much of the time. If we are setting or even getting properties, we would be accessing those via methods instead of directly. So within the Glad Record API process, so to speak, we define a table and a query. And then, once we send this query to the database, we'll receive records as well as the record fields. And on the right are some common SQL record methods such as add query, set limit, add encoded query, et cetera.

We'll cover these methods in the following videos, and we'll actually dissect them and get a better understanding of what they're actually doing. But for now, I just wanted to introduce you to this API diagram. So in the next slide, let's go ahead and run through a code example and map out the methods and properties to our API diagram. We'll start with the Glide Record constructor, which accepts one argument, the name of the database we're looking to query on, as a string type; this is stored within the table variable. Next, we will call the Add query method, passing in two arguments: priority, which is the incident field we'd like to query for, and One, which represents the priority one field value.

Glide Record takes these values and gives us a nice query string that ServiceNow can then use to generate SQL for us. Again, the query string property displays the actual query string generated by this Add query method. On line three, we call the query method, which takes all of the data we've added to the Glide RecordObject, Incident Gr, and performs the actual database query operation, where it then packages up the return results and reassigns them to the Incident Gr variable. Then we use the next method, which will iterate through our glide record object or list of records returned by the database. Then, once within the while loop, we can finally start to process this data; in this case, print the number of the incident. So again, the purpose of this slide was to show you some code and map the properties and methods to the class diagram. We'll see these class diagrams come up in the following sections throughout the rest of this course.

3. Common GlideRecord Methods & Stages

Hello and welcome back! Let's go over some common good recordkeeping methods now. This is not an exhaustive list, but a list I came up with that I believe represents some of the most popular and important methods. In the next video, we'll actually demo these methods in background scripts within ServiceNow, but for now, hang tight.

So first we have the query method, which we should be fairly comfortable with for now. In the previous videos, we've seen it used a couple of times. This method is what actually calls the database and sends the SQL that was generated from the other methods that we used. Next is the new record method. This is used when inserting a new record into a table with Glide Record. This method creates a new record, sets any default values for that record, and then generates and sets the system ID.

We then have the Insert method, which is used to insert the record after setting field values. We have an update method that is similar to insert, but instead of inserting the new record, it would update an existing record with the field values that we updated. Next is a Delete record, which, as I'm sure you can guess, deletes a record.

We also have the Add query method, which adds filters to the SQL query. We've seen this in the past couple videos. Next is an add encoded query, which is very powerful and accepts an encoded string, which we'll see in the next video. It essentially takes this encoded query, processes it, and generates the SQL for us. It's very similar to the Add query method, but as you'll see in the next video, it can be a little more powerful and require less code. Then we have the HasNext method, which returns a boolean value.

If there is another record in the glide record to loop through, then we have the Next method, which performs the actual iteration. Next is the Get method, which is a shortcut for grabbing a specific record. Then we have "Order by," which accepts a field as its argument and will order the list of records in ascending order based on this field. We also have the order using the descending method.

Finally, we have a method for creating, reading, and deleting that uses ACLs in the system to determine whether the current user has the ability to create, write, read, or delete. These are commonly used within scripts, which we'll see in the following sections. All right, now let's discuss the two stages of a glide record.

We can think of the first stage as the building query stage. This is where we build the query using JavaScript, which will then generate SQL for us and run that against the database. So the filter conditions are defined in the building query stage. So here on the left we have our Glide Record API diagram, and on the right we have our database, in this case a MySQL database, where our data is stored in ServiceNow.

So the awesome thing about Glide Record is that it allows us to query the database while only using JavaScript. We don't actually have to write the SQL statements. So it basically uses our JavaScript. In this case, our table is Incident, and our query is Priority Equals One.

So All Priority One Incidents and the GlideRecord API work their magic, taking this JavaScript and spitting out the actual SQL that will run against the MySQL database. So, for example, in this case, select Star from the Glide Record table or incident, where the Glide Record query or our priority equals one query. So again, all of this is happening within the initial build query stage, or the first stage. So how do we build these queries?

Well, we have two options. The first is to use the chain methods, which allow us to chain together a number of methods such as Addquery, Add or Conditionally Add Null Query, Add Not Null Query, Add Active Query, or Add Inactive Query. Or, as a second option, we can use encoded queries, which use the method Add Encoded Query. So let's take a look at the first option, the Chain Methods option. So with this option, we will add these methods or chain these methods to the current Glide Record object as shown in the script. Here we can see on line one that we create our GlideRecord, and then we start to chain methods onto it.

So this query reads: Discover All Priority One incident or priority two incident with a hardware or software category that was created after January 1, 2017, and contains a short description is not null. So again, this is the first option for stage one. So next, let's take a deeper look at the Ad query method, since this is one of the most important methods in Option 1.

So Add Query accepts either two or three arguments, and there's a pretty big difference between the two. The ad query method accepts two or three arguments. If we only pass two arguments to the Add query method, we would be passing the field name as our first argument and then the field value as our second argument. In this example, the field name is ShortDescription, and the field value is Test.

If we decide to pass three arguments in, we again pass the field name as the first argument. However, for the second argument, we pass an operator, which in this case is contains, and then, as the third argument, we have the field value.

So with two arguments, we have the field name and the field value. With three arguments, we have the field name, the field value, and the operator that sits between them. Below are two lists of operators that we can pass in. The first list is used for number fields. So we can do things like determine if this number is greater or equal to another number, and we can use the second list with strings.

So, does a string contain this value, does a string start with this value, et cetera? In this example, we're saying, "Does the short description contain the word test?" Note that if we only pass in two arguments to the Add query method, an equality operator is assumed. Now, let's explore the second option, an encoded query within Stage One.

So for complex queries, I generally prefer this option, as it is much easier for the developer. So first we would head to the table in service now and actually build out the query using the graphic user interface. So, in this example, we have a priority of critical or high, a category of hardware or software, and it was created after 2017 101. and the short description is not empty.

So we have the same filter that we saw in the previous example. Now, in step two, we would copy this query. So you simply go to the breadcrumbs and to the very last filter. In this case, the short description is not empty.

Right-click on that breadcrumb, then click Copy Query. This will copy the encoded query that ServiceNow uses to process this filter. Then, once that's copied to our clipboard, in the third step, we add this to the Add Encoded Query method, which in this case is a long string that contains the encoded query that the service now uses to process this. So you can see in this example that there's a lot less code required.

However, it does require us to go back to ServiceNow, create this query, copy it, and then paste it in our code. All right, so that was an overview of Stage One of the Glad Record. Let's move on to Stage 2, the recording stage. So Stage Two starts after we execute the query method. So the query is executed in MySQL, and the MySQL database returns us the records from our filter. These records get sent to the glide server.

Glide Record does its magic and maps out these database fields to JavaScript properties. So then our records get returned to us in our Guide Record variable, where we then have access to the record fields that are the actual properties of that current record. One of the most important methods in Stage Two is the next method, which iterates over our return list of records.

When I was first learning about Glad Record, this was one method that caused a bit of confusion for me. So I hope this slide will help you avoid this confusion. The next method has a few magical functions baked into it. When we call the query method on a GlideRecord object, we get an iterable object back in our original Glide Record object. So what does this mean?

Well, it means that if the query we build in the first stage of the Gladrecord actually returns one or more records, then a list of those records is within the IncidentGR object, which we can iterate over. For more information on iterators, check out the below wikileak or even this YouTube video that helps explain what an iterator is. In order to access the first record, we first need to iterate on it.

So by calling next on the Incident Gr variable, continue to the first item in the array or list. So in our example, let's say we have a total of four incidents that have a priority of one in our incident table. These four incidents are represented below the block of code and are contained within the incident. If there are no more objects in the array, the JavaScript while loop will continue until it receives a false value, which is returned by the next method. So in this example, the code within the while loop will run four times.

On the first run, we get our first incident, which happens to be an inc. Zero, zero, zero, zero, one, two, three one of them The most powerful part of the Glide Record API is that we have access to all fields on the table. We are querying, in this case, the Incident Table. So, if we wanted to display the Sys ID rather than the number, we could simply change the IncidentNumber text on line five to Incident Gris ID. While we're still within the while loop, we have access to the current object. In this case, Incident inc.

One, two, three. So line five will be executed and print the number to the screen, and then we will continue with the while loop, where we are then taken to the second object in the array, and so on until we get to incident four, the last item in the array-like object. Hopefully we are starting to see the power of the Glide Record API as opposed to writing all of these operations with SQL.

So, as we saw in the last slide, we were able to access any Incident field of the iterated object by simply adding a dot and then the name of the field. Once the query method is called and the object is iterated to a record's fields, they become properties on the current Glide Record object.

Keep in mind we use the field's name in the script as opposed to the field's label. So if we wanted to access an IncidentsContact type, we'd write "Contact underscore type" instead of "Capital C Contact Space type," which is the label as opposed to the name. Now we'll take a quick look at the Get method. So you might be asking yourself, "If I need to get a specific record and a script, do I really need to write five plus lines of code just to get them?" The answer is no; thanks to the Getmethod, you'll often have the SysID of a specific record in a reference field or obtained from another Glide Record query when writing scripts.

As long as a given field on a table is truly unique, we can use the Get method to retrieve that record in two lines of code. However, it is important to note that this is very different from using the query method with glide records, which returns an iterable object. GIT only returns one record even if the filter provided matches more than one record. So only use the GIT method with truly unique values like SysID or system-generated values like the OutoftheBox number field. Let's take a look at them.

An example here is that we have three lines of code as well as the class diagram on the left. As you can see, we're still providing the name of the table online to the glide record constructor. So nothing has changed here. But on line two, instead of adding an add-on method or just calling the query method, we simply use the Get method, which either takes the SysID as an argument or, if we have another unique field, we can pass in the field name and the field value as an argument. Pretty cool. So in this case, because I know the number field is truly unique, I can pass in the number field as the first argument and then the specific incident number to the record I'd like to receive. The number in this case is 0 0 1.

4. Revisiting CRUD

Hello and welcome back! In this video, I'd like to revisit Crud and map out the Glide record methods to the Crud acronym. So, as discussed before, Crud stands for create, read, update, and delete. And these map quite nicely to glide record methods. So create maps go to the Insert method, and read maps go to the query method, which has an asterisk next to it because technically the query method can be used on all Crud operations, not just read. But it turns out that if we wanted to read a record, we would also need to run the query method as well.

So, moving along to Update, we have the Update method. Simple enough, update to update, and then delete with the delete record method. So let's take a deeper look at these four methods. Here on the right, I have some code to create a new incident with the short description of "test one, two, three." There are a few things that need to happen before we can actually create or insert a new record. So, first, we must create a glide record, which entails passing in the table from which we want to create the record. On.

Two, we need to actually perform that query method that will actually initialise the Glide Record object, so to speak. Then we call the new record Method. This will actually set all of the default values associated with a new record, in this case, a new incident, as well as automatically generate the sysID for the record as well. And the fourth step is where we actually set the values that we would like on this new record. So again, in this example, I'm simply setting the short description. However, you could set all of the fields or just a selection of the fields that you would like to have for this new record. And then, finally, in the fifth step, we actually make the insertion. As a result, we call the Insert method. It's important to note that the record isn't actually saved to the database yet until we call this method.

So, even though we call the new record method, that object is still in memory and has not been saved to the database yet. Okay, let's get started reading. So on the right, I have some code that queries the incident table and shows all priority 1 incidents within the while loop. The incident number is simply printed to the screen. So again, for this to happen, we need to follow a few steps. First, we'll build a client record. Two is optional, where we apply any filter conditions to the Clyde record. In this example, priority is one. Third, we need to run the actual query method. Four, we must iterate over the objects or rows using the following method.

And finally, the fifth step is where we actually print or copy the variables, or whatever it is that we need to do in order to achieve our read operation. Next is an update. Here we have some code that updates all of the priority one incidents and sets their priority to two. So in the first step, again, we'll build a glide record. In the second step, we add any additional filter conditions, which are optional. And the third step will query the database. And the fourth step will iterate through our records. The fifth step is where we actually set the field values. So on line seven, I'm setting instantGr dot priority equal to two. And then finally, the 6th step is what we call the "update method," which will actually update the record in the database.

Similar to the insert method, with the update method, the field values are not saved to the database until the update method is called. So, if incident G on line eight never happened, the priorities would not be saved to two; they would remain at one. Finally, we have delete. On the right, I have some code that is going to find the incident and delete that record. So in the first step, we're building the glide record, and in the second step, we're adding the filter, which is optional. We're querying the fourth step in the third step, and iterating to that record with next. And then the fifth step is what we'll call the actual delete record method.

5. GlideRecord - Demo 1

Hello and welcome back! In this video, we'll finally get our hands dirty with some actual code that we'll run in background scripts within ServiceNow. Keep in mind that I'll be scripting all of these videos using the Adam text editor on GitHub. I will then copy the code from Adam and paste it into ServiceNow. I prefer this method just because I think using a text editor like Adam will be easier to read for you, the student, and overall just be easier to present to you guys. All right, so let's get started. First, we'll go ahead and type in background scripts in the Application Navigator. And since we'll be using this so much, we're going to go ahead and star this.

So this will be added to our favorites. So we'll click this, and this will bring up the background scripts within ServiceNow. As you can see, this is nothing fancy. This is simply one large input field where we can click the "Run script" button below, which will execute the script we write against the backend or in the backend of the service. Now, so this would be all server-side stuff.

And then we can also select the scope as well. We won't really be discussing scope in this course, but you do have that option here. So again, this is also why I chose to use a text editor as well, because specifically in background scripts, there's no formatting or line numbers or anything else that would help you guys out. All right, so first, although we're still in the Glide Records section, we need to COVID something called "GS Print," and GS stands for Glide System, which we'll be discussing in the next section. But for now, just know that GS Print is a simple method that prints whatever is in the argument to the screen.

So we'll go ahead and test this out by first doing a GS Print, Hello World. Because this is a very simple example, I decided to just type it upright within the background script itself. So here you can see we have "Hello World" as a string value, and we'll go ahead and click RunScript, and that does exactly what we expect. It prints. Hello, world, to the screen. All right, so we'll delete that. And now let's talk about the glide record. So we'll jump into Adam, and if you are following along, make sure you have JavaScript selected as the language in the bottom right-hand corner. This will help with syntax and error checking. Although Adam is not an IDE, so it won't check strict syntax rules for JavaScript, it will help in some ways. So I definitely recommend having JavaScript selected here as the language. All right, so to start, we'll create a new variable, "incidents," and we'll be querying the incidents table. We've seen all of this before, and we're actually not going to apply any filters here. We will just be querying the entire table here.

And, while Incident Number dot Next is active, we'll just print the incident number. Now, it's also important to point out that this is in my personal developer instance, so I don't have many incidents in the Incident Table. But for example, if you were in a production environment or even a test environment that maybe has hundreds of thousands or even millions of incidents, just keep in mind that this could have a performance impact. So we'll go ahead and copy all of this code, then paste it in the background script and click Run script. Now, you can see that this printed all of the incident numbers and the incident table on the screen here. All right? So let's go back and play around here. So, let us try removing line three and see what happens.

As you can see, we removed both the while loop and the incident gr next method. So we'll click "Run," and you can see we're not getting anything here. So this kind of shows just how important the next method is. Now, it's important to note that we don't need the while loop. The while loop is simply to iterate over the incidents in the arraylike object. However, without a loop mechanism, Incidentgr Next will simply go to the first incident in the array and print that it is only when we add the while loop that it will go through the entire array. All right, so now let's go over adding a query. We'll include Priority and assign it a value of one. So now this will query the IncidentTable and find all Priority One incidents. And then we'll put Priority One Incident, then the Incident Number, a semicolon, and finally the actual Priority. So we'll copy this, paste it in the background script, and click Run. Of course, our query is correct, and we see all of the ones representing Priority One. So here it's important to point out that when we do Incident Group Priority, we are simply getting the value stored within that field.

Now, it's important to note that since priority is a choice field in ServiceNow, there is a system name and a display name. So if we wanted to print the display name, we could use the powerful Get Display Value method, which will automatically grab the display value for any field that we add this method to. So here you can see that instead of just getting the number one, we get the actual display value, which is a critical one, right? So now let's go to the incident table within ServiceNow. We'll go ahead and create a favorite since we'll be returning to this quite a bit in these examples. and we'll navigate into an incident. Now we'll click the hamburger icon and copy the Sys ID of this record. We'll then navigate back to the background scripts, and we'll show off the Git method. All right, so we'll start a brand new glide record. And now we'll use the git method, where we'll pass in one argument, which is the Sys ID of the incident we were just viewing. And then on line three, we will simply print the incident number.

We'll go ahead and copy this and paste it in the background script, and you can see that we have the incident number here. Again, the Git method can accept either the SysID as one argument or it can accept two arguments, the first being the name of the field and the second being that field value. And again, keep in mind that these must be unique. Now we'll go back to the code, and we'll print the number this time as well as the Sys ID. Yup, so we can see that this Sys ID is the exact same as the one we've pasted online to.All right, so now we'll show a very powerful method, the Add Encoded Query. And to start with this one, we'll actually navigate to the incident table, and we're going to build a query in the GUI interface.

So we'll actually click the filter icon on the incident table. And here we'll provide a category of inquiry. Mark Miller is an activist who is honest and open. So these would translate to adding three separate query methods to our record. However, because we're doing the Add Encoded Query, we can actually do all of this in one method. So we'll go ahead and click "Run," which will bring up a list of all active incidents. True, categoryis In Query Help and Open By, the author is Mark Miller. But if we go back to the very top, we can see that we have the query or the breadcrumbs here at the top.

Well, we can actually right-click the very last one and click Copy Query. And this is actually going to copy the method the EncodedQuery service now uses to generate the actual SQL that is then sent to the MySQL database. So if we go into our text editor, we'll create a new glide record. And the first method will be AddEncoded Query this time. And Add Encoded Query accepts one argument, which is a string of that encoded query. So what we'll go ahead and do is assign that encoded query to a query string variable, and then simply pass that variable in as the parameter. So if you look closely enough at this encoded query, you can actually see what it's doing.

We can see Category equals Inquiry, which is the name of the actual choice value active, which is True, and Opened by me, which is the Sys ID of my user record. So now we'll go ahead and apply the query method and loop through all of the incidents, where it will then print the incident number to the screen. So we'll copy this, paste it in our background script, and click Run Script. And here we get a list of all the incidents that match that encoded query. As you can see, the Add encoded query method is extremely powerful. With simply one line of code, we can add extremely complex queries that might have many conditions applied to them.

All right, so now let's create a new incident using Glide Record. Alright, so now we'll go ahead and create a new glide record. We'll give it a table of incidents since we want to create a new incident record, and we'll do a new incident and a new record. Now, if you remember from the previous videos, NewRecord will actually initialise the record for us, set any default values, and generate the Sys ID. So we'll go ahead and provide a short description. And you can see that we're simply taking the glide record object, which is New Incident, and we're just doing a dot.

Then the name of the field, in this case, the Short Description field, followed by an equal sign and a string value for the short description. Finally, we'll use the Insert method, which will actually insert this record into the database. So without this insert, the short description would never get saved. All right, so we ran the script, and now we'll go to the incident table. And just to verify, we'll pull up the incident. And you can see here that this is the incident with the short description we just added in the code. All right, now let's try something just a little different. One of the cool things about the Insert method is that it actually returns the SysID if we assign it to a variable. So in this example, on line four, we will create a new variable called New Incident Sys ID.

And we're actually going to assign the return value from the new incident insert to the new incident. SIS ID variable. To put this to the test, we'll print the New Incident Sys ID to the screen. So we'll copy the code, paste it in the background script, and run it. And you can see that we have our Sys ID here. So we'll copy this, go to the Incident table, bring up the most recent incident, paste this in the short description field, and then actually copy the Sys ID of the current incident and paste this in as well. They should also have the same Sys ID. And they are. Alright, cool.

So now let's do something a little different. Let's say we'd like to create five new incidents. So for this, we're going to do a few things here. To start with, we're going to create a new variable. Line one will be an array called "New Incidents," and line two will be a counter called "Counters." We'll go ahead and assign this to one, and then on line three, we'll create our glide record. So we'll provide a table of incidents. And then on line four, we'll do a while loop. So we'll say that while the counter is less than or equal to five, so they should run five times, we are going to create a new incident.

So on line five, we'll do IncidentgrNew Record, which will initialise the record. And then on line six, we'll set the short description of the new record to Incident Number plus the counter value. On line seven, we'll increment the counter. And finally, on line eight, we will push the Sys ID of the newly created record to the New Incidents Array. And then on line 10, we will simply print the array to the screen. So we'll go ahead and copy this and paste it in the background script, and then click Run Script. And you can see here that we have a comma-separated array of the Sys IDs. So we have our five SysIDs here for the five incidents that were just created. So if we go to the Incidents Table, we can see that we have five incidents here with the counter appended at the end, right? So now let's go over deleting a record.

Now, if you're ever deleting records in a background script, I highly recommend first printing those records to the screen to verify that your filter is correct and that you'll be deleting the records that you want to delete. So first we'll create a new glide record, and let's say we want to delete all of the incidents that have a short description of Incident number three. So again, to start, we'll simply log this to the screen, and then we'll come back and actually perform the delete record. So for now, on line five, we'll do GS Print and we'll do the Incident Number. And we'll also add the short description here as well, just to verify.

So we'll take a copy of this, paste it into a background script, and run it. So here we can see that 20170 is that specific incident. So now we'll jump back into our code, and since we verified that our query is correct, we'll go ahead and delete the record now. So, incident delete record code, and that's all there is to it. So we'll copy this code, paste it in the background script, and run it. And now we'll go to the Incidents Table and verify that there are no incidents in the Incidents Table with a short description of Incident Number 3.

ServiceNow CAD practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass CAD ServiceNow Certified Application Developer certification exam dumps & practice test questions and answers are to help students.