Scripting in ServiceNOW

In ServiceNOW there can be scripts written at the server side or the client Side:
Server side scripting include:
  1. UI Actions
  2. Business Rules 
  3. Script Includes
Client Side Scripting include:
  1. Client Scripts
  2. UI Policies
  3. Data Policies
1. Client Script:

Client-side scripts execute within a user’s browser and are used to manage forms and form fields. Examples of things client-side scripts can do include:
  • Place the cursor in a form field on form load
  • Generate alerts, confirmations, and messages
  • Populate a form field in response to another field’s value
  • Highlight a form field
  • Validate form data
  • Modify choice list options
  • Hide/Show fields or sections

Client Scripts can be written either by accessing client scripts from the configure option on the form header or from the application navigator.
The different types that are available are
  • onLoad - The script is executed when the form is loaded
  • onCellEdit - Runs the script when we try to change any cell from list view
  • onChange - Runs the script when there is a change on specific field
  • onSubmit - Runs the script when the form is submitted
Client Scripts can be applied to only for one view and we need to specify the view to which the client script should be applied. If global is selected this script is applied to all the views.

Client Scripts can also be inherited on to other tables which extend to the table https://developer.servicenow.com/app.do#!/lp/servicenow_application_developer/app_store_learnv2_scripting_istanbul_exercise_test_client_script_types?v=istanbulon which we create the client script.

Onload and onSubmit doesnt have any parameters passed to it, but onChange has some parameters to it.

function onChange(control, oldValue, newValue, isLoading, isTemplate){
// This is mandatory to ensure that the script doesnt execute when the onChange is called on loading
      if(isLoading || newValue == '')
         return;
}

  • control: The field for which the onChange is configured
  • oldValue: Value saved in the DB. This doesnt change with the intermittent values entered.
  • newValue: The  value to which the user has changed to.
  • isLoading: boolean value to indicate the onChange is called when the form loads.
  • isTemplate: If the change is from a template.
GlideUser and GlideForm are the only two classes that we can use in the script.

GlideForm Class:
The GlideForm client-side API provides methods for managing form and form fields including methods to:
  • Retrieve a field value on a form
  • Hide a field
  • Make a field read-only
  • Write a message on a form or a field
  • Add fields to a choice list
  • Remove fields from a choice list
The GlideForm methods are accessed through the global g_form object that is only available in client-side scripts. To use methods from the GlideForm class use the syntax:
 
g_form.<method name>

To see all the method the API link is below
https://developer.servicenow.com/app.do#!/api_doc?v=istanbul&id=client





GlideUser Class:


The GlideUser API provides methods and non-method properties for finding information about the currently logged in user and their roles. The typical use cases are personalizing feedback to the user and inspecting user roles. Note that client-side validation in any web application is easily bypassed.
The GlideUser API has properties and methods to:
  • Retrieve the user’s
    • First name
    • Full name
    • Last name
    • User ID
    • User name
  • Determine if a user has a particular role assigned
The GlideUser methods and non-method properties are accessed through the global g_user object that is only available in client-side scripts. To use methods and properties from the GlideUser class use the syntax: 

g_user.<method or property name>

The g_user.userID property contains the record’s sys_id. Every record has a 32-character unique sys_id.

The GlideUser API also has methods for determining if a user has a specific role. For example:
g_user.hasRole('client_script_admin');
 
 
2. UI Policies:
 
 Like Client Scripts, UI Policies are client-side logic which governs 
form and form field behavior. Unlike Client Scripts, UI Policies do not 
always require scripting. 
 
UI Policy Actions are client-side logic in a UI Policy used to set three field attributes:
  • Mandatory
  • Visible
  • Read-only

 












ServiceNow Update Sets- How are the changes moved through different instances in ServiceNow

  1. There are three instances for a company using ServiceNow : Dev, Test and Production. The naming could vary depending on the organization.
  2. The instance URL looks something like this
    https://devXXXXX.servicenow.com is the demo instance. devXXXXX is the company name of for the organization. For Ex: -https://companynamedev.service-now.com for dev, https://companynametest.service-now.com for test etc., https://companyname.service-now.com for production.
  3. The changes in each instance are not updated automatically. A concept called update sets is used to move changes through different instances. 
  4. The tasks given to the developer are managed using Update Sets. 
  5. We can create a new update set by navigating to Local Update Sets and there is a default container. 
  6. The update are named like V1_JK_TASK
    V1- Version
    JK- Initials of the developer
    TASK- Its usually the task number given by the company.
  7.  In order for all the changes to be captured by the instance so that the changes can be migrated we need to make the update set the current update set, so that the system knows that the changes made to be saved under that particular update. Make it the current update set by clicking on the link below for the update set.
  8. To let the system know that the task is complete change the state from In Progress- Complete and click on update button.
  9.  Once the task is complete we get an Link which says Export to XML which let us download all the changes made in the from an XML file.
    Note: You get the option to export to XML will only be available when the state of the task is changed from In Progress to Complete.
  10.  Applying the change to a different instance:
    In the test environment go for Retrieved Update Sets to apply the changes made in Dev instance.
  11. Right click on the column header and click on Import XML. Choose File and the XML to be applied and upload. The State will be loaded. The update set is still not updated.
  12. Click on Preview Update Set, this is just to see if there are any errors. The state will change to Previewed. Click on Commit Update Set to complete the process.
  13. Retrieve Update Set -> Preview Update Set -> Commit Update Set. (Process)
    Loaded -> Previewed -> Commited (State of the update set)
  14. ServiceNow is developed on the platform SQL.
  15. Everything in ServiceNow is stored in Tables.
  16. Any new table created by the user there is a "u_" that is added before the name of the table.
  17. The WHO columns are by default given by the system. Its better not to mess with any of those.