4 minute read
Debugging in ServiceNow is am essential skill to master. An array of tools are available to help developers understand what the system is doing and narrow down where unexpected behavior is happening. Today we will look specifically at several ways to debug when doing scripting.
Session Debug
A feature released in the New York release unified the session debugging modules. A session is a unique login for a unique user - typically one browser on one device. Now when selecting a session debugging option from the navigation, a new window launches.
The session log and debugging options are available in this interface. On the left, you have the transaction list available. Selecting one of the transactions will jump you to the start of that transaction in the log entries. The search filter does what you would expect, filter the log entries to just lines that contain the search term. The filters in the dropdowns can be handy when many things are happening at once.
It can be confusing to see a filter for debugging options like business rules and also a setting for business rules. The filter narrows the displayed log, where the settings toggle debugging options on/off. Only log entries for the debugging types that are enabled will be visible and then filterable. Most debugging will not need all debugging types turned on, as that will produce to much noise that must be filtered to find the information you as the developer are looking to find.
When should you use the session debugging? session debugging has a variety of options from ACL to Business Rules to Upgrade. What kind of information you are seeking will lead you to one or several of the debugging options. If you wish to know why your new script isn’t adjusting a field as you expect, then the business rule would be my first visit unless you can utilize a breakpoint. (we will talk more about breakpoints later). Access can be easily checked by using the security debugging along with impersonation.
The joining of all the logs into one powerful interface should help you find the root cause of whatever you are inspecting. Utilize the clear log tool between tries to help lessen the noise when applicable. Knowing how to best filter, find, and examine the results will enable you to develop faster and hopefully with fewer errors. One way to do that is to try out the debugging before you encounter an issue. Give it a try on an update of a record you are familiar with before adjusting any business logic. That way, you have some idea of what things look like before you changed anything.
Breakpoints
Breakpoints and Conditional Breakpoints are where we insert a pause in the execution flow. That pausing leads to an essential note: breakpoints only apply in direct synchronous sessions. Only the developer that set the breakpoint, and only in their session in which a script debugger window is opened, will be paused. Thus you can safely debug without impacting your fellow developers. You can read more about the details of the script debugger in the detailed blog entry.
Leveraging the script breakpoints can be a powerful tool to reduce the need for log entries to validate field and object values. Using the inspector, you can see the value for all of the variables as you step through your script and other scripts called later in the execution flow. Figuring out how and why your result didn’t reach the outcome you inspected can be quickly determined with this method.
A Tip is invoking an asynchronous process directly through background scripts or the rest API explorer.
Logging
No entry on debugging would be complete without at least a reference to the old stand-by, logging. Inserting logs can be quite useful especially for warn and error statements once a given script is in use in production. I discourage system log entries for normal operations as they pollute your codebase and log table with noise. One note: if operating in the global scope, use the source parameter to help facilitate filtering.
The node logs are the point of last resort for most debugging. ServiceNow logs quite a bit of detail inside of the node logs. I might do a future entry just on node logs as there is lots to cover but isn’t a general use case. If you leverage the other options available, you can typically avoid having to dive into the detailed node logs.
Happy Debugging
Hopefully, these tips will help you use the tools available to you as a ServiceNow developer. Please share in the comments any other great debugging ideas that I did not document here. Time to get back to building my application!
Share this post
Twitter
Facebook
Reddit
LinkedIn
Email