Here are the main technical best practices of ServiceNow for development are as follows
– Scripting Technical Best Practices
– Client Scripting Technical Best Practices
– Business Rules Technical Best Practices
– Debugging Best Practices
– Logs & Queues Best Practices
– Update Set Technical Best Practices
Scripting Technical Best Practices
High quality code results in building strong functionality in ServiceNow. The strong functionality of ServiceNow helps to ensure a good performance, reduces the chances of problems, and simplifies the debugging process.
Make Code Easy to Read
Ensure the code is easy to read and understand because others may work with it in the future.
- Comment Your Code
– Commenting should be well-written and clear to understand for developers in future.
– Keep comments as accurate as possible, this helps to understand the code clearly.
- Use White Space
– Using empty lines and spaces helps the code to be more readable.
– Spacing helps to identify the correct issues in the code.
- Write Simple Statements
– Minimizing the use of fancy tricks helps the fresh developers to understand and work on it.
Create Small, Modular Components
Breaking the code into modular components or specialized functions include the following benefits:
- easy to create because they are small and simple with limited functionality.
- They are simpler and shorter, so it is easy to understand the logic, input, and outputs.
- They are easier to test.
- Constructing the reusable functions or similar logic saves the trouble of searching through multiple blocks of similar code when a problem arises and makes code easier to maintain.
Variables
- Use Descriptive Variable and Function Names
- Use Variables to Store Function Results
- Verify Values Exist Before Using Them
- Return Values
- Avoid Dynamic JEXL Expressions in an Evaluate
- Avoid the eval Function
Interacting with the Database
- Try to avoid the complex Glide Record queries.
- Recommended to use the Glide Aggregate for Simple Record Counting.
- Avoid complex queries on large data sets
- Allowing the database to do the work
Use Self-Executing Functions
A self-executing function is defined and called at the same script field. When dealing with a script that will only need to execute in one context, for instance a transform map script, then this type of function is very useful.
Avoid Coding Pitfalls
- Using of hard-Coded Values are not recommended
- Avoid Dot-Walking to the sys_id of a Reference Field
- Use getDisplayValue effectively
Client Scripting Technical Best Practices
The following are the best practices to ensure Client Scripts work efficiently.
Client Scripting Considerations
- Using the Client Scripts to Validate Data
- Validation improves the user experience because the user finds out if there are data issues before submitting the information.
- Set Client Script Order
- Adding the baseline Order field to the Client Script form results in setting the client script order.
- Code will be executed from low to high order.
Run Only Necessary Client Scripts
Client scripts do not have a condition field which leads to onload and on change client scripts run on the load of the form. Ensure client scripts perform only necessary tasks and avoid unnecessary time-consuming scripts.
The following steps indicate to prevent the client script from running unnecessary code.
- General Cleanup
- For smooth performance it is recommended to use an asynchronous GlideAjax call instead of getReference or GlideRecord lookup.
- Keep the isLoading Check (onChange Client Scripts Only)
- Ensure isLoading check exists in onChange Client scripts results in preventing from doing a cmdb_ci lookup on every form load.
- Keep the newValue Check
- Make sure the new value check exists in onChange Client scripts.
- Add the newValue != oldValue Check
- use the newValue != oldValue check to run only when the newValue is different from oldValue in onchange client scripts.
- Bury the GlideAjax Call
- Recommended to check for the values before calling the script include, as it involves a server look up. One of the best practice to call the GlideAjax only when it’s necessary.
Enclose Code in Functions
Enclosing the code in functions helps in resulting the variables and other objects not to collide with other client scripts.
Minimize Server Lookups
– Most of the time client scripting uses the data retrieved from the server or the data available on the client.
– To restrict the time-consuming server lookups, usage of client data as high as possible is recommended, g_scratchpad, and asynchronous GlideAjax lookup are the best ways to get the information from server.
– The method “g_scratchpad” is sent once when a form is loaded and the other method “GlideAjax” is dynamically triggered when the client requests information from the server.
– To retrieve server information other methods like GlideRecord and g_form.getReference() callback are also available which are not recommended because of their performance impact.
– Ensure to include the display value with the value (sys_id) while using setValue() on a reference field.
– Setting the display value empty results in performance issues as ServiceNow will do a synchronous Ajax call to retrieve the display value of the specific record.
Client Scripting Practices to Avoid
- Avoid Global Client Scripts
- As there are no table restrictions for global client scripts there will be a load on every page which results in the process delay due to load on the browser.
- Avoid DOM Manipulation
- Usage of DOM can cause a maintainability issue when browsers are updated, one of the best practices to avoid DOM manipulation.
Business Rules Technical Best Practices
Execution of business rules happens when a record is inserted, updated, displayed or deleted and also when a table is queried.
Know When to Run Business Rules
When field on the business rule form indicates whether the script runs before or after the current object is saved to the database.
| Value | Use Case |
| display | Provides the client-side scripts with access to server-side data. |
| before | Updates the information on the current object. For example, a Business Rule containing current.state=3; would set the State field on the current record to the state with a value of 3. |
| after | Updates the information on related objects that need to be displayed immediately, such as GlideRecord queries. |
| async | Updates the information on related objects that do not need to be displayed immediately, such as calculating metrics and SLAs. |
Use Conditions in Business Rules
It is important to consider the conditions in business rules as they are evaluated before the rule is executed. If the condition is met, the script is evaluated and executed.
If the condition is not met, the system assumes that the Business Rule should be evaluated and executed for every action.
Keep Code in Functions
In business rule by default the business rule will cover the code in a function. If the code is not enclosed in a function, variables and other objects are available to all other server-side scripts.
Prevent Recursive Business Rules
Not using current.update() in a Business Rule is one of the best practices. The method can make business rules insert and update actions on the same table, which can cause the business rule repeatedly calling itself in a loop.
Use Business Rules to Double-Check Critical Input
One of the best business rule best practices is to re-verify the critical input.
Use Script Includes Instead of Global Business Rules
Basically, the global business rules don’t have any conditions or table restrictions, and they load on every page where there is no benefit. Using the script includes instead of global business rules is highly encouraged because this script includes are only loaded when they are called.
Debugging Best Practices
Debugging helps to understand the system processes by providing information, there are different debugging features which can be used in ServiceNow.
Server-side Debugging
- Debug Log
- helps to avoid switching between the record which we are trying to debug and the log output.
- Debug Log displays gs.debug(), gs.info(), gs.print() and gs.log() statements as well as server logging information and error messages at the bottom of the content frame.
- Debug Business Rule
- Indicates which business rules are running and when they are started, finished, or skipped.
- Debug business rule displays the messages about business rules and if a business rule is skipped, the failed condition is displayed.
- Debug Security Rules
- These are very helpful while using ACLs to control access to records and fields. The debug security rules have upgraded functionality, allowing to view the context parameter.
- Stop Debugging
- Disables all the debugging processes.
- Server-Side Debugging Persistence
- By activating the server-side debugging module, it will remain active until one of the following occurs:
- One should activate the stop debugging module which is located in system security.
- Users have to log out from the instance.
- If the session expires or by closing the browser.
Client-side Debugging
As server-side debug statements, jslog statements in client-side scripts will not consume disk space. To open the log viewer, navigate to the settings icon in the banner frame and select developer from the menu and turn on JavaScript Log and Field Watcher.
- Browser Debugging
- Using the browser’s console log for additional debugging information helps to speed up the development and troubleshooting processes by locating undefined objects.
Logs and Queues Best Practices
Reviewing Warnings and Errors
- To achieve the correct operation in the development process, reviewing queues and logs frequently is the best practice.
- The log results in giving severity information as
- Information
- Warning
- Error
- Debug
Checking Log File Sizes
- Sudden increase in the log file results in excessive errors, debugging may be enabled, or a new plugin may have been activated.
- Identification of increase or decrease in node log file size may cause the file to be zipped.
- Slow evaluation, slow or recursive business rule, compiler exception, warning – large table limit and extremely large result determines the root cause of the issue, such as a poorly performing script, and correct it.
Managing Queues
- Checking the Email Queue
- Selected users can be notified automatically via email of specific activities in the system, such as updates to Incidents or HR requests.
- Highly recommended to inspect the email queues to ensure email is operating properly by navigating to the system mailboxes application
- Checking the ECC Queue
- The External Communication Channel table helps to manage the MID server. The MID server is used to transfer data between ServiceNow and outside applications, data sources, or services. By checking the ECC queue regularly, potential issues with the ServiceNow instance or the MID server itself can be identified.
Managing Event Logs
- Reviewing Event Logs
- All the system events that occur within ServiceNow are stored in the events log records. Events which take a long time to process could be the result of inefficient scripts or a system error.
- Removing Unused Events
- If there is no response to the event, consider disabling the script that logs the event and removing the unused events can improve system performance.
Update Set Technical Best Practices
The effective migration process changes from one instance to another. The key document of the migration process is a document containing steps to migrate update sets, and other information not captured in the update set.
Update Set Application Order
- The order of the update sets should be applied because it is important to ensure dependencies are met.
- Creating an ordered list, details the grouped update sets in the migration procedure.
Additional Data Migration
- Additional data or configuration changes required to accompany the update sets.
- Certain items need to be updated before or after an update set is committed.
- Activating plugins, configuring system properties or other instance-specific settings, setting up MID servers and identity servers, ensuring that the target table is available are some of the procedures that need to be followed while migration happens
