One of the core principles to maintain optimal performance in ServiceNow is: Minimize round trip server calls from client scripts. Let’s explore one method of eliminating the need for such occurrences.
Client and Server?
If you’re not clear on the differences between the client and server and how interaction between the two affects the User Experience, head one post over and read my explanation, and then come back: Client vs. Server.
What’s the Problem?
As we recently discussed, the ACE Report, is very slanted against any synchronous use of functions that gather information from the server. This includes GlideRecord, GlideAjax, and getReference(). While all three of these can be used asynchronously, it’s still going to drag down the perceived User Experience if you have too many asynchronous actions running on a form. It’ll seem to your users that they’re constantly waiting on a “laggy” system to do one thing or another.
What’s the Solution?
While there are a handful of different architectural principles we can apply to reduce the number of “round trips” to the server, one of the more recent and most powerful additions is the combination of Display Business Rules and the g_scratchpad JavaScript object.
Display Business Rules
As you likely know, each Business Rule can be told when it should run:
- Before or After a record saves.
- Asynchronously (at some point in the future after the record is saved, but not immediately)
- Just before a form is Displayed
It’s the last item in that list that we are focused on today. A Display Business Rule is the colloquial name for having the server execute some code for us every time a user displays a particular form. The primary, and only, use for this that I have found so far is to make additional information to client scripts.
g_scratchpad
This JavaScript object is what allows us to pass that precious data into a client script. By setting properties on g_scratchpad from a Display Business Rule, we can then access the same object and properties from the browser.
Example
VIP User Indicator
It’s very common to have an onChange client script perform actions like highlighting the Caller field if the user is a “VIP” (typically someone with the power to fire you if they don’t like how you speak to them). While this is a great feature, it often results in a server round trip occurring, even when we we’re opening an existing ticket, and thus already know the caller before we even load the form. By implementing a Display Business Rule and g_scratchpad, we can eliminate the need for this unnecessary data transfer.
Incident – Provide VIP Status
Business Rule
Table: Incident
Advanced: True
When: Display
Condition: !current.isNewRecord()
Incident – VIP Indicator onLoad
Client Script
When: onLoad
