Solutions
Have you ever run into unexpected behavior when making inbound REST calls to your ServiceNow instance? Perhaps the result of a GET doesn’t contain all of the records you expect it to, or nothing happens when you try to modify a record.
In this post, we’ll explore some of the options available for debugging inbound REST API calls and the Business Rules / ACLs that might be impacting those calls.
ServiceNow provides a number of ways to export data from the platform. All of these methods are simple to use, but something that isn’t always obvious is how to include the Sys ID value associated with a record in the export.
Depending on how you plan to use the exported data, having the Sys ID is important. If you plan to do any kind of reconciliation or bring that data back into the platform in the future, having this value is critical.
I’ll start with the good stuff. Starting with Jakarta, SNI is supported! If you need to enable it, create a system property named glide.outbound.tls_sni.enabled and set the value to true. After you set this property, it make take up to 30 seconds for the change to take effect. If you’re using a MID server, create a MID server property with the same name and restart the MID Server.
If you don’t know what SNI is, don’t worry, you’re not alone.
The Jakarta release of ServiceNow introduces support for a new import/export data format: JSON. This blog post is a quick overview of where and how you can interact with these new features.
Export to JSON From a list of records, you can now choose JSON from the list of file formats when exporting data. Right click the header of any record list and select Export > JSON.
JSON Structure The output of this export is a simple JSON structure.
In an interesting coincidence, I recently had to solve this issue in my own Travel Tracker app (as seen on a number of Live Coding Happy Hour episodes). Just today, someone in the Developer Program asked the same thing so I thought I would document it for posterity. What happens when an incoming connection you don’t control (such as a webhook) isn’t using application/json or application/xml as the Content-Type on the HTTP transaction?
Over the weekend I ran into a problem that gave the “too many errors: 88% scanned” error in one of my Script Includes. I had to figure part of it out on my own and then lo and behold andrew.kincaid also answered it in the community yesterday.
When I presented at the inaugural ServiceNow Developer Meetup in Seattle, I did a demo of the Istanbul Script Debugger. I noted that in the application I am currently developing, almost all of the serious logic lives in Script Includes.
tl;dr If you use Stream Writers in your Scripted REST API, explicitly set the HTTP status or it won’t work the way you expect.
Muuuuch longer version This is based on a problem a coworker (and sometimes cohost) saw yesterday. He set up a Scripted REST API that returned about 200 records in a JSON object, total payload was ~36k. When loaded in the browser directly, it worked fine. Consumed via either curl or a different instance with a REST message, nothing ever moved down the wire.
In the first post in this series titled Import Series Part 1 - Getting Started with Import Sets , I set up a simple Import Set to Load and Transform Chicago Park District data into Location records.
In that post, we glossed over some big topics. In this post, we’re going to address:
Just what exactly is happening when you use the “Load Data” module? How do all of these pieces fit together?
Did you know it’s easy to give your users Unsubscribe and Manage Preferences links in your outbound emails?
This can be accomplished using two new macros available with the Istanbul release:
${NOTIF_UNSUB} ${NOTIF_PREFS} To use these macros, simply place them in the body of your notification or Email Layout.
What Users See Here’s an example of what users will see.
Clicking Unsubscribe Clicking Unsubscribe launches the user’s default email client and pre-populates the email with the information needed to unsubscribe.
The Istanbul release included the Automated Testing Framework. This is the first time that the platform itself has included any significant mechanism for automated testing. There are third party solutions such as Cerna’s CapIO but none actually included in the product until Istanbul. Let’s take a look at this framework in depth to see what it includes.
Tests: A list of all Tests cases defined on the system. A Test is basically one transaction from beginning to end and is composed of a series of Test Steps.
