Overview
The ServiceNow platform consists of a range of business rules, Script Includes, and internal codes. Occasionally, you need to know how certain values are being inserted, updated, or deleted to be able to understand how these happen and to narrow down the troubleshooting.
This article describes a debugging business rule that will print out the StackTrace when the condition is met.
Prerequisite and Assumptions
In order for the troubleshooting business rule to be effective, you need to have a hypothesis of what you want to capture. Printing out everything slows things down and produces too many useless logs. A good debug business rule therefore depends on a good restrictive set of conditions.
Examples:
-
If you have a lot of new records on the u_test table by user Abel Tuter, you might want to create a debug business rule for "insert" on table u_test and "created by" as Abel Tuter and nothing else.
-
If you have a lot of updates on the u_test table by David Loo, you might want to create a debug business rule for "update" on table u_test and "updated by" as David Loo and nothing else.
-
If you have a lot of records being created for the table u_test with the name ABCDE, you might want to have a debug business rule on "insert" on table u_test and "name" as ABCDE and nothing else.
Script of the Debug Business Rule
The following example shows a sample script for the debug business rule. You can customize the details according to your own situation.
(function executeRule(current, previous /*null when async*/) {
// Add your code here
gs.log('***** DEBUG - ' + new Date().getTime() + ' - ' + current.sys_id + ' - \n' + GlideLog.getStackTrace(new Packages.java.lang.Throwable()), 'Stacktrace Debug');
})(current, previous);
Logs
You can check the logs for the debug business rule on the syslog table where "source" is "Stacktrace Debug" (the second parameter of the gs.log).
For example: https://<instance-name>.service-now.com/syslog_list.do?sysparm_query=source%3DStacktrace%20Debug