Just a simple script to add a YouTube like loading bar to the top of the page for AJAX Requests. Many users said they wanted a way to know when the system was “thinking”. There actually is a loading GIF in the top right (I noticed it in Fuji) but it’s a bit hard to see. This adds a very obvious loader to every page, even popups and CMS page.

Second, and this is the reason I have not been blogging much lately, I am nearly done writing my first – and I am pretty sure the world’s only -and I am certain the world’s LAST – book on Jelly in ServiceNow!

Here is a quick summary of what the book “Using Jelly in ServiceNow” contains:

Start to end walkthrough of every function with examples

Full page examples with walkthroughs

Everything from simple pages to portals and AJAX pages

Examples showing how to use Frameworks

Documentation on all Glide API Interfaces for Jelly

Full language reference

Full JavaScript Object reference

Over 200 Pages of content

During the conference I am offering pre-orders at a special price of $25. As soon as the book is ready (~Mid April or earlier) it will be delivered by email.

Any questions feel free to stop by the booth or leave a comment here! Thanks.

Uploading files is fairly easy in SN but what if you need to upload a lot of files?

There are some solutions using the AttachmentCreator service which work great but I wondered if it was possible to do it without any programming at all. So I racked my brain then I remembered a tool: cURL.

cURL is a tool used for making all sorts of web related requests. The best part about is it a command line tool so if you are in need of automating web requests this is the tool to use. Theres several versions for every OS out there and its fairly well documented.

So as a continuation to the previous article I want to expand the entire process of Coding Style with steps you can use in your own coding practices and as the basis of a Peer Code review process.

Step 0 – Installing Sublime (or another Smart Editor)

These instructions are set up for Sublime but are mostly tool agnostic as long as a similar plugin can be found. This process will take a few minutes, but it will save you so much time I don’t think you will mind. While it’s good to be aware of all the recommendations so you can use them naturally when you are coding, rely on tools as much as possible to automate code cleanup.

Grab Sublime from http://www.sublimetext.com/2 . It’s $70 for a User License, but it’s worth every penny IMO. You can evaluate it before you buy it to make sure it’s right for you.

When the Plugin window pops up start typing the name of the plugins, then press enter to install.

JSHint and JSBeautify both work on .js files, so to test create a test JS file with this content and press Ctrl+Alt+F to format it, and Ctrl+Alt+J to JSHint it. If everything is installed correctly you should get a list of errors in the script.

Step 1 – Formatting

This refers back to the last post and is the first thing I usually look for in a code review. Using JSBeautify makes this very simple, just run it, I accept most of the defaults, the only thing I might change is the indent_size setting to “4”. All plugin settings can be tweaked in Sublime by going to Preferences > Package Settings > Package Name > Settings Default. All changes should update immediately.

Step 2 – Naming Conventions

Avoiding poorly named variables, functions and records is essential to understanding code. Properly named functions and variables make the code self-documenting and eliminate the need for many comments. Here is a recap of the Coding Standards from the last article.

Variables – camelCaseFunctions – camelCasePrivateFunctions – _camelCaseClasses – InitialsAreCapitalsConstants – ALL_CAPITALSCSSClass – kebab-caseServiceNowRecords – PREFIX – Record Name(for records that don’t use the name as a file name)
For UIScripts it can be anything just no spaces.
For UIMacros I try to identify the usage like service_catalog_menu

Step 3 – JSHint Errors

JSHint will likely drive you insane with it’s complaining but it WILL make you a better coder and less dependent on JavaScript to ignore your mistakes. To run it in Sublime you must save the file as .js

It will run automatically on Save or by pressing Ctrl+Alt+J

Certain things you can ignore are issues regarding using a function before it was defined, any complaints about ServiceNow specific objects not being declared (since they are global) and the error Do Not use JSON as a constructor.

Other than those exceptions I try to, and recommend you try to, fix all errors reported. == versus === is very important to pay attention to because in MANY places === will break previously working functionality. It is still best to use === and to explicitly compare types correctly or convert objects to strings before comparing.

It is most definitely more work NOW but it will save you headaches in the long run.

Step 4 – Engineering Principles

Two Principles that I mentioned before are DRY and SOC. These should be applied when possible. It is important to understand how to properly use ServiceNow to implement these principles.

Example – Within a series of business rules the same function is repeated and changed only slightly in each business rule. The correct way to apply DRY in this case is to generalize the function so that the “tweaked” part is a parameter and then move that function to a Script Include. It may even be possible at that point to move all the Business Rules to a single rule.

Example – Several reports were created as UI Pages that use the same basic layout but with just tweaked values. In this case it may be best to either pass the parameters in the request OR to relocate the copied layout to a UI Macro and then include the macro.

Example – The same function is used within Client Scripts throughout the system. In this case moving the function to a UI Script might be the best solution so the function is available to all Client Scripts.

The other principle I try to implement is Separation of Concerns. This too goes back to understanding where all the code should be placed in ServiceNow.

Example – If styling is included directly in HTML it is best to move that to a Style Sheet record and include that sheet.

Example – When working on a custom UI Page JavaScript to manipulate the DOM and make GlideRecord queries is mixed within functions. This is definitely a bad way to do things, at the very least the code should be separated into functions whose intention is very specific. At first glance, this may seem like just extra busy work, but the inevitably the application will grow, and if code is all separated by concern, it makes it easier to understand and re-use.

