Update Set
Best Practice |
Compliance(Yes/No/NA) |
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 |
Compliance(Yes/No/NA) |
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 |
Compliance(Yes/No/NA) |
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. |
|
Domain
Best Practice |
Compliance(Yes/No/NA) |
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 |
Compliance(Yes/No/NA) |
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. |
|
Logging
Best Practice |
Compliance(Yes/No/NA) |
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 |
Compliance(Yes/No/NA) |
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 |
Compliance(Yes/No/NA) |
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 |
Compliance(Yes/No/NA) |
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 |
Compliance(Yes/No/NA) |
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 |
Compliance(Yes/No/NA) |
Exporting a Single
Record is often useful. |
|
Exporting Multiple
Records. |
|
Import Records as
XML Data. |
|
Update Sets Best Practices
Best Practice |
Compliance(Yes/No/NA) |
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 |
Compliance(Yes/No/NA) |
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 |
Compliance(Yes/No/NA) |
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 |
Compliance(Yes/No/NA) |
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 |
Compliance(Yes/No/NA) |
Create Plan to
Validate Critical Functionality. |
|
Before patching
production instances, patch and validate sub-production instances. |
|
Web Service Integrations Best Practices
Best Practice |
Compliance(Yes/No/NA) |
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 |
Compliance(Yes/No/NA) |
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 |
Compliance(Yes/No/NA) |
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 |
Compliance(Yes/No/NA) |
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