NOTE: MY POSTINGS REFLECT MY OWN VIEWS AND DO NOT NECESSARILY REPRESENT THE VIEWS OF MY EMPLOYER, ACCENTURE.
DIFFICULTY LEVEL: INTERMEDIATE
Assumes basic knowledge and/or familiarity of the Studio IDE, and Scripting in ServiceNow.
____________________________________________________________________________
Recently I gave an Ask-the-Expert session on Scoped Debugging. This set of three articles is a follow-up to that session. These are for those of you who would like to work through the examples yourself.
In this first article I will talk about what is available on the client-side. In part 2 I will present you with more in-depth debugging of scripts from the Client-Side. In part 3 I will present what is available on the server-side.
Create a Scoped Application
First we will create a Scoped Application to contain the examples we will be working with.
1. Navigate to System Applications > Studio. A second browser tab will open with the studio Load Application form.
2. Click on the Create Application button. The Create Application form will be displayed.
3. Click on the Create button for Start from scratch.
4. Fill in the name field on the form with: Debugging Logger
5. Click on the Create button to generate your application and open the Studio.
Create a Client Script
The first thing I will show is concerning the alert() statement. This is the bedrock foundation that all browser-side developers use for the "I made it to here" debugging. Let's create a simple Client Script to show how this works.
1. Click on the Create Application File button
2. In the Filter field type Client Script, and choose Client Script from the Filter Results
3. Fill out the form with the following:
Name: Logging Scoped
Table: Incident
Active: True
UI Type: Desktop
Type: onLoad
Description: Script to test logging and debugging from the browser.
Script:
function onLoad() {
var number = g_form.getValue('number');
alert('---> Incident Number: ' + number);
}
4. Click the Submit button to save your script.
5. From your Instance navigate to Incident > Open
6. Open your favorite incident. The alert statement will fire and should look something like this:
Alert provides a way for a developer to indicate how far the code has executed on the Browser side. I usually do not use this for production code. Instead I find g_form.addErrorMessage or g_form.addInfoMessage to be better more user-friendly mechanisms. I find myself using alert less-and-less, and instead I use jslog(). jslog() places the statement in the console log instead of interrupting the user with a modal pop-up box! This is a much preferred method; especially if you forget to remove the log statement before pushing to production! BTW, an excellent article on what is, and is not, allowed in Scoped client-side scripts is: Supported and unsupported client scripts.
7. In the Studio modify the Logging Scoped Client Script. Change the alert statement to a jslog() statement.
Script:
function onLoad() {
var number = g_form.getValue('number');
jslog('---> Incident Number: ' + number);
}
8. Click on the Update button to save your script modification. This will automatically place a log message into the console log when we open an incident record.
Okay, we now have everything we need to begin testing and debugging.
Client Side Debugging Tools
The JavaScript Log and Field Watcher
7. Open an incident record, or if you still have it open from the previous testing; right click at the top of the incident form and click on the Reload Form link. The idea is to trigger the onLoad Client Scripts. The alert box should no longer be displayed.
8. From your instance click on the Systems Settings gear button in the upper right. This will open the System Settings form.
9. Click on the Developer tab.
10. Make sure the following switches are set to "on":
- Show application picker in header
- Show update set picker in header
- JavaScript Log and Field Watcher
As a Scoped Application developer I like having the first two turned on to allow me to quickly jump between scopes. This also allows me to make sure I am in the right Scope AND the right Update Set. The JavaScript Log and Field Watcher allows me to view the console log specific to ServiceNow, and it will be where our jslog messages will appear. BTW, I don't use Field Watcher that much and won't be covering it in this article, but you might want to check it out and see if it is useful to you.
11. At the bottom of the form make sure that JavaScript Log is selected, and click on the Medium button. You may look at Small and Large just to get a feel for what they do.
12. Click on the Clear Log button (looks like a circle with a diagonal slash through it). This will clear the immediate console log.
13. You may have to scroll down a bit in the JavaScript Log to find your jslog() message. It should look something like this:
Browser Developer Tools
An alternative to the ServiceNow JavaScript Log is your browser's console log. Most every browser available has some sort of developer tool(s) that allows for this. These tools display a lot more information about the state of your session than does the ServiceNow JavaScript Logger. That can be good and bad. Good in that all errors and warnings are displayed. Bad in that there are a lot of messages that are displayed that are not ServiceNow specific. This "noise" can be overwhelming when you first start using this method. I will briefly cover three of the top browsers: Internet Explorer, Google Chrome, and Mozilla Firefox.
Note how in each browser the jslog message is displayed (the red arrows).
With Internet Explorer press the F12 button, and the console will be displayed. Again you may have to scroll down a ways to see your jslog() message, but it will be there. There is no provision to dock it to the side like in other browsers. However, you can undock it; at which point it will be in its own window which you can then move around or push to the back. Click on the close ("x") button or press F12 again to remove the console.
With Google Chrome pressing the F12 button brings up the console. Unlike Internet Explorer there is the ability to dock it to the side or at the bottom. Again you may have to scroll a bit or do a search to find your message.
Even though Chrome is my browser of choice I like the Mozilla FireFox developer tools better for their organization and ease-of-use. Again, F12 brings up the console window, and like Chrome you can dock it to the side or at the bottom. BTW, the old FireBug plugin for FireFox has been deprecated.
So that is pretty much it concerning the various client console logs and how to place log statements into them with Script.
In my next article (Mini-Lab: Scoped Debugging and Logging — Part 2) we will talk about how to use the client-side debugging tools to debug our client-side AND server-side scripts!
Steven Bell
For a list of all of my articles: Community Code Snippets: Articles List to Date
Please Share, Like, Bookmark, Mark Helpful, or Comment this blog if you've found it helpful or insightful.
Also, if you are not already, I would like to encourage you to become a member of our blog!
1 Comment
