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.

‘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

On all of your scripts in Creation rules you will have your SCOM alert, your task, or both. Each of these have 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!

Further Reading

This section is also very closely related to Troubleshooting ServiceNow. It would also be worth familiarizing yourself with that page as troubleshooting steps can also be helpful in testing scenarios.

Some of the tips on this page also require scripting, so check out the Post-Processing and Advanced Creation Rules pages to get further information on how to use these.