Month: July 2020

Adding Worknotes From a Script (ServiceNow)

I recently had a need to add work notes to a bunch of old incidents (to let the users know that they had changed and why they had been changed). My first approach was just to add a record to the sys_journal_field table.

At first blush, that seemed to work, but then a co-worker pointed out that the work note was showing up in the history tab with the wrong user, and at the wrong time.

It appears that the automation responsible for populating work notes into the activities feed in the history tab didn’t like me just inserting a record into that table.

I ended up using this code, which seems to do the trick of getting the work note into the sys_journal_field table, and pushing it into the activities feed correctly as well.

incidents['work_notes'].setJournalEntry("The text you want to appear in your work note...);

Impersonating a user from a server script (ServiceNow)

I recently needed to add a bunch of work notes to old incidents, but the comments needed to show up as being posted by someone else. This worked quite handily:

var impUser = new GlideImpersonate();
impUser.impersonate('6816f79cc0a8012341c5a33be123beaa1');

The sys_id in the code will obviously need to be changed to the user in your environment that you’re wanting to impersonate.

If Statements Have Their Own Scope

I just ran into a bug that was the result of thinking that the block inside the body of an if statement had the same scope as the code outside of the if statement.

To clarify, the ‘{}’ in an if statement has its one scope, meaning that it can see the variables from the code outside of the ‘{}’, but that that exterior code is unable to see into the scope of the if statement.

Return Statements & Adding Event Listeners

I’ve been working with TCP connections lately, which means that upon connection from the client, my server needs to create a bunch of event listeners for things like .on(‘data’, and .on(‘timeout’

I also need to go through some logic to determine what I should do after connection, but before data or timeout. In my first pass, I created the event listeners towards the bottom of the .on(‘connection’ function.

That worked great until I started using return statements to change the flow inside of the .on(‘connection’ function. Once I did that, I started running into issues because the return statement resulted in the event listeners never being declared.

The lesson there for me is that I’m nearly always going to be best off setting up an event listener earlier rather than later. A niaeve concern might be that the on data listener will fire off before you get to the rest of your on connect function, but all the on data listener does is let stuff be placed on the event table, and then eventually be moved down to the event queue.

Nothing will be pulled off of the event queue though until the current function has finished running. So, you’re generally going to be just fine…unless maybe your current function is an async/await function, in which case it is possible that you’ll set up the event listeners, and then shift the function to the event table, allowing the on data listeners to fire off and get pulled onto the call stack before the original function resolves its asynchronous call and is placed back on the call stack.

Layers inside of layers, so my revised rule of thumb is to place any event listeners right after my await call. I hope that is helpful!