Help
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
sabell2012
Mega Sage
Mega Sage

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

 

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


In my previous two articles I tackled variable substitution using GlideSystem methods in server-side scripts, and then also how to apply this and other techniques in Business rules. Here, I will be showing how to use these techniques inside Workflows, and demonstrate some tricks and methods of logging.

 

My previous two articles in case you want to do some extra digging:

 

Community Code Snippets - Logging: Some Notes on Variable Substitution

Community Code Snippets - Logging: Some Notes on Business Rules

 

In the ServiceNow platform we have three scripted logging methods attached to the Workflow object:

 

  • workflow.info
  • workflow.warn
  • workflow.error

 

These work very similarly to their GlideSystem analogs (sic. gs.info), but, with one really significant difference: They all three write to the workflow context log! Yes! No more searching through the System Log looking for my workflow logging messages!!!

 

Oh yeah, and like their GlideSystem analogs (and unlike gs.log) they are also scope safe. 😁

 

Lab 1.1: Creating the workflow to test the logging

 

1. Navigate to Workflow > Workflow Editor

2. Create a new workflow:

Name: Logging Test

Table: Global [global]

Description: Workflow logging examples

If condition matches: -- None --

3. Place a Run Script Activity on the form:

Name: Test Logging

Script:

 

var location = 'WF:' + context.name + '.' + activity.name;    

// Current Factory
var current = new GlideRecord('incident');
current.addActiveQuery();
current.setLimit(1);
current.orderByDesc('number');
current.query();
current.next();

// Set up some variables
var number = current.number;  
var caller = current.caller_id.getDisplayValue();  
var category = current.category.getDisplayValue();  
var impact = current.getValue('impact');  
var priority = current.getValue('priority');  
var urgency = current.getValue('urgency');  

// Create the test message
var message = gs.getMessage('--->[{6}] \n\tNumber:\t\t{0} \n\tCaller:\t\t{1} \n\tCategory:\t{2} \n\tImpact:\t\t{3}\n\tPriority:\t{4}\n\tUrgency:\t{5}\n',    
      [number, caller, category, impact, priority, urgency, location]);  

// Send it to the System Log
gs.log(message, location);   // the old way

// Send it to the Workflow Context log AND the System Log
workflow.info(message);
workflow.warn(message);
workflow.error(message);

 

4. Click on the Submit button to save your work.

 

NOTE: You can see that I have utilized the same code as that used in the Fix Script in my original article. Instead of gs.info, etc. I used the workflow objects. These write not only to the Workflow Context log, but also to the System log.

 

The workflow should look like this:

 

sabell2012_1-1702914917828.png

 

5. Run the workflow.

 

sabell2012_2-1702915009160.png

 

6. Navigate to Workflow > Live Workflows > All Contexts. Then bring up the most recent context labeled with a Workflow Version of Logging Test.

 

You will see that the workflow object wrote the three logging statements to the Workflow Context log:

 

sabell2012_3-1702915149326.png

 

This is slick! The need for bringing up the System Log list view (which, if you have a lot of entries in it, could take forever to display), and searching through the results was just made obsolete!

 

So, let's see what was actually written into the System Log.

 

7. Navigate to System Logs > System Log > All.

8. Search for Message that begins with "--->".

 

sabell2012_4-1702915272582.png

 

You will see that all three Workflow logging statements were written out, as was the gs.log. Note that you still should follow the best practice of including the identification information in your message. This will short-cut having to search out mystery messages in the log. Note that the source of the gs.log show the workflow and that the the others are marked with a source of Activity. Old vs. new.

 

Remember that the best practice is to remove debugging logging from your code before it goes to production!

 

For more information on the Workflow object.

 

For more information on GlideSystem.

 

I want to highly recommend taking the ServiceNow Scripting training class should you get the opportunity.   The class has an entire module covering Workflow Scripting.

 

Enjoy!

Steven Bell.

 

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

 

sabell2012_0-1702914655511.png


Originally published on: 07-10-2016 08:39 AM

I updated the code, fixed broken links, and brought the article into alignment with my new formatting standard.

1 Comment