Tech Tips

Browser Console

Browser Console

When working on ServiceNow portal widgets, etc, it can be useful to write out information to the browser’s console log.

You can display the browser console by pressing F12 but, as you’ll notice, the console is a bit noisy. Writing information to the console is useful, but it can be difficult to spot the exact information you’re looking for.

There are a number of console commands, but in this article we’ll only focus on the log action and how that can be used to simplify debugging a service portal widget in ServiceNow.

In javascript, all that’s needed to write to the log is…

console.log('this is important information')

But try finding that in your log when the log extends for a few pages.

There are a couple of tricks to simplify this, one is to add a dash of color.

console.log('%cthis is important information','color:red')

You can even add different colors to highlight different pieces of information by adding multiple styling breaks.

var thisObject = {'name':'John Smith', 'address':'123 Eagle St', 'company':'JDS Australia', 'occupation':'ServiceNow consultant'}

for (var thisField in thisObject){
console.log('%c' + thisField + ' = %c' + thisObject[thisField], 'color:green', 'color:red');
}

As you can see, it’s very easy to find the debugging information we’re looking for, but there’s one other tip that might come in handy and that’s using the console filter.

At the top of the console log there’s a filter that can allow you to isolate exactly what you’re looking for, allowing you to remove all the noise.

If we add a unique preface to all our log statements, we can then filter on that to see only the information that’s important to us. In this example, we’ll use a double colon (highlighted in yellow in the image below).

console.log('%c::this is important information','color:red');
var thisObject = {'name':'John Smith', 'address':'123 Eagle St', 'company':'JDS Australia', 'occupation':'ServiceNow consultant'}

for (var thisField in thisObject){
console.log('%c::' + thisField + ' = %c' + thisObject[thisField],'color:green','color:red');
}

The console log is a useful way of streamlining portal development so use it to the fullest by filtering and/or coloring your inputs so you can debug your widgets with ease.

Conclusion

It doesn't need to be complicated! Reach out to us and we can help you.

Our team on the case

Document as you go.

Peter Cawdron

Consultant

Length of Time at JDS

5 years

Skills

ServiceNow, Loadrunner, HP BSM, Splunk.

Workplace Passion

I enjoy working with the new AngularJS portal in ServiceNow.

Our ServiceNow stories

Posted by Jillian Hunter in ServiceNow, Tech Tips, 0 comments
Glide Variables

Glide Variables

ServiceNow uses a special type of super flexible variable to store information in what appears like a single field, but is actually a complex storage/management system with a database column type called glide_var.

As each record can have a different number of variables stored as key/value pairs, there’s no easy way of dot-walking to the name of the variable within the glide_var as the names can change from record to record within the same table! You can, however, detect and retrieve variables from a glide_var by treating the gliderecord field as an object.

In this example, from an automated test framework step, you can see each of the variables and their values from the database glide_var column inputs.

var gr = new GlideRecord('the table you are looking at')
gr.get('sys_id of the record you are looking at')

for(var eachVariable in gr.inputs){
gs.info(eachVariable + ' : ' + gr.inputs[eachVariable])
}

If you run this in a background script you’ll see precisely which variables exist and what their values are.

Conclusion

It doesn't need to be complicated! Reach out to us and we can help you.

Our team on the case

Document as you go.

Peter Cawdron

Consultant

Length of Time at JDS

5 years

Skills

ServiceNow, Loadrunner, HP BSM, Splunk.

Workplace Passion

I enjoy working with the new AngularJS portal in ServiceNow.

Our ServiceNow stories

Posted by Jillian Hunter in ServiceNow, Tech Tips, 0 comments
Understanding Database Indexes in ServiceNow

Understanding Database Indexes in ServiceNow

ServiceNow uses the MySQL database to manage its information, so whenever users are looking at a list of records they’re looking at the results of a database query.

Like all databases, MySQL is designed to handle large volumes of information in the most efficient manner possible. To do this, MySQL has a concept known as indexes. These work very much like the index in the back of a book. Instead of flipping through every page looking for something, a quick trip to the index can let you find all the references for a subject in one spot. In the same way, table indexes increase the speed of database queries.

Real world example

Here’s a real world example of a user waiting upwards of a hundred seconds for the following query on a table with 200,000 rows.

On investigation, it became apparent that there was a database index that should cover this scenario, but it wasn’t being automatically picked up by ServiceNow because of the way indexes work.

Indexes are ONLY used if the columns within them are used seqentially, and this is an important point to understand.

Understanding index order

It doesn’t matter which order the columns are used within the query itself, but they MUST occur based on the order in which they have been put into the index as read from left to right. For example, when it comes to this particular index, the following holds true.

Also, it’s important to note that key columns (like Assignment Group) probably occur in several indexes, so just because this particular index isn’t used doesn’t mean no index will be used. Another index might pick up where this one leaves off.

When a query or report is run, the database engine will examine all the indexes on the table to determine which is most efficient index to use.

All the reference fields used in ServiceNow have an index applied to them, but these aren’t always the most efficient way to query the database. For example, consider these two indexes.

  1. Assigned To, Active
  2. Active, Assignment Group, Assigned To, Number

The first index is the default index for the Assigned To column as a reference field. Although it filters on Active, that is only applied AFTER the Assigned To.

