Large Teams (Part 1 of 3) - Debugging

[Chuck Tomasi]

For the past year or so I've been working with large customers with large deployment teams. This differs greatly from when I was a customer with a team of two people configuring the platform. As a result, I've learned a few things in the past few months. In this series, I'll cover some of the things I've learned from working in a larger team. Feel free to add comments and share your contributions.


One of the first things we ran into on a large team was sending debug messages to the screen. It can be a bit challenging when dealing with a hierarchical system such as ServiceNow. For example, someone puts a gs.addInfoMessage() call in a business rule that runs on the task table and that business rule is inherited. Now when I'm working on change, I see blue messages appear at the top of the screen with 10 cryptic messages like "i=3 true". Where did that come from?! And I've got a demo in 10 minutes to show off my new screen format.

If you're going to be debugging in a team environment, try using gs.log() on your sever side scripts. Output ends up in System Logs> Script Log Statements. My preference is to make the logs messages as easy to filter as possible. Here are some ideas to make it easier to filter what I see in the script log:

1. Option 1: Use the "source" argument in gs.log() to create your own source based on your name, or the item you are debugging. For example, gs.log('Result=' + result, 'incident'); No, you won't be able to find them in the System Logs> Script Log Statements (because that module is defined to look for source '*** Script'), but you can create your own module or filter to get just your messages.
2. Option 2: Add meaningful information in the text of your gs.log() statements to set them apart. My personal choice is to start all my debug messages with ">>>DEBUG", it's easy to spot and filter on. Depending on the situation, I also add the script name and perhaps the function (in script includes) so I know exactly where the message is coming from. Note: If you look at the debug outputs, they don't always show up in the exact order they were executed. Run a for-loop and log the counter to the log some time.
3. Option 3: Sure, in the example above, writing

   
   gs.log('>>>DEBUG: myChangeTaskFunctions: loadNextTask():…')

   as a prefix every time is kind of annoying if you have to do it 20 times. And when you're done, going back to comment them all out is also a pain! For script includes, try creating a private _debug() method something like this:
   

   
   
     initialize : function() {
   
       this.debug = true;
       this.debugPrefix = '>>>DEBUG: myChangeTaskFunctions:';
     },
   
     _debug : function (s) {
   
        if (this.debug)
          gs.log(this.debugPrefix + ' ' +s);
     }
   

   
   
   The property

   
   this.debug

   determines if anything will be output in the _debug() method, and the property

   
   this.debugPrefix

   saves lots of typing while giving consistent information to your debug output.
   

   
   Now you can sprinkle debug statements throughout your script like this:
   

   
   this._debug('loadNextTask(): querying table…');

   
   

When you want to turn all the debug statements off in that script include, just go to initialize() and set this.debug=false.

• For Business Rules, use a local variable with your debug prefix, such as:
  

allMyCircuits();

function allMyCircuits() {
  var dPref = '>>>DEBUG: BR: All My Circuits ' + current.number + ' ';
  gs.log(dPref + 'starting the function');
}

It's fairly trivial to use a gs.log() call and get useful information to filter on. One final note, I included the name of the business rule in the log. I often forget to turn off those debug messages after development is done. Months later I find them cluttering up the log. It's nice to know where they are coming from!


Reference:
gs.log()