Server-Side Scripting Best Practices

Overview of Server-Side Scripting Best Practices

• Make code easy to read by including comments and using whitespace and empty lines
• Use if/else statements instead of ternary operators for better readability
• Break code into modular components with specialized functions
• Construct reusable functions for similar logic
• Use descriptive variable and function names
• Store function results in a variable to reuse and avoid calling the same function multiple times
• Verify that the value of a variable exists before using it
• Return a value when creating functions
• Avoid using the Eval function due to security risks and debugging challenges
• Avoid dynamic JEXL expressions inside Jelly tags (<g2:evaluate>) as they can affect memory resources and cause performance issues

Interacting with the Database

• When using Jelly, use jelly.jvar_user_id instead of ${jvar_userid}
• Use addEncodedQuery() instead of complex gliderecord queries with multiple addQuery() and addOrCondition()
• Use GlideAggregate for efficient record counting instead of getRowCount() from GlideRecord
• Avoid complex queries on large datasets to prevent performance issues
• Utilize the database for data processing and filtering instead of client or server-side scripting
• Use self-executing functions for scripts that only need to run in a single context

Avoiding Coding Pitfalls

• Always test code in a sandbox environment before deploying to staging or production
• Avoid hard-coding values like sys_ids in scripts; use system properties and gs.getProperty instead
• Instead of dot-walking to get a reference field's sys_id, use current.getValue("caller_id")
• Use getDisplayValue() instead of getValue("field name") to avoid code changes if the display value changes

Client-Side Scripting Best Practices

• Use client scripts to validate data
• Ensure the correct script order for multiple client scripts on a table, where lower order values execute first
• Use UI policies to set field attributes like mandatory, visible, and read-only instead of client scripts
• Restrict list editing to avoid conflicts between client scripts/UI policies and list editing
• Only run necessary client scripts to avoid performance issues
• Use newValue != oldValue in onChange client scripts
• Ensure isLoading and newValue checks exist in onChange Client scripts
• Call GlideAjax only when necessary, checking values beforehand to avoid unnecessary server lookups
• Enclose code in functions to prevent variable collisions

Minimizing Server Lookups

• Use client-side data whenever possible to reduce server lookups
• Use g_scratchpad and asynchronous GlideAjax lookups to get information from the server
  • g_scratchpad is sent once when a form is loaded, while GlideAjax is triggered dynamically
• Avoid GlideRecord and g_form.getReference() callbacks due to performance impact
• When using setValue() on a reference field, include the display value to avoid synchronous Ajax calls

Client Scripting Practices to Avoid

• Avoid Global Client Scripts, as they load on every page and cause browser load delays
• Avoid DOM Manipulation, except in UI Pages and the Service Portal, and use GlideForm API instead

Business Rules Best Practices

• Ensure the when field is carefully considered when writing Business Rules
• Use Async Business Rules instead of after Business Rules if the updated values do not need to be immediately shown
• Use Conditions in Business Rules to avoid unnecessary evaluations
• Enclose code in functions to avoid variable conflicts
• Prevent Recursive Business Rules by avoiding current.update() in a Business Rule script
• Use Business Rules to double-check critical inputs
• Use Script Includes instead of Global Business Rules, as Script Includes load only when called

Debugging Best Practices

• For server-side debugging, use the debug navigation filter
• Use System Diagnostics > Debug Log to display gs.debug(), gs.info(), gs.print(), and gs.log() statements
  • gs.print() and gs.log() are unavailable in scoped applications
• System Diagnostics > Debug Business Rule displays messages about business rules
• System Security > Debug Security Rules places a debug icon on each field to display debug messages
• Use gs.debug() statements controlled by system properties for server-side debugging
• For client-side debugging, enable JavaScript Log and Field Watcher
• Use jslog() statements in client scripts and UI policy scripts
• Check the browser's console log for additional debugging information
• Disable server-side debugging before closing an update set or completing testing

Logs and Queues

• Review warnings and errors in logs and queues frequently
  • System Logs > System Log > All shows all warnings and errors
• Regularly check the size of log files via System Logs > Node Log File Download.
• Review recent log files (files with names that start with localhost_log) and search for messages that may indicate potential issues:
  • Slow evaluate
  • Slow Business Rule
  • Recursive Business Rule
  • Compiler exception
  • Warning - large table limit
  • Extremely large result
• Diagnose performance issues by reviewing the Slow SQL Statements log
• Check the ECC Queue to identify any problems with the instance or MID Server
• Reviewing Event Logs records all system events that occur within ServiceNow
• Improve overall system performance by removing unused events

Update Set and XML Data Transfer

• Use a well-defined migration process for moving changes between instances
• Create an ordered list detailing how grouped update sets should be applied
• The migration procedure should include information about any additional data or configuration changes required to accompany the update sets
• Need instructions for:
  • Activating plugins
  • Configuring system properties or other instance-specific settings
  • Setting up MID Servers and identity servers
  • Ensuring that the target table is available
• Export XML data from one instance and import it to another to migrate data
• Migrating data in an XML file saves time for unscheduled data imports since there is no need to build an import set or a transform map
• Adding a comment in the update set description is good practice so the user installing the update set is aware that an XML import is required
• Importing XML preserves data without firing business rules or updating the instance cache
• Only the selected record will be exported, not the records related to it