Where scripts run in a ServiceNow transaction and the implications of using them - Support and Troubleshooting

Where scripts run in a ServiceNow transaction and the implications of using them Issue  The two primary scripting languages used in ServiceNow configuration are JavaScript and Jelly. You will also encounter HTML, CSS, XML and markup, however less frequently and at times situational to a module or plugin.

ServiceNow offers a number of different areas where you can define and execute scripts. Knowing the context and scope of how your scripts will be interpreted and executed is an important influence on designing any solution which may require some amount of scripting to achieve.

Simply put there are two contexts where JavaScript is executed by ServiceNow, the server and the client. The developer documentation already includes a good information about scripting in ServiceNow . This article collates guidelines on the different script types and summarises the implications.

The Server Side Context: Executed within the ServiceNow application server. Scripts executed here have full access to ServiceNow APIs such as: GlideSystem, GlideRecord, GlideDateTime, GlideUser etc. Scripts executed on the Server also have direct access to other configuration resources e.g. Script Includes, Global Business Rules.

Here is a TechNow video by Chuck Tomasi and Andrew Kincaid on Server Side Scripting:

Examples: Business Rules Script Actions Access control scripts Implications: Scripts executed on the Server may also have an order of execution and as such are run in the same scope. This means that each script is executed in order and objects within the script (variables, functions etc) persist from one script to the next. See: Business Rule Variables are Global

If an operation at the server relies on information submitted from the client, always check to ensure that this information is present and in the correct format by using javascript statements like try and if.

Consider running Business rules that incorporate large queries as async. This will help reduce the server time aspect of a page load.

When sending information back to the client, via GlideAjax, consider sending an object converted to JSON as the payload. The client can then decode this JSON string and immediately have access to it natively which can be iterated over or it's properties accessed without the need for manipulating strings. To do this, simply instantiate the JSON script include like so: var _JSON = new JSON(); then you can use _JSON.decode(); and _JSON.encode();

The Client Side Context: Executed by the browser. Scripts executed here have limited access to ServiceNow APIs, but instead are provided special client side objects to reduce callbacks to the Server. An example of one of these helper objects is g_user. Scripts executed on the client also have access to the page DOM and are able to access browser objects such as window and document . Scripts executed on the client also have access to other configuration resources e.g. UI Scripts. Scripts executed on the client also have access to included JavaScript frameworks e.g. Prototype and jQuery .

Here is a TechNow video by Chuck Tomasi and Andre Kincaid on Client Side Scripting.

Examples: Client Scripts UI scripts UI Policies Implications: Check out the Client Script Best Practice page before you continue.

If you want to use HTML 5 and CSS 3 features make sure you feature detect first and fall back to another standard or inform the user instead of failing silently (or not so silently).

Be aware that the client is hackable and open. Users can take advantage of code injecting browser add-ons such as grease monkey to manipulate client side code. It sounds horrible but I have seen an example of a user bypassing mandatory fields by manipulating client scripts. Because of this use ACLs as much as possible and don't rely on UI Policies or Clients scripts as your primary tool for setting mandatory/readonly fields.

While it may be tempting to utilise the full suite of DOM objects available to you, keep in mind that 99.9% of functionality required can be accessed using ServiceNow provided components. Use g_form and the attached functions instead of $() or getElementById() to get and set field properties in Client Scripts.

At all costs avoid using $(). If you absolutely must get access to DOM elements not covered by g_form use the ServiceNow call: gel() instead of $();

Because Client Side scripts are executed by the browser, it is important to make sure any DOM calls are as technology agnostic as possible. There can be huge differences in how IE, Chrome Fire Fox, Safari etc "interperate" and implement web standards.

Avoid using global UI scripts if possible. A global UI Script will be included as a resource on every single ServiceNow page. If you must use a global UI Script consider minifying the code.

If you are using a global UI Script to executing some code onLoad, consider using the document.location to limit execution to only those pages where it needs to execute.

Catch as many script errors as possible. If a Client Script creates a runtime error, this error may prevent other Client Scripts from executing resulting in a half loaded form or page.

Once a page is cached, on average the majority of ServiceNow page load times is due to Client Script execution. Consider how much time a script is adding to page loads (you can record page load statistics by using broswer plugins such as speed tracer for Chrome, firebug for FireFox and even the Client Transaction Timings plugin.

When communicating to the Server using GlideAjax, consider sending an object which has been converted to JSON as the payload instead of lots of parameters. Here is an example of this and parsing a JSON response from the Server:

//build the options object var options = { opt1: 'some string', opt2: 10, opt3: ['arr1', 'arr2', 'arr3'] };

var ga = new GlideAjax('asdf'); ga.addParam('sysparm_name', 'doSomething'); ga.addParam('sysparm_options', Object.toJSON(options));

ga.getXML(parseResponse);

function parseResponse(response) {

var answer = response.responseXML.documentElement.getAttribute("answer"); answer = answer.evalJSON(true);

for(p in answer){ alert(p + ' is a ' + typeof answer[p] + ' and equals ' + answer[p]); } }

Hybrids Context: Scripts that fall under this category have areas in their configuration where you can execute both Server and Client Side code. Generally the Server and Client code is executed in a different scope, but there are some helper APIs like g_scratchpad which allow you to transport information from the Server to the Client and vice-versa.

Examples: UI Actions Jelly Implications: UI Actions have an onClick component which will run a function specified in the script section. If the property is set, the Server Side code must be wrapped in a function and executed inside an if statement.

Related Links JavaScript Coding Standards

TechNow Scripting Series

GitHub JavaScript best practices Pragmatic Standards: JavaScript Coding Standards and Best Practices