ServiceNow Admins and Developers use logging statements all the time.
When you’re in the development environment, you’re constantly throwing logs, to see what value is shown, when a certain action is taken.
But do you use gs.log() or do you use gs.print()?
The two look very similar, and do have some common results.
The fundamental difference between the 2 logging functions are:
gs.log() creates a record in the System Logs table, where gs.print() does not.
If you need to refer to the value, in a business rule, or script include – we recommend using gs.log().
Also a small note, this post only applies to applications being run in the Global scope.
If you’re writing a custom scope, you cannot use gs.log()! You must use gs.info(), when you try to use gs.log() in a scoped application, ServiceNow will throw an error log whenever gs.log() is reached in a script.
Using gs.info() in a scoped application, will create a log in the Application Logs table.
So remember:
- Global scope – use gs.log();
- Custom scope – use gs.info();
If you just want to test something quickly, and are running background script – feel free to use gs.print() – just remember that it will not create a record anywhere for you to reference later on.
gs.log() vs gs.print()
Consider the following example, using a background script.
Example script:
gs.log("This creates a record in the [syslog] table");
gs.print("This will print in background script runs, but will NOT show in the [syslog] table");
When you run this script in a background script, you’ll get the following output:
This is great, you now have the result of your gs.log() and gs.print() output statement.
But if you were to refresh this, you’d lose one value and you’d have the other retained.
If you go over to your System Logs [syslog] table, you’ll see that gs.log() is captured, where as gs.print(), is no where to be found.
When To Use gs.log()
We prefer this, in almost every case.
If there’s ever a reason to retain or later refer back to what you’ve done, you’ll want to use gs.log(). This is going to almost always be the case. If you’re on the fence, default to gs.log(), there’s no issue if you create a log, that you may need to refer back to.
If you’re running a background script and modifying data, we’d definitely recommend using gs.log(), you’ll be able to refer back later on to what was updated, if you log properly.
If you’re constantly testing and debugging a tough business rule, you’re really going to want to use gs.log(), so you can see how the value changes over time, as you modify your script.
You may also want to log with a source value, for easier lookup in the syslog application.
Take a look at the following article to understand how and when to add a source to your system logs, this is magical if you’ve never used it before. It will help you organize your log statements 10x better than without using a source.
When To Use gs.print()
If you just need to quickly retrieve a value in a background script, and you don’t care about looking at it later – feel free to use gs.print().
Say you’re just writing a really small script to retrieve the current time, and you just want to make sure that it works in a business rule.
Go ahead and run it using gs.print() in a background script, make sure that the output is the way you want it, copy the code and then move on.
To summarize the entire point of this post, just make sure you fully understand the following point:
If you’re using a business rule, scheduled job or script include in Global scope – you must use gs.log()! Because if you use gs.print(), it will not show up anywhere.
We don’t want to log in the production environment when it’s not necessary. So make sure to pull your gs.log() statements from your code, when you don’t need it. If you find that you may need to check values after a new process runs a few times in production, I see no issue with leaving the log statement there.
