Most training courses and college classes on software development cover specific coding environments with one language (e.g. Java) or a set of languages (i.e. HTML, CSS, JavaScript). Each of these courses focuses on the core features, functions, and syntax of the subject system, but only lightly touch on best practices that run across the board. Even then, it’s often tilted toward the style and opinion of the instructor. Students are then left on their own to research and find the right way to perform tasks and functions, including those that are repeated throughout the development process.
When it comes to ServiceNow development, there are tons of best practices and rules for each application on the platform. Today I’m discussing my top 5 that apply across the board to enhance code maintenance and supportability.
1 - Minimize Server Calls in Client Scripts
The user’s experience in their browser is dependent upon fast load and response times. Even a couple of seconds delay can cause a user to discount the system’s value. When writing client scripts, developers can severely impact, or enhance, the user experience.
A key element is to never use GlideRecord or other direct server calls in the client script. Instead, put the server call in a script include, and use GlideAjax to perform an asynchronous call to the database that keeps your user’s browser running.
On this same vein comes the next item on my list:
2 - Business Rules’ Performance Impact on Clients
Business rules are server-side code, executed during various server calls (i.e. before, after, async, display). Whether at insert, update, delete, or query, these rules can be used to perform a multitude of useful and beneficial tasks to meet our customer’s requirements. They can also hamper performance to the client browser.
Rules set to run ‘before’ and ‘after’ an action can cause the browser to wait for a response. If the script is performing updates to other records, the additional database calls may cause the user to think the session is hung. For this reason, best practice is to never update records in another table within a ‘before’ business rule, and where possible, use ‘async’ rules to drive the load to the server with no impact to browser performance.
3 - Don’t Use “update()” in business rules
Our next best practice has to do with preventing recursion. Say you want to modify the value of another field on the same record that has just been updated. If you write a script to set the value and then add ‘current.update()’ on the end of the rule, you’ll cause some trouble.
‘Before’ business rules set values before the database operation is complete. This means if you set a value with your script, the database operation will then complete including your updated value. If your script includes ‘current.update()’ it will cause the record to save again. Additionally, everytime ‘current.update()’ is used, EVERY business rule set to run on ‘update’ will run. This could potentially lead to rules running over and over, degrading performance.
4 - Proper Prefixes and naming
When writing code, there are as many opinions on variable and parameter naming as there are developers creating them. For long-term supportability, it’s important to adhere to at least a few best practices in naming. Here are a few examples:
- GlideRecord variables should be prefixed with ‘gr’
- e.g. var grUser = new GlideRecord(‘sys_user’);
- GlideAggregate variables should be prefixed with ‘ga’
- e.g. var gaIncident = new GlideAggregate(‘incident’);
- Catalog variable names should follow the snake_case format with the first letter being lower case
- e.g. user_location
- Script Include names should be in Upper Camel Case
- e.g. MyScriptInclude or WorkflowUtils
5 - Update Set Management
This last one isn’t directly related to coding, but it does have to do with developing updates and sharing them between environments. Sometimes we work on a big project and end up with hundreds of updates. ServiceNow does not guarantee the sequence in which each update is committed, so it’s important to keep a few items in check:
- Never have multiple updates for the same item in the same or other active update sets
- Keep the update set update count to a maximum of 500 or less
- Write good descriptions for what’s in your update set
All of these ServiceNow best practices and hundreds more are encompassed in the Best Practice Engine© (BPE). Real-time code review provides guidance at the time you’re actually writing code, delivering value when you need it. Scheduled code scans provide a historical look at what’s already implemented in your environment to help highlight where your training needs may be, and to represent your technical debt for improvement. If you’re interested in improving your use of best practices, click here to view more information on how our Best Practice Engine© works and how it can drive your ServiceNow instance to success.