ServiceNow CAD – Exploring Other APIs Part 2
- Other APIs and Undocumented APIs
Hello and welcome back. In this video, we’ll take a look at some additional documented APIs within ServiceNow, as well as some undocumented APIs. And we’ll cover how we can find out what these undocumented APIs do. And we’ll also cover how many of the OutoftheBox scripts leverage script includes. All right, so let’s get started. So in addition to the APIs that we’ve already covered in this course, there’s also a number of other APIs that you can find useful. Keep in mind that these APIs aren’t as common as, say, something like a glide record API, but I just want to expose you to these APIs so you’re aware that they exist. Up first is the Glide modal.
You can use this for popups within service now. So if you ever go to delete a record or something of that sort, a lot of the times you’ll get a popup or a modal saying, are you sure you’d like to delete this? Well, it turns out that that’s actually using the Glide modal API. And if you’re creating a custom application or something like a UI action or even in service portal, you can leverage this live modal. Next is the workflow API. And this is used in a lot of scripts that deal with workflows so you can initialize workflows, and this makes it a lot easier to work with the underlying process of a workflow. There’s also a Glide sys attachment API that is used to work with attachments. So if you have to programmatically add attachments or manipulate attachments somehow, you can use this API.
Then we get into some of the web service APIs like Rest message v two, rest response v two, soap message v two, and Soap response v two. Anytime you’re dealing with web services within service now, so integrations to other systems, you’ll more than likely use either the Rest API or the Soap API to process the message or responses to and from the other systems. There’s also a Glide Duration API that makes it very convenient to work with durations within ServiceNow so over a period of time, there’s also many more APIs within service now.
And I highly recommend going to the ServiceNow API website and just spending some time to go through the entire list. That way, when you’re developing applications or customizing the platform, you’re at least aware that there’s other APIs out there that you can leverage instead of spending additional time creating your own. Now, let’s quickly go over some undocumented APIs. So when I say undocumented APIs, I’m referring to the ServiceNow API website where these APIs just simply aren’t listed. Now, that doesn’t mean you can’t find documentation out there by googling or even using the old Wiki website.
All right, so now let’s quickly look at spotting script includes. So in out of the box scripts, you might often find something very similar to this line of code here. So a lot of the times you’ll see a new variable and it’s assigned the value new sumscript, some function. As we’ve seen in the Glide Ajax section, when we see something like this, we have a pretty good idea that some script represents the name of a script include and some function represents the name of a method in that script include.
So if you ever see something similar in an out of the box script and you want to know more about what it actually does, I would recommend first searching the script includes table with the word sum script in this example and then within that script include. Finding the method in this example, some function and just reading through the code and getting an understanding of what it does.
A lot of the out of the box script includes. They’re actually very well commented and they’re pretty easy to follow along. So now let’s jump into service now and take a deeper look at some of these out of the box script includes. So we’ll go to the script include table and we’ll go into this script include. And you can see here that sure enough, some function is defined within this sum script API. So now let’s jump into the business rules table, and we’ll actually do a search.
So we’ll search the script field and we’ll do it contains jsutil. So we’ll find all business rules where there’s a script field that contains jsutil. We’ll go into the first one here, and we can see that this is related to the CMDB. And if we click the advanced tab, we can see that on line five, they’re using jsutil, not nil. So from this line of code, even though we don’t know much about the jsutil API, we can kind of put together what this is doing. It’s referencing a not nil method.
And this method is just finding whether this value is nil or not. So null or not. Now, to test this, we’ll go ahead and copy that. We’ll go to the script includes table. We’ll find the jsutil script include. And within here, we’ll actually search for that not Nil method. All right, so here it is. And what this is actually doing is returning the opposite of Jsutil nil.
So it’s actually referencing itself and calling the Nil method. So the Nil method is right here, and you can see that this is, in fact, leveraging another method. So this should give you an idea of how to research script includes. So if you see these crazy looking scripts and out of the box scripts, this is a good way, or this is a good start to exploring and finding out more about what a specific script or API does. All right, let’s try another one.
So let’s go back to the business rules table, and we’ll try the Discovery CMDB Util API. So here we have one, and here we can see on line ten that we have Discovery CMDB Util, and it’s calling the Create or Update app method. So we’ll go back to the script includes, look for that script include and find the actual method. So, as I said before, this has a lot of comments in it to help us understand what exactly is going on here. All right? And we’ll do one more. We’ll actually just go ahead and find the Cart script include. And in this one, there’s actually a nice description within the description field. And then we can also look within the script and we see that there are a ton of helper methods. And that gives us an idea of what this API helps us with.
- Creating Our Own API
Hello and welcome back. In this video, we’ll actually create our own API using a script include. So in order for you, the developer, to benefit from taking the time to create your own API, you kind of need a few things in order for it to make sense. First, you would need a collection of common functions. So functions you’re calling or referencing in a number of locations. If you’re just calling this method or function once, it probably doesn’t make sense to take the time to create your own API. You’ll also need a script include to create the API. So this will actually store our API for us. And then third, you would need a place to invoke or call our API. So in our example, it’s going to be pretty simple. We’re going to have our API stored within a script include. And we’re actually going to leverage a service now API the glide record within our API.
So let’s jump into ServiceNow and get started. So on the script includes table, we’ll go ahead and click new, and we’ll provide a name for our script include. So in this case, we’ll just give a name of incident utils. Keep in mind that this name must be unique. So once we provided the name, we can see some script that automatically generated. And we’ll start by creating a new method, get latest incidents, which will take an integer for the limit of records we’d like to return. So on line seven, we’ll do VAR limit equals NUM, which is the integer passed in to us, otherwise assign it to five.
So the logic here is if there’s no number passed in, we’ll go ahead and default the limit to five. Now on line eight, we’ll create our glide record object. On nine, we’ll do an order by descending the syscreated on. And then on line ten, we’ll do incidentgr setlimit, where we provide the variable limit. Then we’ll query and we’ll actually create a results array. And within our while loop, we’ll just simply push the number of the incident to the array. And then on line 16, we’ll return the results. So let’s test this by going to background scripts.
And we’ll do VAR incidents equals new incident details, get latest incidents, and we’ll pass in ten. So we’ll go ahead and GS that print our incidents variable. And we can see here that we get ten of the latest incidents back to us. So if we go back and remove ten, so we’re not passing in any arguments, we can see that it defaults to five. All right, great. So let’s extend this a little more. We’ll go back into our script include. All right, so now let’s create a grab records method which will be much more flexible. So we’ll actually be able to provide three arguments the table name, the limit, and the order. So we’ll start by creating a variable that holds our table.
So we’ll do VAR table equals tab otherwise we’ll set a default of the incident table. Then we’ll create a limit variable where we set it to limb, otherwise we default to five and then we create an order by variable where we set it to the order argument, otherwise we set it to a default of the syscreated on field. So now we’ll create our glide record object and we’ll initiate it. So we’ll pass in the table variable. Then we’ll do an order by and pass in our order by variable and a set limit passing in our limit variable. And now let’s actually create a results variable that will hold our results and within our while loop we’ll just do a results push gr dot number dot git display value then after that we’ll just simply return our results. So let’s save this and go ahead and test it in background script.
So we’ll do varrecords equals new incident utils grab records we’ll pass in incident ten and syscreated on and then we’ll go ahead and print these so we can see our ten incidents ordered by the syscreated on field. We’ll go back and provide a value of two so we can see two incidents this time. Now we’ll go back and actually provide the problem table. So here we can see two problem records. Now let’s order by the number field and change the limit to 20. So here we can see 20 problem records ordered by the number field. So these go 010203, etc.
- Section Recap
Hello and welcome to the last video in section eight where we’ll provide a section recap. So first let’s go over where we can use these APIs. So within this section, we actually discussed client side and server side APIs. So it really just comes down to what specific API you’re dealing with. Now, a lot of them were server side APIs such as Glide Element, Glide Date Time, XML Document Two, et cetera. But there were a few like glide modal that are actually client side. The API documentation will tell you whether an API is client side or server side. So just be on the lookout for that. But I would say 75% to 90% of the time you’re going to be dealing with server side APIs. All right, so as a developer, you’ll use the Glide date time API when dealing with dates and times and wanting to manipulate these fields.
You’ll use Glide element when manipulating fields in a Glide record query. And you’ll use the XML document too. When dealing with XML, such as in a web service. When trying to research or get an understanding of what an undocumented API is doing, I would recommend first trying Google and seeing what else is out there. A lot of the times these will bring back results from the community site or even old wiki sites or even third party websites that do a nice job at explaining what this API does. If a specific script include is accessible, I recommend reading through it to get a better understanding of what exactly it does. And don’t forget, you can create your very own APIs within script includes that you can then reference from many other parts within server. Just now.