[go: up one dir, main page]
Scribd
Upload
13 views2 pages

Technical Best Practices

Uploaded by

Nandhini
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
13 views2 pages

Technical Best Practices

Uploaded by

Nandhini
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

ServiceNow

Technical Best Practices


Debugging Technical Best Practices
Debugging can provide information to hep you understand the system.

Debugging best practices can be classified into two main areas,

• Server-Side VS Client-Side practices

Before you start debugging, it is important to identify the source of the issue, and to be able to
reproduce the defect or bug. Potential sources include user error, invalid test data, test script
inaccuracy, and technical implementation. To help identify and remediate the issue, the tester should
provide the following information:

1. The record being worked on


2. The user ID used for the test
3. The steps required to reproduce the issue
4. The expected result of the test
5. The actual result of the test

Server-side Debugging:
Debug Log-

• System Diagnostics > Debug Log displays gs.debug(), gs.info(), gs.print() and gs.log()
statements as well as server logging information and error messages at the bottom of the
content frame.
• This helps you avoid alternating between the record you are trying to debug and the log
output.

Debug Business Rule-

• System Diagnostics > Debug Business Rule displays messages about business rules.
• These messages indicate which business rules are being run and when they are started (==>),
finished (<==), or skipped (===). If a business rule is skipped, the failed condition is displayed.

Debug Security Rules-

• System Security > Debug Security Rules places a debug icon on each field of a form.
• Point to the icon to see if there are any debug messages for the associated element. Click the
icon to expand details about read and write access. This module is very helpful when you are
using ACLs to control access to records and fields.

Stop Debugging-

• System Security > Stop Debugging disables all debugging processes.

Server-Side Debugging Persistence-

When you activate a server-side debugging module, it remains active until one of the following
occurs:
1. You activate the Stop Debugging module, located in System Security.
2. You log out from the instance.
3. The session expires (for example, the session times out).
4. You close the browser.

Log Messages controlled by a property-

The recommended way to debug server-side scripts is to use gs.debug() statements controlled by
system properties. It enables you to have distinct debugging in script includes so they can each be
debugged independent of each other.

Scoped Application Script Logging-

• gs.print() and gs.log() are older and not available in scoped applications, whereas gs.debug(),
gs.info(), gs.warn(), gs.error() work in both scoped applications and global are therefore are
more versatile going forward in future versions.
• Another helpful function gs.isDebugging() and can be used to determine if session debugging
is on OR the scoped property is debug.

Other Methods-

• Some developers use the gs.addInfoMessage() or gs.addErrorMessage() JavaScript methods,


but these may have an impact on the user experience.
• Using gs.log() (and alert() for client-side scripts) statements in scripts may seem fairly
anonymous to other users at first. The drawback to using gs.log() and alert() statements to
output debug messages is that they often get left in the code. If gs.log()and alert()statements
are left in the code, they can have a considerable impact on the size of the system log file.

Client-Side Debugging:
• To debug processes on the client side, click the settings icon in the banner frame, select
Developer from the menu and turn on JavaScript Log and Field Watcher.
• This will open the log viewer at the bottom of the window. Along with useful system
information, you may choose to include jslog() statements in client scripts and UI policy
scripts to help isolate and resolve issues.
• Unlike server-side debug statements, jslog() statements in client-side scripts do not consume
disk space. This means you can leave them enabled, even in production.
• alert() statements should be avoided if possible.

Disabling Debugging:
• Before you close out an update set or complete testing of the production instance, be sure to
disable all server-side debugging to save log space in production. To disable debugging,
search for all system properties that contain the string debug in the name and ensure they
are all set to false.
• This is another good reason to use properties to control debugging in a script. It makes
enabling or disabling debugging a simple task, such as when you need to validate use cases
or data.

You might also like