Script Debugging: Script Tracer and Debugger in ServiceNow CAD
Script Debugging (Script Tracer and Debugger) in ServiceNow
Why Is Script Debugging Important?
Script debugging is a critical skill for any ServiceNow developer. As applications grow in complexity, understanding how scripts execute, identifying errors, and tracing logic flow become essential to maintaining a stable and reliable platform. Without proper debugging tools and techniques, developers may spend excessive time guessing where issues lie, leading to slower development cycles, more bugs in production, and degraded user experience. For the ServiceNow Certified Application Developer (CAD) exam, understanding script debugging demonstrates your ability to build, maintain, and troubleshoot applications effectively.
What Is Script Debugging in ServiceNow?
ServiceNow provides two primary tools for debugging scripts:
1. Script Debugger
The Script Debugger is an interactive debugging tool that allows developers to set breakpoints in server-side scripts and step through code line by line. It operates in real time and is used primarily for debugging Business Rules, Script Includes, and other server-side scripts. Key features include:
- Breakpoints: You can set breakpoints at specific lines of code where execution will pause, allowing you to inspect variable values and the call stack.
- Step Over, Step Into, Step Out: Standard debugging controls that let you navigate through code execution at your own pace.
- Variable Inspection: While paused at a breakpoint, you can examine the current values of local and global variables.
- Call Stack: View the chain of function calls that led to the current point of execution.
Important: The Script Debugger is session-specific. It only affects the session of the developer who has enabled it. Other users are not impacted. It is available for server-side scripts only — it does not debug client-side scripts.
2. Script Tracer
The Script Tracer is a passive monitoring tool that traces the execution of scripts during a transaction. Rather than interactively stepping through code, the Script Tracer records which scripts were executed, in what order, and how long each took. Key features include:
- Transaction Tracking: It shows all scripts that fire during a given transaction (e.g., when a record is inserted, updated, or deleted).
- Execution Order: It reveals the sequence in which Business Rules, Script Includes, ACLs, UI Policies (server-side), and other scripts execute.
- Time Analysis: It displays the time each script takes to execute, helping identify performance bottlenecks.
- Filtering: You can filter by script type (Business Rules, Script Includes, etc.) to focus on specific areas of interest.
Important: The Script Tracer is also session-specific and does not affect other users. It is a read-only observation tool — it does not allow you to modify execution or set breakpoints.
How Do They Work?
Script Debugger Workflow:
1. Navigate to System Diagnostics > Script Debugger.
2. Enable the debugger for your session.
3. Open the script you want to debug (e.g., a Business Rule).
4. Set breakpoints by clicking on the line numbers where you want execution to pause.
5. Trigger the transaction that causes the script to run (e.g., update a record).
6. The debugger will pause execution at your breakpoint. You can then inspect variables, step through lines, and observe behavior.
7. Use Step Over (F10) to execute the current line and move to the next, Step Into (F11) to dive into a function call, or Step Out (Shift+F11) to exit the current function.
8. When finished, disable the debugger to resume normal execution.
Script Tracer Workflow:
1. Navigate to System Diagnostics > Script Tracer.
2. Enable the tracer for your session.
3. Perform the action you want to trace (e.g., submit a form, run a workflow).
4. Return to the Script Tracer to review the list of scripts that were executed during the transaction.
5. Analyze the order of execution, time spent in each script, and any unexpected script firings.
6. Disable the tracer when finished.
Key Differences Between Script Debugger and Script Tracer:
| Aspect | Script Debugger | Script Tracer |
The Script Debugger is interactive — it pauses execution at breakpoints and lets you step through code. The Script Tracer is passive — it only records and displays which scripts ran and in what order without stopping execution.
The Script Debugger is best for finding logical errors in specific scripts, while the Script Tracer is best for understanding the overall flow of script execution during a transaction and identifying performance issues.
When to Use Each Tool:
- Use the Script Debugger when you know which script has an issue and need to inspect variable values and logic flow step by step.
- Use the Script Tracer when you are unsure which scripts are firing during a transaction, when you want to check execution order, or when you need to identify performance bottlenecks.
Additional Debugging Techniques:
- gs.log() / gs.info() / gs.debug(): Server-side logging statements that write messages to the system log. Useful for quick debugging without the full debugger.
- jslog(): Client-side logging that outputs messages to the browser's JavaScript console.
- gs.addInfoMessage() / gs.addErrorMessage(): Display messages on the form to verify script execution during development.
- System Log (syslog): Review entries in System Logs > System Log > All to find errors and debug messages.
Exam Tips: Answering Questions on Script Debugging (Script Tracer and Debugger)
1. Know the scope of each tool: The Script Debugger and Script Tracer are server-side only tools. If a question asks about debugging client-side scripts, the answer involves the browser's JavaScript console or jslog(), not the Script Debugger or Tracer.
2. Remember session isolation: Both tools are session-specific. They do not affect other users' sessions. This is a commonly tested concept. If a question asks whether enabling the debugger affects all users, the answer is no.
3. Differentiate between interactive and passive: The Debugger is interactive (breakpoints, stepping). The Tracer is passive (observation only). Exam questions often test whether you can distinguish between the two.
4. Understand breakpoints: Know that breakpoints pause execution at a specific line. You must trigger the relevant transaction for the breakpoint to be hit. Breakpoints are set in the Script Debugger, not in the Script Tracer.
5. Execution order visibility: If a question asks which tool shows the order in which scripts execute during a transaction, the answer is the Script Tracer.
6. Performance analysis: If a question asks which tool helps identify slow-running scripts, the answer is the Script Tracer, because it shows execution time for each script.
7. Navigation paths: Remember that both tools are found under System Diagnostics. Questions may reference the module path.
8. Watch for distractors: Questions may mention tools like the JavaScript Debugger (browser-based), REST API Explorer, or the Application Log. Make sure you map the correct tool to the correct use case.
9. Logging vs. Debugging: Know that gs.log() and gs.info() are lightweight alternatives to the full debugger. Some questions may ask about the best approach for quick troubleshooting versus detailed debugging.
10. Practice scenarios: Be prepared for scenario-based questions such as: A developer needs to find out why a Business Rule is not setting a value correctly. Which tool should they use? — The answer would be the Script Debugger because they need to step through the logic and inspect variable values. Another scenario: A developer notices that a record update is taking too long. Which tool helps identify the cause? — The answer would be the Script Tracer because it reveals execution times.
11. Roles and access: Be aware that access to debugging tools typically requires the admin role or specific debugging roles. This may appear in questions about who can use these tools.
Summary:
Script debugging in ServiceNow revolves around two main tools: the Script Debugger for interactive, step-by-step analysis of server-side scripts, and the Script Tracer for passive observation of script execution order and performance. Both are session-specific and server-side only. For the CAD exam, focus on knowing when to use each tool, how they differ, and the specific capabilities of each. Combine this knowledge with an understanding of logging methods (gs.log, gs.info, jslog) and you will be well-prepared to answer any script debugging question on the exam.