I mentioned on one of my past posts that I’d noticed that user criteria in ServiceNow don’t update in real time. The get checked the first time you try to look at something, and are cached at that point.

That can be problematic when you are updating a user criteria and you still seeing everything you’re not supposed to see (or not seeing something that you should be able to see) because the old version of the user criteria is still cached.

I ran into that same issue last week, and didn’t have the option of just waiting for the cache to be updated at some nebulous point in the future.

I did some looking, and found out that the cache is supposed to refresh when you log out of and then back into ServiceNow.

I tried that without any success, which meant that I was supposed to move on to clearing the cache to reset the user criteria in the user’s cache.

I knew that you could type cache.do in the filter navigator, but that only worked if you had certain rights, which the user I was supporting didn’t seem to have, so I seemed to be in a pickle.

The solution should have been much more obvious to me than it was. I just needed to use the url to trigger the cache.do call.

**service-now.com/nav_to.do?uri=%2Fcache.do

I’ve spent a week or so at this point working on a rendezvous problem based on my understanding of the course content from the Berkeley class that I mentioned in an earlier post.

I’ve got something that successfully streams, and successfully allows data to rendezvous, and successfully writes out the data at the end.

Small data sets that I can hand-check are working perfectly, but something is going wrong with larger data sets and I’m getting outputs saying that more numbers were processed than were in my data set.

It seems to be an issue with the code that writes the unmatched data from the hash table out to the unmatched data file. I’d like to continue working through it, but need to get back to the consulting work that has started stacking up, so I’m going to have to set this to one side.

However, I’m going to link to the code because I’m worried that if I don’t, that I’ll never post the result of so much time and effort.

A key takeaway for me on the project (in addition to all of the learning about how streams work in NodeJS), is that when all was said and done, it turns out that there is an “EventStream” npm module that would have probably cut a whole bunch of time out of my efforts.

I’m seeing a recurring theme in my development efforts where I end up trying to re-invent the wheel because I don’t know what resources are out there.

Some of that will probably improve through the simple passage of time, but part of my educational efforts in the future will include running through npm packages so that I in the future I’ll have an idea of what resources exist to speed my efforts up.

Also, here is a link to the post that pointed me towards the EventStream npm module:

https://itnext.io/using-node-js-to-read-really-really-large-files-pt-1-d2057fe76b33

As I was working on my self-assigned homework to write an algorithm that would stream data in, and then hold the data in memory waiting for a rendezvous to happen, I ran into an error that was new to me:

MaxListenersExceededWarning: Possible EventEmitter memory leak detected

Some research pointed me to the root cause of my issue. You should only ever define a given event listener a single time. That means you shouldn’t define an event listener in a loop, or in a function (since the function sooner or latter will end up being called more than once).

I suspect it’s more of a rookie mistake, which means it’s a little embarrassing to admit to, but if I hide my deficiencies, it just makes it that much harder to get better. Besides, maybe someone else making that ‘rookie’ mistake will stumble onto this and it will help them debug their code a bit faster than they would have managed otherwise.

Coming from a (mostly) non-computer science degree background, I’m very much aware that I have some blindspots that need to be addressed.

The other things I bring to the table as a result of a decade and a half as a professional mean that I’m still able to create a lot of value for my organization, but the more I know, the better I’ll be able to contribute.

I’ve actively been working to address those blind spots, and one of the wonderful things that I’ve learned or re-learned along the way is hash tables.

Hash tables are great because a well-designed one lets you find a key and pull out the value in O(1) complexity.

JavaScript’s implementation of hash tables is the Map object. There are a lot of algorithms where a map function is hugely helpful, including the rendevous algorithm that I’ve been working on for the last week or so.

Tonight, after spending a decent amount of time debugging a number of issues with my code so far, I realized that next issue I was up against was because I thought I was saving number keys in my map rather than string keys.

map.get() and map.delete() don’t do any kind of type coercion, so you have to be very careful that you’re comparing apples to apples between the item you’re looking for and the keys in your map.

Lesson learned!