The second index is the one we’re examining, but it can only be used if Assignment Group is also used (following the order of the index from left to right).

If you have a table with a million rows but only 20,000 of them are active, then which of these approaches will be more effective?

a) Select EVERY entry assigned to a person and only then filter on active records
b) Select ONLY active records and then filter on that person

As 98% of the records are inactive, option (b) will produce the best results as it will completely ignore 980,000 records before it starts filtering by name.

So in this case, querying by Active, Assignment Group and Assigned To will be considerably quicker than querying by Assigned To and then Active.

Going back to our real world example, we can see that our index is NOT being used because the very first column in the index hasn’t been included so none of the other parts of the index are being applied. By adding Active we’ll bring this index into play.

And the results?

We’ve gone from 100 seconds down to less than one second!

In this particular case, the results were exactly the same as this person was only actually interested in active records anyway but forgot to include Active in their query, but what if we wanted both active and inactive results? Ah, this is where it gets interesting…

Again, by including Active we’re allowing the MySQL database to use this index and improve performance, and look at the results.

Rather than waiting almost two minutes, we have our results in under a second.

In theory, this query is now exactly the same as the original (which didn’t specify whether a record was active or not) and yet look at how much faster it is because the database can use this index.

Also, it’s interesting to note, that in the absence of this index, the database would have used index (2) above, but because active was applied second it was grossly inefficient.

Trying this same approach on a table with 2.7 million rows, retrieving ALL the rows (with no query) took 21 seconds. Using the seemingly counterintuitive approach of "active=true or active = false" consistently reduced that to 13 seconds, and still returned all 2.7 million rows! That’s a reduction of 40% in the query time!

JDS doesn’t recommend using this "active=true or active=false" query. It’s included only as an example to help make the point. All list views should have a query behind them, and those queries should be based on the underlying database indexes.

The lessons from this are...

  • Don’t underestimate the importance of your database indexes.
  • Be sure to conduct an audit of your commonly used application modules and slow running transactions to make sure the queries in them leverage database indexes properly.

Find out more

To learn more about how JDS can optimize the performance of ServiceNow, contact our team today on 1300 780 432, or email contactus@jds.net.au.

Our team on the case

Document as you go.

Peter Cawdron

Consultant

Length of Time at JDS

5 years

Skills

ServiceNow, Loadrunner, HP BSM, Splunk.

Workplace Passion

I enjoy working with the new AngularJS portal in ServiceNow.

Our ServiceNow stories

Posted by Jillian Hunter in ServiceNow, Tech Tips, 0 comments
What’s new in LoadRunner 12.02

What’s new in LoadRunner 12.02

HP recently released LoadRunner 12.02 and here at JDS, we have had first hand look at what HP has to offer in this new release. Many new and interesting features were introduced as part of this release, with a new feature called Web Controller available for non-production testing included. Here is a brief summary and initial thoughts of the new release.

Web Controller

  • Must run separately from the desktop Controller.
  • Currently not released for Production. Released as part of a Preview Project.
  • HP has gone with a much cleaner, white themed look for the Scenario Set Up in the Web Controller and have also removed a few options which are available in the desktop Controller
  • Removed these options in Scenario Schedule:
    • Schedule by: Scenario
    • Run Mode: Real- world Schedule
  • Scenario Schedule is now replaced by:
    • Schedule By Test
    • Schedule By Script

WebController

Noise Testing

  • The noise test performs basic load testing without an actual business process. The approach of this test scenario is to create heavy load on the server by having the same URL accessed simultaneously by a large number of virtual users.
  • 1 web Vuser license can instead be used for for 10 “noise” Vusers.
  • A noise testing scenario can be set up with a standard Vugen script load scenario. One scenario will contain standard Vusers and the other will have noise generator type Vusers.
  • “noise_” prefix will be automatically added to the group name in the scenario groups. This helps with distinguishing the different group tests.
  • Make sure that either the “Define each actions as a transaction” or Define each step as a transaction” is selected in the Run-time settings.

NoiseTest

Vugen

  • Run Time Settings now appears in a Tab instead of a separate window. This will allow easier access to multiple run time settings for multiple scripts.
  • Traffic filtering is now possible before/after recording. This means you can record a script, and then regenerate to exclude Google analytics etc. Might be a useful alternative to creating a blacklist of servers as was the previous way to achieve this.
  • Updates to the way TruClient identifies objects. The enhancement is in the Descriptor Editor where the user selects attributes to identify the object by. This does not require the use of XPath as with previous versions.
  • New JSON view in snapshot pane, for HTTP requests and responses with an application/json content type.
  • Proxy recording for Java over HTTP, Oracle NCA, and Oracle – Web protocols
  • Large scripts with multiple correlations can be easily handled

Vugen

Analysis

  • Analysis can now support much larger results files without consuming all the system resources. Good news for analysing soak results with lots of transactions / monitoring stats.

Protocol Enhancements

  • Support for latest versions of XenDesktop, and NetScaler Access Gateway.
  • TLS1.1 and TLS1.2 are now supported
  • RTE has Win 8.1, Windows 2012 R2, and IPv6 support.
  • Support for SOAP 1.2
  • Support for latest versions of Flex and GraniteDS

Tech tips from JDS

Posted by Lionel Lim in ServiceNow, Tech Tips, 0 comments