Preventing HTTP 400 Errors From List Views

Recently I’ve come across an issue on a couple or so clients where when clicking a record from a list view, a blank page would be displayed.

While debugging, in the network developer tools I noticed that when clicking the link, ServiceNow was returning a HTTP 400 error which is why it was resulting in a blank page.

So what was causing the issue?Well turns out it was a before query business rule both times…

So on each of these clients we had very complex security rules as to what can and can’t be seen by different users. This was implemented using before query business rules so that we didn’t get the ‘Number of rows removed’ message at the bottom of the list. These before query business rules would dynamically generate the encoded query which sometimes was very long (over 1000 characters when logging down current.getEncodedQuery() ).

How did this cause the HTTP 400 error? Well when inspecting the DOM of the list view, it adds additional parameters to each of the links. So instead of a link for example being ‘incident.do?sys_id=4bc8d37a6f9c2900e14c16ff8d3ee4b4’, it would also add the query that caused it to be in that list. So if you manually add a filter on the top for active is true, the link would look more similar to:

incident.do?sys_id=4bc8d37a6f9c2900e14c16ff8d3ee4b4&sysparm_record_target=incident&sysparm_record_row=1&sysparm_record_rows=5218&sysparm_record_list=active%3Dtrue%5EORDERBYnumber

Where sysparm_record_target is the table name, sysparm_record_row is the row number selected, sysparm_record_rows is the total number of rows returned and sysparm_record_list is the query that brought us to this point.

As it turns out, if you add a before query business rule, that encoded query, even though it’s transparent to the user, is actually added to the link url in the DOM. So, when we had really complex before query business rules, those complex rules actually were being added to url.

As a (sort of) side note, these parameters are added to facilitate the up and down arrows in a record to navigate up and down the list without leaving the page.

After banging my head against a wall for ages about this, I eventually came up with two potential routes to solve the issue:

  1. Do a less complex before query business rule so the query was shorter
  2. Remove the additional parameters from the link

The first option was technically the better and more sensible approach, however the business would not (could not?) remove many of their restrictions around security for obvious reasons which left us with the second approach.

The second approach would require DOM manipulation which is generally a last resort tactic for any configuration in ServiceNow, so use with caution and check it out when upgrading.

But the solution was this. I created a global UI script which would on load, look for any long URLs and replace them with a shorter version. The downside of this approach however is that the up and down arrows would disappear, but it was the price to pay unfortunately for the security rules to be in place.

Code below:

//After the page is loaded
addLoadEvent(function () {
//check if there are any formlink classes on the page.
//This inidicates we're on a list view
var formLinks = $$('.formlink');
if (formLinks) {
var href;
formLinks.each(function (link) {
href = link.href;
//If the link is longer than 800 characters, lets shorten it
if (href.length > 800) {
//Find if it contains table.do?sys_id=1234567810
var re = /.*\.do\?sys_id=[0-9a-z]{32}/gmi;
var match = re.exec(href);
//If we find it, update the link
if (match) {
link.href = match + '';
}
}
});
}
})

Just a quick tangent, if I’m going to be honest, my ideal solution is that ServiceNow allowed for the sysparm_tiny parameter to add unlimited parameters to the system.

It already uses these in various places (have a look at sys_tiny_url table for parameters which have been shrunk down) and it could really use them on the list view.

It doesn’t work everywhere so clearly there’s some technical reasons behind it, but I would love to see the system utilise it everywhere as queries and security models are increasingly becoming more complex as the toolset grows.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s