Please Note: As of the June 2011 Preview 1 release, you have an optional second parameter in the “gs.log” function call that will set your source string. If you don’t need to log warning or error messages, you can use this feature in the class described below instead of using the Packages Syslog object.

In every integration that I perform, I like to have a way to setting apart the log messages from the integration apart from all other log messages in the system. This also gives me the option to turn debug logging on and off with my integration.

In order to do this I use a second parameter in the gs.log() method. I also create system properties so that the logging is more configurable. For information on setting up system properties for an integration, you can visit my blog entry about setting up a system properties page for an integration.

This provides me an opportunity to create configurable settings that customize my log statements. The following screenshot shows an example of some logging configuration that you can set up for your integration.

With those settings, your log might look like the following screenshot:

If you will likely have a number of different integrations in your ServiceNow instance, I recommend that you create a base class for the system logger that can be extended by a logging class that would be specific to your integration.

A base class Script Include for custom logging may look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
var ScriptLogger = Class.create();

ScriptLogger.prototype = {
 
  /*
   *  Set a source for log entries.  With every log entry the string
   *  in this variable will be set in the "Source" field of the log
   */
  SOURCE : "CUSTOM",
 
  verbose : "false", //don't log debug statements by default

  initialize : function() {
  },
 
  info : function(s) {
    gs.log(s, this.SOURCE);
  },  
 
  debug : function(s) {
    if (this.verbose == 'true') { //debug logs only show if Verbose
      gs.log(s, this.SOURCE);
      if (gs.hasRole('admin')) {
        gs.addInfoMessage(s); //adding InfoMessages for admins on debug
      }
    }
  }
}

Now that we have our Base Class, when we create an integration, we can extend that class and grab a “Source” string and a “Verbosity” setting from that integration’s settings.

The following is a script include for a fake integration called “MyIntegration”.

1
2
3
4
5
6
7
8
9
10
var MyLogger = Class.create();

MyLogger.prototype = Object.extendsObject( ScriptLogger, {

  initialize : function() {
    this.SOURCE = gs.getProperty("com.snc.integration.myintegration.logsource", "MyIntegration");
    this.verbose = gs.getProperty("com.snc.integration.myintegration.debuglogging", 'true');
  }

});

Now, of course, for this to work right, you will need to create the properties that were used in the constructor. If you do not create the properties, the values will default to whatever is in the second parameter for the “gs.getProperty” call.

When you are coding for your integration, you can instantiate your integration’s Logging class and then log using the “info” and “debug” methods.

Here is a sample script using the “MyIntegration” class:

1
2
3
4
5
6
var s = new MyLogger();
s.debug("The integration is starting");
s.debug("Trying to talk to the server");
s.info("No port was provided in the connection info...using default");
s.info("Could not connect to the third party server!");
s.debug("The integration has ended");

That script generates three debug log statements IF you have your integration’s debug setting set to true. Two informational messages are printed regardless of the debug setting in your integration.

Go ahead, play around with this in your ServiceNow instance and let me know if you do anything cool with your logging.

For your convenience, I have put the base class and the test integration script includes into an update set that you can download below.

ScriptLogger Update Set