When I was first starting out with ServiceNow, someone pointed me to the scheduled jobs when I needed to run a script on a recurring basis, and I’ve ended up using on demand scheduled jobs to test pieces of script includes I was creating.

For the most part it’s a great way to run a script on demand, but a while ago I found out that you can use fix scripts in ServiceNow to run code, and they have the astounding benefit of letting you roll back the changes from your script if things don’t go as you were expecting them to.

The next time you need to move data around using a script inside of ServiceNow, use a fix script!

Hat tip to my co-worker Kim for teaching me that.

I’m so far behind with posting blog ideas that a lot of times when I go back to my list the things that I was excited to blog about previously now seem trivial.

However trivial they may be though, there is likely someone else out there that doesn’t know them yet, so I’ll continue posting them in the hopes that someone can save half an hour debugging because they stumbled across my blog while doing a google search on the topic.

It’s possible (and easy) to create a event from inside of a script. You use gs.eventQueue()

Then you pass the name of the event, a Glide Record object, and the values for the parm 1 and parm 2 on the event.

The tricky part is that my normal method for getting a Glide Record doesn’t work. I normally do something like this:

var gr = new GlideRecord(‘sys_user’);

gr.addQuery(‘sys_id’, ”d3489ac7dbbe8c10c772f9baae9619e8′);

gr.query();

gr.next();

However, passing gr into my gs.eventQueue() call didn’t work. Instead, apparently, you have to use the gr.get() construction.

For instance:

var gr = new GlideRecord(‘sc_req_item’);

gr.get(‘d3489ac7dbbe8c10c77af9baae9619e7’);

gs.eventQueue(‘my.event’, gr, ‘869104dc1b7c7b48ubbd43b3cd4bcb53’, ‘f2b1694edb768010co72f9baae9619c3’ );

More than a year ago, I had someone recommend that I check out the video archives from Berkeley’s 2015 computer science 186 class.

I’ve spent roughly half of my free time since then doing ServiceNow consulting, but that seems to be winding down a little now, so I went out and watched the first class.

I quite enjoyed it, and have spent most of the last week since I watched the first class working through what I imagine the assignment for the class might have looked like.

I’ll post more about that once I have my algorithm working, but in the mean time, here is the link to the series:

https://archive.org/details/ucberkeley-webcast-PL-XXv-cvA_iBVK2QzAV-R7NMA1ZkaiR2y?sort=titleSorter

Here’s my solution to the Ransom Note problem found here:
https://www.hackerrank.com/challenges/ctci-ransom-note/problem

The title explicitly points out that it should be solved with a hash table. My logic is in the isViableCombination function. The checkMagazine function just formats the output the way that the test is expecting to receive it (with console.logs).

My initial expectation was that if I created a notification on a table, that the notification would be inherited by any child tables of the table where I’d defined the notification.

Upon further digging, it turns out that notifications aren’t inherited the way that business rules are, which actually makes more sense than my starting expectation.

If a child table inherited a parent’s notifications, then you’d be in a real pickle if you ever needed the child table not to inherit the parent’s notifications.

The way that it’s been coded up means that you may have to create a bunch more notifications to build the same functionality across different child tables, but that’s a better way to go than trying to figure out how to stop unwanted notifications from firing off.

**Apologies for posting this a few days late. I’ve been doing some consulting work for the last several months. It has been great experience, and the extra money has been nice, but it’s meant that a lot of other things have had to be pushed to the back burner.

My posting schedule may still be a bit erratic for a while until the consulting is done, but I’ll do my best to keep it as close to the normal schedule as possible.

On to the subject at hand:

When using a branch and join construction in a ServiceNow workflow, my first instinct is to do the branch, and then do any if activities between the branch and the join.

However, this is always the wrong answer because the workflow will hang at the join as it waits for the flow to progress down the other side of the if activity.

The correct way to go about that is to do your if activity, and then run a branch off of the yes path, and another branch off of the no path.

It means that you end up having to copy a bunch of tasks so that they are on routes off of the if activity, but that way all of the routes into the relevant join reach it and flow can continue paste the point statement rather than hanging.