Monday, November 21, 2022

ServiceNow Developement Guidelines & Technical Best Practices

 Update Set


Best Practice





Update set names as per below guidelines (<Developer Name>_ <Story #> _ <Description>_<Version>)

Example : David_STRY0001_IncidentImplementation_V1.0.




Each update set to have maximum of 100 updates.




Specify Update set order





Never Delete Updates, Instead Move Them to Default



Export the update set xml and keep in central repository.



Use update source to transfer the update set to destination instance.



Promote Changes after working hours or on Weekends




CMDB Best Practice :


Best Practice



CI Name must be unique and that doesn’t change over time.CI name should be unique so it can be differentiated from other CI’s and it must not change so the CI can be tracked over time.




It is bad idea to use an IP or MAC address as CI name since this may change easily over time.





CI Must have relationship




CI’s and Assets are related but they are not same.



Don’t create CI’s for things you cant configure or monitor. CMDB is there to help you deliver digital services it isn’t a data centre.





End User form related best practices



Best Practice




All fields in end user related forms have to be prefilled with existing and relevant information. The rule is that the end user should not enter information which is available in ServiceNow tables.






Best Practice




Peer review to randomly check if code is committed to right domain.




Any OOB code was modified. Avoid this.




Notification should be global domain unless it’s for a specific customer. In this case, the condition should be set appropriately.





Workflows must be in global domain. If this is Customer specific workflow then Company should be used in condition builder.



Groups should be created in global domain. Together with setup of roles necessary for a group, Visibility to particular customer domains should be specified (Visibility Domains related list on Group form).



Manual Activity


Best Practice




Data import, like initial import of domains, Users, Configuration Items, Groups etc.




Domain records to be migrated to destination instance before everything else.




Referenced tables should be imported before rest of the tables.





System properties which are specific for the instance or can be different on other instances, like debug level of scripts, integrations related settings (soap endpoints etc.)/properties



Referenced tables should be imported before rest of the tables.





Best Practice




Each logging entry should be easily assignable to responsible code (i.e. script name prefix)




„Non Error Loggings“ (debug messages) must be switched off or commented when a new functionality is completed, just to avoid unneeded log entries on target (non- development) instances




On CAT and PROD systems only error loggings are permitted. Other loggings have to be discussed with the system architects.





System performance

Performance critical tasks like mass data loading must be coordinated with administration of the instance (Global Team on DEV)



Business Rules Best Practices



Best Practice




Prevent Recursive Business Rules(Do not use current.update() in a Business Rule script)




Enclose Code in Functions




Use Script Includes Instead of Global Business Rules




Use Conditions in Business Rules





Client Script Best Practices



Best Practice




Restrict List Editing - If UI Policies or Client    Scripts are used




Minimize Server Lookups Userg_scratchpad, Async GlideAjax & getReference




Use UI Policies Instead of Client Scripts





Avoid Global Client Scripts



Avoid DOM Manipulation



Enclose Code in Functions



Run Only Necessary Scripts - use appropriate 'if' conditions



Add the isLoading Check (onChange Scripts Only)



Add the newValue Check



Add the newValue != oldValue check



Bury the GlideAjax Call



Coding Best Practices



Best Practice




Make code Easy to Read.



Use Descriptive Variable and Function Names-Meaningful names for functions and variables better indicate readers the purpose of code.



Construct reusable functions-This improves the quality of code, saves you the trouble of searching through multiple blocks of similar code when problem arises and makes code easier to maintain.



Use variables to Store Function Results.



Use immediately Invoked Function Expressions-This is used to run the script in a single context such as a transform map script.



Avoid Complex GlideRecord Queries.



Do not Use Hard-Coded values in scripts,they can lead to unpredictable results and can be difficult to track down later.



Avoid Dot-Walking to the sys_id of a reference field.



Avoid Complex Queries on Large Data Sets.



Avoid Dynamic JEXL Expressions in an Evaluate.



Commenting Your Work



Best Practice




Comment your code that will be useful to anyone who needs to update the script later.




Make Comments Helpful by clearly describing the purpose of functions and all inputs and outputs.




Add Descriptions to Records that will help to understand the contents of a record.





Exporting and Importing XML Files



Best Practice




Exporting a Single Record is often useful.




Exporting Multiple Records.




Import Records as XML Data.





Update Sets Best Practices



Best Practice




Follow Update Source Requirements-Create only one update source record per instance source to avoid transfer errors.



Define naming Standards-This makes it easy to coordinate changes from multiple developers or when applying changes from one instance to another one.



Provide Helpful Descriptions.



Organize Update Sets-Create Update sets based on process,stream,or application.This allows changes to be promoted and tested within the same release or sprint with minimal conflict.



Merge Update Sets-This reduces the number of times you have to preview and commit update sets.



Clean Up Previously Merged Update Sets.



Remove Debugging Code.



Ensure Updates Are Instance Independent.



Debugging Tools Best Practices



Best Practice




Debugging can provide information to help you understand system processes.



Debug Log helps you avoid alternating between the record you are trying to debug and the log output.



Debug Business Rule displays messages that indicate which business rules are being run and when they are started.



Debug Security Rules places a debug icon to see if there are any messages for the associated element.



Stop Debugging disables all debugging processes.



Recommended way to debug server-side scripts is to use gs.print statements controlled by system properties.



Check the browser's console log for additional debugging information.

These logs can help spped up development and troubleshooting processes by locating undefined objects.



Before closing update set or complete testing of the production instance,be sure to disable all server-side debugging to save log space in production.



Import Set Performance Best Practices



Best Practice




Avoid running business rules during a transform unless you want all insert and update business rules, notifications and workflows to run.



Avoid writing complicated scripts that use Glide Record queries. Use base system functionality whenever possible instead of writing custom scripts.



On import set tables with large amounts of data being processes, limit the number of transform maps to 1.



For a JDBC import, use the Use last run date time option in your import set Data Source. For a File type import, be sure that whatever is generating your files is only adding data that is new, or has been changed.



Coalesce on a unique field and a field that is already indexed.



Stagger your imports so they do not overlap.



Verify the Import Set Deleter job is running. If the import sets are not cleaned on a regular basis the table fills causing imports to stop.



Truncate the import table before importing with a new column.



Break a very large data set into multiple,smaller for faster results.








Logs and Queues Best Practices



Best Practice




Review queues and logs frequently throughout the development process to ensure correct operation. Waiting until development is complete makes diagnosis and correction more difficult.



Diagnose potential performance issues by reviewing the Slow SQL Statements.



Check the size of log files regularly. If a log file you have been checking suddenly increases in size, there may be excessive errors, debugging may be enabled, or a new plugin may have been activated.



View Log detail and search for messages which may indicate potential issues, determine the root cause of the issue, such as poorly performing script, and correct it.



Periodic review of the External Communication Channel can help determine if problems exist with the instance or MID Server.



Periodically review the events log to determine which events are taking longest to process.



Remove unused events this can improve overall system performance.



Patches Best Practices



Best Practice




Create Plan to Validate Critical Functionality.



Before patching production instances, patch and validate sub-production instances.











Web Service Integrations Best Practices



Best Practice




Client Connection Setting Recommendations should be taken care of to ensure acceptable performance.



It's recommended that whenever a SOAP Request is executed, that you evaluate if it is necessary to get an instant response back.



Enable compression of HTTP messages. This is the default behavior with the latest, robust SOAP libraries, but make sure to verify it.



Test new applications carefully.

 1. Examine wire-level traffic for anomalies and to verify correct and efficient behavior.

  2. Test with large datasets of the kind that will be encountered in production, rather than relatively tiny test data sets.



Use Version-Specific REST APIs.



After upgrading, pull new WSDLs using any client applications that access the instance through SOAP and rebuild the stubs. This action updates the client application to use the upgraded WSDL.



ODBC Best Practices



Best Practice




Perform SOAP Load Testing.



Avoid using joins as they can impact performance.



Use WHERE Clauses in Queries Efficiently.



Consistent Use of Time zones in Queries-It is important to ensure that both the client and users be set to the same time zone in order to avoid time lapses.



Avoid views that reference themselves. This can cause the queries to loop and create stack overflows.



Avoid Number Precision Errors.



Avoid Select Top N Statements. This may impact instance performance.



Avoid using the dateadd and datediff statements when the result cannot be transformed to a literal value in the where clause.



Establish a connection to the instance before performing any queries and reuse this connection for all of the queries.



System Performance Best Practices



Best Practice




Monitor Response Times to maintain good performance levels on the application server.



Remove unused inactivity monitors as they can produce large numbers of unanswered events can adversely impact the performance of the event processing engine.



Adjust the Auto-Complete Wait Time.



Check the SLA Trace level, it controls the number of messages sent to the system log.



Monitor the processing duration of Scheduled Jobs to keep track of system performance and to screen for issues.



Avoid modifying the default system User Preference named rowcount as it will slow down list viewing and has the potential to become a scalability and performance issue.



Configure the Browser to accept compressed data from an application server to speed the performance.



System Properties Best Practices



Best Practice




Define a Naming Convention for System Properties. This makes it easier to filter lists of properties.



Create New Properties and then add related properties to categories.



Create Properties Page this makes it easy to access system properties.



Use Properties in Server-Side Scripts, properties make it easy to change the behaviour of the system.



No comments:

Post a Comment