Debugging Client Script in ServiceNow - All you need to know

 Hello all Readers,

 

I have seen many developers struggling and killing lots of their productive time in finding error/bugs in the code. Often they have no clue why the hell their code is not working the way it should. Now there could be 'N' number of reasons why your code migh not work, but how to know  ? 

 

The most approached way I have seen that developers follow is using alert() method or console.log() method. This approach is no doubt helpful but, what if you are not sure at which line of code you are having data processing issue? You may end up with multiple alert messages and unknowingly you may end up irritating other people who are working on the form, as those alerts will popup on their screen as well 

 

So, is there a way I can debug my client side code silently without using alert(s) and without bothering anyone else ?? Ofcourse, YES!!!!

 

Before we go on to the soultion. Lets go to the basics of execution platform of client and server code. 

 

Server side code executes at the server and since that's not on your machine, you do not have control over it's execution. By control I mean when the execution of code starts you can't hold it in between.

 

But this is not the case with client code, as client side code executes locally on your browser and the code that executes on your system you can control it. Here also by control I mean control on the execution of code written at client side.

 

And that's the reason why, how well you can debug server side code lies at the mercy of  options made available by server. But at Client side you have the POWER !!!!

 

Now let's see how we can use this POWER to debug client side code. All of the browsers that we use are equipped with developer tool, those who use console.log() must already be aware of this. There are different ways how you can access that and is also dependent on the browser you are using. Here I am using Google Chrome to show case. In google chrome you can access developer tool by below ways :

 

1. Press CTRL + SHIFT + I

          OR

2. Right click on the page and select last option Inspect

 

Below is the screen shot of how developer tool looks like, you will notice this open at the bottom of your page or right hand side of the page

 

 

Now if you see, there are multiple sections in this tool. For this article what is relevant is 'Source'.

 

Open any servicenow record's form and open developer tool. Then click on the 'Source' tab. On this tab you will see there is a page section in the left side of the pane. Which contains all the files that are used to display this form and those which will control the form on your browser. In this list you will see one file with name tableName.do?sys_id=sysid_of_the_record , you need to click on this file. Click on this file and it will show all the client side codes that are written for this table in the centre pane of the developer tool. Below is an example of a record that belongs to change reuest table :

 

Let's take a hypothetical example for debugging. I am writing a client script on Incident table. In this script we will set the value of short_description field based on Configuration item selected. The format of the short description will be "Issue with configuration_item_value". Below is the script that I have written with small issue because of which short description is not populating as per my expectation.

 

 

 

So let's see how to debug now.

 

Open any incident form and open the developer tool on that page. Click on the 'Source' table and then click on file whose name starts with 'incident.do?sys_id='  . Now click on the central pane where client side codes are showing and press CTRL + F and search for your any one line of your code from your script:

 

Now since it's just two lines of code, issue could be at first line of code or second. I will start the debugging at first line of code. To do this I will have to set the debug point at that line. For setting the debug point just do a single left click on the line number where you see your code. In my example that is at line number 2662 wo I will click on that number and this will set the debug point. Successfully setting of debug point is indicated by highligting the line number in blue color.

 

Once debug point is set, you are all set to start your debugging. Just change your 'Configuration item' field value and you will see that execution of code will STOP at the line of code where you have set your debug point. Yes you read it right, it will STOP the execution and will not move ahead untill you allow that. Now this is the POWER I was referring to at the begining which you have at client side. You can stop the execution of code at any point at your will in client side. Let's see in action:

 

In the above screen shot you can see at the top 'Paused in debugger' this means execution is at hold at line number 2662. Also youy can see that variables of already executed lines i.e. lines before line number 2662 like newValue, OldValue are showing values that they are storing at this point of time. This helps alot in knowing which variable is storing what value when your code is executing. Now to move the execution to the next line of your code click once on the Step over icon on the Paused in debugger area indicated by semi circular arrow with dot in center.

 

Doing this you will see execution has stopped at the next line i.e. at line number 2663. At this point you can see what msg variable is storing.

In the above screen shot we can see variable 'msg' is storing the value "Issue with : ", this confirms that there is an issue with the code g_form.getValue as it evaluated to blank. Now since we know where the issue is, looking closely at that, I realized that there is a spelling mistake in the field name. In the field name 't' is missing from incident. 

 

Let's make the change in the script and test again. After making the change in script reload the incident form and change the CI value again to test if script works this time. Yes, now we can see 'msg' variable storing the expected value:

Now click on the Step over icon again and see if short description field value is setting right. Ohh!! still not setting short description. Now the we are left with only once line of code and if it's not working then issue must be with that line. Looking closely at that we can see there is one spelling mistake in setValue() function as well. There is a spelling mistake in field name. In short_description,  'h' is missing:

Let's make the last modification and see if it works now. Make change in the script, reload the incident form and change the value of CI. Click on Step over icon, we can see 'msg' is populated right, click on Step over icon again and voillah! short description is populated now. You can stop the debugger now by closing the developer tool.

There is alot I wanted to share how debugging works in detail but this will make this article too much lengthy. So those who did not know how to debug your client side script and were using alert() only, try using this approach. See how your code executes line by line and enjoy debugging.

 

I hope the time you have spent on this article today, will save alot of time in your developer life tomorrow.