Community Code Snippets: Using a System Property to Control Logging

[sabell2012]

NOTE: MY POSTINGS REFLECT MY OWN VIEWS AND DO NOT NECESSARILY REPRESENT THE VIEWS OF MY EMPLOYER, ACCENTURE.

DIFFICULTY LEVEL:    BEGINNER
Assumes having taken the class SSNF and has good intermediate level of knowledge and/or familiarity with Scripting in ServiceNow.

---

A technique I utilize myself for turning run-time server-side debugging on and off; after a push to production, is to create a System Property for the purpose. The need for this is two-fold: First to put control of debug messages into the hands of the ServiceNow Admin (who, after all, will be saddled with looking after what I wrote), and second to reduce the amount of messaging ending up in the log, unless it is absolutely necessary.

The nice part about this technique is that it is usable with all Server-Side coding:   Business Rules, Script Includes, Workflows, Scheduled Jobs, Script Actions, UI Actions (server-side), Transform Scripts, etc.   I find it gives a certain engineering polish to my projects!

To implement this is really a simple matter.  

1. Create a system property
2. Pull in the property value in my server-side script
3. Utilize the value

To create the system property:

1. Navigate to sys_properties.list. The System Properties list view will be displayed.
2. Click the New button to display the new System Property form.
3. I fill in my form thusly:
   1. Name: serverside.debug
   2. Description: Server-side debug control
   3. Choices: true|false
   4. Type: true | false
   5. Value: true
   6. Click Submit to save my work.

Now I can use it anywhere I write server-side code!

An example to run in Scripts - Background:

var debug = gs.getProperty('serverside.debug', false);
if (debug) {
    gs.info('---> debugging is on!');
}

A use case could be to use this property to turn debugging on or off in a Business Rule.

Since this is a true/false property it is pulled into the code by getProperty as a boolean; making things simple.

You can surround all of your debugging code (logging or otherwise) with a simple "if" statement and turn it off prior to going to production (or even after if you want to watch things there for a bit after implementation). This provides an excellent way to do after-push production debugging if needed.

One suggestion here is to use this with restraint. You might consider doing this on a project level as, after creating this sort of thing for several releases, turning it on may fill up the log with a lot of unneeded debugging noise. Just saying. 🙂

Enjoy!

Steven Bell.

If you find this article helps you, don't forget to log in and mark it as "Helpful"!

---

Originally published on: 08-28-2016 08:02 AM

I updated the code and brought the article into alignment with my new formatting standard.