These principles are not hard rules, they need to be applied with some discretion. If it is the 11th hour before a production push I would not recommend re-factoring all code into Script Includes.

Step 5 – ServiceNow Best Practices

This is a growing list of fixes or quirks within ServiceNow which just need to be memorized and looked for. This list will update as I find and create more worst practices.

Do not use current.update() in onBefore Business Rules
Limit Synchronous GlideRecord Calls
Create functions in Business Rules and call them
Avoid nesting GlideRecords deeply
Don’t hardcode values; use Constants or System Properties
GlideRecords should check for next or hasNext before using them
All variables should be declared
A function should not be longer than one screen and ideally not even remotely that large
All paths in an AbstractAJAXProcessor Script Include should return a value
To get a GlideRecord field value, always use .toString() or .getDisplayValue()

Step 6 – Documentation

For all non-generated functions, like Client Scripts, I try to generate documentation. This is not the same as comments, which should be used SPARINGLY. Documentation states exactly what a function does, what it accepts as parameters and what it returns. This is especially important in JavaScript because we don’t always know the type of parameters and returns.

To create a block like this, in your file right before a function you can type /** and enter. This will automatically look at the function and pull out its parameters and returns and create the documentation for you. I used an onChange function here for example but since they wont typically change parameters its not necessary to document each param, just the description.

If all of your code lives locally on your system, you will be able to create API documentation automatically with these blocks.

Local Files and Backup

I find it a best practice to store every file I work on locally. Typically I will create a folder structure in a directory that is backed up to a service like Box.com. The folder structure can mimic the table structure in ServiceNow, so a folder for sys_script_include, sys_script, sys_ui_script. Or using friendly names Script Includes, Business Rules and so on. Don’t get lazy here! Keeping you files organized will speed things up in the future.

So there was a request to bring back an old article on RemoteGlideRecord. I am fairly certain ServiceNow will want to deprecate this Package. I have tested the following in Eureka and it still works but I don’t know for how long. Of course, even if you use this and it gets deprecated you always have the option of another integration type.

So what is RemoteGlideRecord? It is a Package that allows you to use GlideRecord to query from one ServiceNow Instance to another. If you are interested, behind the scenes this is executing a SOAP Request and uses Basic Authentication to authenticate to the second instance.

Given that I work remotely most of the time I am quick to try new tools but very rarely does something change enough to provide a reason to change. Over the years IM, Email and Yammer have held true while Mumble, IRC and others have failed.

Well today I finally signed up for slack.com, an enterprise communication platform, and I immediately realized the awesome potential. The interface is clean and to the point but just beneath the surface are a ton of functions that either completely missing or practically unusable in other apps. File sharing and code sharing were the two that jumped out immediately. Then digging even more the integrations hooks caught my eye.

Of course this is ripe for integrating with ServiceNow so I took a stab at it. Turned out to be incredibly easy.

Here I will walk you through setting up Slack with ServiceNow.

First set up a private test channel in Slack. Then go to “+ Add a service integration”. Towards the bottom is “Incoming WebHooks”

Add an Incoming WebHook and copy the WebHook URL that was generated. Believe it or not we are already half done.

In ServiceNow create a new Outbound REST Web Message. Set the REST Endpoint to that WebHook URL and Save.

Then go to the “post” function – actually this is the only one we need so you can remove the others. In the Content field add the following:

{"text":"${text}"}

Add a REST Message Function Parameter and name it text and set the value to Hello World.

That’s it. Run a test to make sure it works and you are good to start using the integration.

Now you may want to add additional configuration, such as setting the name and channel which you can do by adding more parameters into the Content field. You can also configure these properties in Slack on the Integration details page.

Here’s an example with Username specified. Don’t forget to add the Function Parameter.

{"text":"${text}","username":"${user}"}

So that’s a basic integration. You can also build more complicated messages. Here is one setup for sending out an Incident notification.

In this, the first monthly project, I will be looking at trying to give ServiceNow the ability to automatically classify user input and suggest resolutions.

To start lets talk briefly about text classification. I will say upfront that I am no expert in natural language processing. I understand just enough to get myself in trouble. For my purpose I will be using what is known as a Naive Bayes Classifier.

A super simple explanation is that based on some given data one can predict the probable output. This is done by creating a sort of map by training the system with previous data for which the output is already known.

The data that is important for text classification is word frequency and really anything that can be expressed in terms of data can be classified this way.

The intention will be to train the system based on a user input “description” and classify that text in a couple dimensions. Possibly the type of resolution: Knowledge Base, Request, Incident and Category: Software, Hardware, Network and Topic. The resulting classification will be fed into a ServiceNow application to make suggestions and automatically resolve the users issue if possible.

Since the libraries to do the classification are too large to bring them into ServiceNow I think the best solution would be to create a WebService Integration to a NodeJS app. The integration will be able to add training data directly from ServiceNow and ask for a suggestion based on text.

The interface should accept users input and make suggestions which the user can accept or reject (and look for another solution.) This could either be from the Ticket table or possibly a custom form, like a mock chat system.

Join me for the next post in this series where I will prototype the Node Service and Integration. In the final post I will fully train the system and let end users try it.