November 2019

Adding and Accessing a System Property

As I’ve indicated in the past, I write this blog at least partially as a way of documenting things that I’ve figured out, but which I know I’ll need to refer back to at a future point. This is one of those things.

When programming my side projects, I use system variables on a regular basis. Having a constant in one spot where I can change it if something about my environment changes is hugely helpful. Likewise, it is very beneficial to be able to have one value for my dev environment and another value when the code is running on the production server.

Creating a system property is the equivalent thing in ServiceNow, and I’m grateful to my previous boss, Chris York, for showing me how to both set one up and then access it from inside of my server-side script include.

To create or modify a system property, go to:

sys_properties.list

Then, if we assume that I set up a system property that is named ‘deans.api.key’, to access it from inside of a server script, I would use:

gs.getProperty(‘deans.api.key’);

This would return the value of the system property, allowing me to assign it to a variable or otherwise use it.

Hugely helpful!

getXML() and getXMLWait()

I have a common pattern I use where I have a server-side script include that does all of the heavy lifting, which then subsequently needs to be accessed by something on the client script.

Using a GlideAjax script include allows you to take input from the client side of things and pass it to the GlideAjax which in turn passes it to your server-side script include.

This works well on the whole, but can run into problems if you have something on the back end that isn’t instantaneous–like an API call. In those scenarios, you can see instances where the client script has moved on and is acting as though it has the data from the server-side script include before the data is actually there.

In modern JavaScript I would handle that by using async/await, but it took a bit for me to figure out how to deal with it inside of ServiceNow.

The correct way to do that is with getXMLWait(), or by calling getXML() and then passing in the name of the function you want to run after the server-side stuff has run.

Note, you have to pass just the name, not the name and (), so if you had

function doSomething() = {

console.log(“Hello World”);

}

and you wanted to add a callback to a getXML(), then you would use:

getXML(doSomething);

Determining what makes up a Performance Analytics Dashboard

This is going to be one of those posts that seem like common sense to some people, but I recently needed to figure out which reports made up a particular performance analytics dashboard, and I didn’t find anything that jumped out at me online.

It turns out that the way to find this out is to go to the list of dashboards (pa_dashboards.list).

Then click the ‘Launch Dependancy Assessment’ ui action. This will pull up a list of tabs and the reports that are on each tab, allowing you to find out what makes up the dashboard.

ServiceNow Workflow Scratchpad (Break)

I recently had a project where I wanted to use a looping workflow that would continue around the loop until some criteria was met.

For various reasons, I was going to find out whether or not a given loop was done before I actually reached the if statement that was designed to break the execution flow out of the loop and allow the workflow to move on.

Given that, it seemed sensible to to use the scratchpad to set a variable that I could then check against when it came time to break out of the loop. That would save me having to do a GlideRecord query at the decision point to determine whether or not it was time to exit the loop.

I wrote the code, and when the workflow detected that it had gotten to the point where the loop wasn’t supposed to continue, I set “workflow.scratchpad.break = true”, at which point my workflow broke and started behaving erratically.

It’s possible that something else was happening as a result of setting the break variable to true, but as nearly as I can tell, doing that actually dumped the values in the scratchpad, leaving me with undefined instead.

I’ve done some checking to try and see if that is documented somewhere, but haven’t be able to find anything to date. It makes sense that break could end up being some kind of reserved term given its use generally inside of Java and Javascript.

For now, use workflow.scratchpad.break in your workflow at your own risk.