Search

Testing, Tips, and Tricks for ServiceNow

Impersonation

Impersonation is a powerful feature in ServiceNow that allows you to act and behave in the same way as a specific user. Impersonating your service account can allow you to see errors or other messages that might not be so easily surfaced. If impersonation is not available to you and your service account is able to, try to login to your ServiceNow instance directly as this will achieve the same result in a slightly less convenient manner.

Whilst not exactly the same as the process that Connection Center uses to create alerts, simply creating a new record on the SCOM Alerts table in ServiceNow is usually enough to help surface some basic errors or test out Creation Rule logic.

API Explorer

The REST API Explorer can be a good option for surfacing information that you may not otherwise see. Set the namespace to the appropriate Cookdown App (x_oklt_cookdown_sc for Alerts and x_oklt_cookdown_mm for maintenance) and then send the query to see the response.

Ideally, you would run this as (or impersonating) the service account as well as your normal user account as this can highlight permissions issues. If your account returns results but the service account returns nothing you may find that the service account has problems accessing the relevant tables or records in the tables.

Minimum Requirements for Incident Creation (and Mocking Alerts)

There are a minimum set of requirements for a Creation Rule to successfully execute:

Alert Name
Monitoring Object Parent IDs (If you wish to work with CI assignment)

These minimums can allow you to quickly create mock alerts to test your logic and/or scripts in isolation, filling in only what you need for your scenario.

If you are going to mock an Alert remember that some of these properties can be leaked back to SCOM via the API if a task is successfully generated. You should ensure any field that could make its way back to SCOM is in the expected format. For example SCOM expects a Guid for the Alert ID.

‘Re-run’ Alerts

If you are testing out logic or scripts in your creation rules it can be beneficial to use the same alert repeatedly. If your alert has not yet matched a creation rule modifying any property other than 'Created Record' or 'Creation Rule' and saving the alert will cause the Creation Rule logic to re-execute and attempt to match the alert to a rule. If your alert has already matched a Creation Rule you can delete this rule, any created record, and save the alert to cause your logic to re-run:

Use ‘Journals’ for troubleshooting

If you don’t have access to some of the more formal ServiceNow script debugging methods described here you can use one of the records ‘journal fields’ instead. On all of your scripts in Creation rules, you will have your SCOM alert, your task, or both. Each of these has one or more ‘journal' fields that can be used for debugging purposes. For example, your SCOM alert has its ‘Alert Activity' and your Task will have a 'Work Notes’ field. If you are using one of our scripted options you should have some sort of journal field available to you.

Each time you write a string to one of these journal fields it will create an entry or activity in that field allowing you to track where your script has gotten to. If you are having trouble with an if/else statement you might wish to write out the status just before you hit the if statement, a status report for each branch, and the values the condition is interested in:

	// Write out a status pre condition
	createdTask.work_notes = "Approaching RepeatCount IF";
	
	if(scomAlertRecord.repeatcount > 5){
		// Write out a status with expected logic
		createdTask.work_notes = "RepeatCount " +  scomAlertRecord.repeatcount + " is greater than 5";
	}
	else {
		// Write out a status with expected logic
		createdTask.work_notes = "RepeatCount " +  scomAlertRecord.repeatcount + " is not greater than 5";
	}

Using a Post-Processing example, you can export all properties and their values to the alert or incident history. If you are running into script problems you can use this to see the state of play at that stage in the script.

	// Create our variables to hold the output as strings
	var scomAlertString = "Properties and values on scomAlertRecord\r\n";
	var snowTaskString = "Properties and values on createdTask\r\n";
	
	// Loop through each property and value on each record and add them to the relevant string variable
	for (var key in scomAlertRecord) {
		if (Object.prototype.hasOwnProperty.call(scomAlertRecord, key)) {
		scomAlertString += '\r\n' + key + ": " + scomAlertRecord[key];
		}
	}	
		
	for (var taskkey in createdTask) {
		if (Object.prototype.hasOwnProperty.call(createdTask, taskkey)) {
			snowTaskString += '\r\n' + taskkey + ": " + createdTask[taskkey];
		}
	}
	
	// Add the string variables to the work notes and alert activity
	// In this case I'm adding task properties to the alert and alert properties to the task
	// We do this AFTER pulling all the properties to prevent work_notes and alert_activity being overloaded
	createdTask.work_notes = scomAlertString;
	scomAlertRecord.alert_activity = snowTaskString;

Try not to run through this repeatedly as the work_notes and alert_activity fields will nest and get increasingly noisy!

Template Creation Rules

ServiceNow provides you with the option to 'Insert' modifications to a record without updating the original. This can help speed up the creation of more complex Creation Rules.

To start with a simple example we will create a template and then create a new Rule from it. Start with a rule as follows:

Name: Template
Active: False
Processing Order: 20,000 (or a high numbered unique value)
Category: Hardware
Assignment Group: Some test assignment group (US Presidents Group 1 in this example)

Submit the rule so that this is in your list of Creation Rules:

Re-open this rule to work with it. Set the properties as follows:

Name: From Template
Processing Order: 100 (or a different unique value)
Active: True
Alert Condition: Some valid condition ([Alert Id][is not empty] in this example)

Now instead of selecting Update, select the hamburger menu and then 'Insert':

You should now have a new copy of the rule with only the properties we changed modified:

Whilst this is a fairly trivial example that probably doesn’t benefit from using a template, there are a number of situations (for example if you are heavily utilizing scripting) where this could significantly speed up development. This also doesn’t have to be limited to Creation Rules, you could do the same with an alert, making sure that you give it a new guid for an ID to simulate a new issue coming in.

Quick Field Changes

If you want to make a quick change to a field that is visible from the main view, you normally only need to double click on the field to modify it directly: