ServiceNow Application Development Fundamentals: MODULE 4

Modified API's (Scoped Client Scripts)

* GlideAjax * g_form * GlideDialogWindow

Inaccessible API's (Scoped Client Scripts)

* GlideRecord * Window * Document * $(Prototype library) * $$ (Prototype library selector shortcut) * jQuery * $j (jQuery shortcut) * $F (Sizzle form element value shortcut) **The inaccessible APIs can be turned back on a per-application basis. To do this, set the system property glide.script.block.client.globals to false in the application. **GlideRecord is the only API that cannot be turned back on. **GlideAjax can be used as a replacement for GlideRecord

What's UI Policy Scripting?

*Ability to create complex conditions *Show/Hide sections *Remove/add/change/validate data in fields *Full use of JavaScript methods **UI Policy scripts execute on the client-side **Although fields can be hidden with UI Policy Actions, sections can't. SCRIPTING is REQUIRED to show/hide sections

Server-Side Scripts

*Access Control -Trigger based on operation *Business Rules -Trigger on database accesses -Insert/Update/Delete/Query -Before/After/Display/Async *Scheduled Jobs -Trigger based on a schedule *Script Actions -Trigger when events are generated *Script Includes -Trigger when called *UI Actions -Trigger by user clicks on a widget *Workflow/Flow -Trigger when workflow condition met ** Execution of server-side scripts is triggered by different things happening in SNOW **This list contains server-side script types that are commonly used in applications; other server-side script types exist.

GlideAjax

*Asynchronous request -Callback function *Client-side & a server-side components -Client-callable Script Include *Return multiple values -XML response **Use a callback function that runs asynchronously. **Note: Do not use a callback function in an onSubmit script

Field Types

*Avoid the use of free-form text fields that allow users to enter anything unless you are sure that's what you want *Use string fields when consistent or specially formatted data is not required -Don't use for dates -Don't use for fields that referenced people by name -Don't use for reference objects *Use Choice Lists and Reference Fields to limit options *Only display fields for data you need *Choose the field type carefully as changing the type can result in data loss

What's a UI Policy?

*Client-side logic governing form and field behavior *Have a condition which must be true in order to execute *Defines the behavior and visibility of fields on a form without scripting -Mandatory -Visible -Read only *UI policy actions are applied only if all of the following conditions are met: -The UI Policy is Active -The items in the Conditions field evaluate to true -The field specified in the UI policy action is present on the specified form

GlideForm

*Client-side scripting object: g_form - Properties are the fields from a form's table - Property values are field values - Contains methods for managing form fields and values *Automatically Instantiated for Client-side scripts *There are g_form methods that are specific to desktop/tablet and methods that are specific to mobile

Common data type options

*Date/time: A day and time of day, which can be selected by a calendar widget *Decimal: A number with up to two decimal places, 12.34 *Reference: A query that displays records from another table *String: A character string *True/False: A Boolean field represented by a checkbox

Logical Form Layout

*Display fields in logical groupings *Order should reflect process flow

Inclusion of Appropriate Fields and Meaningful Labels

*Don't ask for data you don't need *Use the smallest possible set of fields *Labels should clearly identify what information users should enter in the field STEPS to change field's label: 1. In Studio, open Forms & UI > Forms > <form of interest> 2. Hover over the field of interest in the Form Designer 3. Select the Settings (gear) button 4. Enter a new value in the Label field 5. Save *Keep labels short. Use the Hint, Annotation, or Helps fields for longer descriptions

Scripting in SNOW

*Enhance the user experience *Extend existing functionality or add new functionality to applications E.g.: -Place cursor in particular field on form load -Send email notifications -Write to log files -Validate data -Prompt users: alerts/confirmations/messages -Add widgets to form and lists

Client Scripts vs. UI Policies

*Execute on form load: Client Script , UI Policy *Execute on form save/submit/update: Client Script *Execute on form field value change: Client Script, UI Policy *Have access to a field's prior value: Client Script *Execute on a list field value change(s): Client Script *Execute after Client Script: UI Policy *Require Scripting: Client Script **Client-side scripts manage forms and their fields ** Client Scripts and UI Policies both execute client-side and use the SAME API.

Form Design Considerations (2)

*Forms should read from top to bottom *Important fields at the top *Reference number/name at top left *Keep side-by-side fields at the top *Use full width for large text fields *Use annotations and sections to break up long forms *Keep the form as short as possible **Do not create visually unappealing or unusable forms

Form Designer Anatomy

*Header:The header displays the table and view names for the form being edited or designed *Field Navigator: Manages the fields on a form *Views can be created, but not deleted, in the Form Designer *Available Fields: A list of fields that can be added to the form *Field Types: A list of data types that can be added to the form. Adding a field type creates a new field on the form's table when he form is saved. *Field Properties: Dictionary entry for the selected field

Annotation types are:

*Info Box Blue *Info Box Red *Line Separator *Section Details *Section Separator *Text

Adding fields to a table: Studio

*Insert a new row... adds a new Column to a Table *Provide a Column label (field name) and Type *Capitalize only the first letter of the first word in the label STEPS: 1. Open the application in Studio for editing 2. Open the table record of interest 3. Scroll to the bottom of the Table Columns related list 4. Select the Insert a new row... option 5. Enter a Column label (field name) and data type. Configure other column parameters as required 6. Save

Client Script Form Fields

*Name *Active *Global *View *UI Type (Desktop, tablet, mobile or both) *Type (onChange,onLoad, onSubmit, or onCellEdit) *Table (Form to which it applies) *Inherited *Field Name

Server-Side API

*Server-side scripts use the Server-side API *Scripts execute on the SNOW server and not in users' browsers *GlideForm and GlideUser classes are not available (part of the client-side APi) *Scripting Assistance available *Dev site for more info

What's a Client Script?

*Snow Client Scripts execute in a browser *Client Scripts manage forms and form fields in real time: - Modify choice list options - Set one field in response to another in real time - Hide/Show form sections - Display an alert - Make fields mandatory - Hide fields

UI Policy Scripting

*The Script tab appears only in the Advanced view *Select the Run scripts option to access the scripting fields *Can write a script in one or both fields

When vs. What

*Trigger specifies when to execute *Script specifies what to do

Execute if True/False (UI Policy Scripting)

*True: JavaScript that executes when the UI Policy condition tests true *False: JavaScript that executes when the UI Policy Condition tests false *UI Policy scripts execute client-side *NOTE: The Advanced view option Reverse if false must be selected in order for the Execute if false script to execute . The Execute if true script execute when the Reverse if false option is not selected. **Can be used to hide or display a section if condition is T/F

UI Policy Trigger - Default View

*UI Policies don't have a Name field; use short description field as a pseudo name *No scripting field on the Default View *UI Policy Actions and Script fields do not appear on the form until a new record is saved

UI Policy Scripting for Mobile

*UI Policy Actions execute on Mobile *UI Policy Scripts do not execute on Mobile baseline *UI Policy Scripts execute on the Mobile Platform regardless of the value in the Run scripts in UI type field. *UI Policy form is part of the Global application

Can you consolidate two fields into one?

*You are asked for an Acceptance date field and a Rejection date field *Strategy: Combine both into a single field called Decision

Can you re-title an existing field?

*You need a text field called Scenario *Your table has an unused field called Short description *Strategy: Re-label the Short description field

Helpful CSS formatting commands

*font-weight:bold; *text-decoration:underline; *font-style:italic; *text-align:center; *text-align:right; *font-size:18px; *background-color:blue' *color:yellow;

Client Scripts

*onLoad() *onSubmit() *onChange()

Browsers (Client Scripts)

Although modern browsers largely interpret JavaScript the same way, you may still observe browser-dependent behaviors in client-side scripts *E.g. if a choice list has restricted set of choices, some browsers will still display all of the options but some will be grayed out. Other browsers will not display choice list options that have been removed

Inherit (UI Policy Advanced View)

Apply this script to any extended tables when selected

To Add or Not to Add

Before creating a field, first determine if a new field is necessary. If you extended an existing table, consider using or re-purposing an existing field. Configuring the label on a field changes the label only for current table and not for the parent table(s) *Add fields to your table and not to the base table

Data Policies

Data policies enable you to enforce data consistency by setting mandatory and read-only states for fields. Data policies are similar to UI policies, but UI policies only apply to data entered on a form through the standard browser. Data policies can apply rules to all data entered into the system, including data brought in through import sets or web services and data entered through the mobile UI.

Scripting Assistance

Display a list of select-able elements in script field *ctrl-spacebar: press this to select from a list of classes *period: Type a class name followed by a period to select properties from a list *Help is displayed when you highlight a object or property.

Basic case UI Policies

Don't require scripting in order to: *Make number field read only *Make Configuration item field mandatory *Hide Priority field **Client Scripts can also hide fields, show fields, and make fields mandatory. ALWAYS use a UI Policy instead of a Client Script if you can for FASTER LOAD TIMES

Field Properties

Editing field properties makes changes to the DB *Available properties depend on data type Steps to edit properties: 1. In form layout, locate field of interest 2. Hover over the field 3. Select Edit Properties (gear) button *Changes to field properties are not committed to the DB until the Form Design is saved.

On Load (UI Policy Advanced View)

Execute on form load and form change

Inherited Field (Client Script Form)

Execute the script for forms from any extended tables when selected

Provide Real Time Feedback (Styles)

Field Styles add visual impact to a form -Field color -Font attributes (bold, italics, underline, line through etc) -Text alignment *Keep color and style selections tasteful and businesslike

Form Design Considerations

Forms are the primary way users interact with an application *Users must have a positive experience or they will be reluctant to adopt an application *Logical form layout *Field type *Inclusion of appropriate fields *Meaningful Labels *Tool tips to offer guidance *Feedback to users through message options *Effective use of color *User views for selective data display *Logical groupings of fields in Sections *Differentiation between mobile and desktop users

Removing a Field from a Form

Hover over a field to enable the Action buttons for a field -Edit properties -Remove Steps: 1. In form layout, locate field of interest 2. Hover over the field 3. Select the Delete (X) button *Removing a field removes the field from the form but does not delete the column from the table in the DB

Global Field (Client Script Form)

If selected the script applied to all Views. If the Global field is not selected you must specify the View

Active Field (Client Script Form)

If selected the script is executing in the runtime environment

Provide Real Time Feedback

Immediate and targeted feedback to users (requires scripting) -Give users feedback through client scripts and UI Action Scripts *g_form.showFieldMsg() *g_form.addInfoMessage() *g_form.addErrorMessage() *alert() *confirm()

onCondition() Function

In the appropriate UI Policy script fields is automatically called when the condition returns true or false

confirm

Is a JavaScript method that opens a dialog OK and Cancel buttons

alert

Is a JavaScript method that opens a dialog with an OK button

Description field (Scripting)

Is for documenting the script. Include information like who wrote the script, what business requirement the script is for and any other pertinent.

Condition Builder

Is not unique to UI Policies. The same filter is used in survey administration, SLAs, List Filters, Report Conditions and more. *Conditions are only re-checked if a user manually changes a field for a record on a form; if the change is made by a UI Action, Context Menu action, from an Import Set, via web services, or through List Editor, it will NOT be evaluated. *Use Data Policies, which are not scriptable, to manage the mandatory and read only state of fields for records not changed on a form

Client-Side

Manage forms and form fields: *Client Scripts *UI Policies

Server-Side

Manage the database and back-end: *Business Rules *Scheduled Jobs *Script Actions

New Fields and Forms

New fields are automatically added to the end of the form *New fields are NOT automatically added to lists. STEPS: 1. Open the list 2. Select the Personalized List gear 3. Select the columns to add 4. Arrange the Selected columns by clicking, adding, and dragging the columns 5. Select the Save button

Use Sections to Organize Fields on a Form

Organize forms into Sections *In tabbed mode (baseline), users do not see all of the fields all the time *STEPS to create a form Section: 1. In Studio, open Forms & UI > Forms > form name 2. Create a new section by selecting the + button on an existing section 3. Enter a name for the new Section ans select the OK button 4. Add fields to the new Section using the Field Navigator 5. Select the Save button **Tabs only appear when there are two or more sections.

g_form.showFieldMsg()

Prints a message on a blue background below the field passed in the method call

g_form.addInfoMessage()

Prints a message on a blue background to the top of the current form

g_form.addErrorMessage()

Prints a message on a red background to the top of the current form

SNOW API Docs

SNOW dev site contains comprehensive documentation for SNOW scripting API's: 1. developer.servicenow.com 2. Open API > Client or API > Server 3. Select a class from the navigation pane on the left 4. Select a method

Global vs. Scoped Client Scripts

Scoped client scripts execute differently than global client scripts. Scoped client scripts are wrapped in an immediately-invoked function expression (IFE). As a result, certain APIs are either modified or unavailable altogether.

onSubmit()(Client Script)

Script runs when a form meeting the trigger condition is saved, updated, or submitted *Users have no access to a form's fields while onSubmit() Client Scripts execute *onSubmit() Client Scripts are typically used to perform data validation against multiple fields simultaneously

onLoad()(Client Script)

Script runs when a form meeting the trigger conditions loads and before control is given to the user *While onLoad() Client Scripts executes, users have no ability to modify form fields *Use onLoad() to pre-populate fields with values and make other form appearance and content modifications

onChange()(Client Script)

Script runs when a particular field's value on a form changes *Use onChange() Client Scripts to validate a field's value in real time or to set or modify field values in response to another field

Client-Side vs. Server-Side

Scripts in SNOW execute either on the client (user's browser) or in the SNOW back end. It's important to know where a script will execute as there are different APIs for the client and server-side scripts

Adding a field to a form

Select a field's handle in the Fields tab and drag the field to the desired destination on the form Steps: 1. From the list of fields in the Field Navigator, select a field from the list of available fields 2. Drag the field to a location on the form

UI Policy Actions - Setting Field Attributes

Set field attributes: Mandatory, Visible, Read only STEPS: 1. In Studio, open Client Development > UI Policies and open a UI Policy for editing 2. Scroll to the UI Policy Action section 3. Select the New button 4. Configure the UI Policy Action 5. Save

View Field (Client Script Form)

Specifies the View to which the script applies. The View field is only visible when Global is not selected. A script can only act on fields that are part of the selected form View. If the View field is blank the script applies to the Default view

Benefit from extending a table

Strategy: Use existing fields with no modifications

UI Policy Trigger - Advanced View

The Advanced view has additional configuration fields *Select the Advanced view Related Link *In addition to the fields from the Default view, the Advanced view has: -Reverse if false -Global -View -On load -Inherit *If the Global option is not selected you must specify the view to which the script applies. *The View option is only visible when Global is not selected. *Select the view before writing a script. A script can only act on fields that are part of the selected form view. If you do not select Global and leave the View field blank the script applies to the default view

Form Designer Anatomy (Form Layout)

The Form Layout contains a cell for each field, section, annotation, UI element, and related list on a form *Every field is represented by a light gray rectangle. Field Labels identify each field. Fields have a handle for dragging and dropping a field anywhere on a form. *Every section is represented by a dark gray rectangle. Use the + and X buttons on the section rectangle to add or delete sections.

Global (UI Policy Advanced View)

The UI Policy applies to all views if selected

View Name

The View name appears in square brackets [] next to the form name. In the Default view no View name is displayed *All Views have a Name (name in database) and a Title (friendly, human readable name). *E.g. the Self Service View has the Name ESS but has the Title Self Service

View (UI Policy Advanced View)

The name of the view to which the script applies

Form Designer

Tool for creating and modifying forms *Add, modify, create, or delete: - Fields, Views, Sections/Tabs *Drag, drop, and configure *Three sections: -Header -Field Navigator -Form layout

Tool Tips add Guidance

Tool tips help clarify what information a user should enter *To personalize a new field's hint: 1. Open the table's form 2. Right-click on the new field and select Configure Label 3. Enter the mouse over text in the Hint field 4. Save *Keep tool tips short (one line is best). They are only visible for a few seconds.

Client Script Trigger

Trigger condition must be met for the Client Script to execute

UI Policy Trigger Conditions

UI Policies execute based on evaluation of their Condition *Build Conditions with the Condition Builder rater than scripting for better performance *If blank, the UI Policy will always execute

Reverse if false (UI Policy Advanced View)

UI Policy actions are reversed and Execute if false script executes when its UI policy's condition evaluate to false.

Adding Annotations

Use Annotations to add information, instructions, or separators to a form Steps: 1. Select the Field Types tab 2. Drag the Annotation to the appropriate location on the form 3. Select the Edit Properties (gear) button 4. Selection Annotation Type 5. Enter a value for Annotation Text. You can use HTML tags to format the annotation text 6. Select Save button

Messages field (Scripting)

Used for localization. E.g. if the script generates an alert that says Hello World, the string "Hello World" would appear in the Messages field on its own line. *If an entry exists in the sys_ui_message table with the same key but a localized language, the localized language version is presented to the user even though the script uses the version from the Messages field.

Field Name Field (Client Script Form)

Used only if the script responds to a field value change (onChange or onCellEdit); name of the field to which the script applies

Script field (Scripting)

Used to script what needs to happen when the conditions in the trigger are meet

Deleting Fields from a Table

User-defined field can be deleted by selecting the red X button that appears to the left of the Column label *Inherited fields cannot be deleted *No table records are deleted when a field is deleted STEPS: 1. Locate the field in the Table Columns list 2. Select the red X next to the Columns Label 3. Save

Views

Views are different ways at looking at the same record. A view is a saved version of a configured form or list. It defines which fields appear on the form or list and in which order. Views enable users to quickly display the same form or list in multiple ways. Administrators can create any number of views for a form or list. E.g. you might create and use different views in Incident for an ESS user, an ITIL user, and a mobile user

Script Trigger

All scripts have a trigger specifying WHEN a script's logic should execute. The trigger configuration field depend on the script type

Default List and Form

All new tables have a default list and form *For tables that extend another table, the fields on the default list and form depend on the base table fields

Views overview

Allow different users to see form data in different ways -Fields -Layout -Scripts *Users require the view_changer role to change views

Create New UI Policy (STEP 1)

1. Configure the UI Policy: *Table- table to which the UI Policy applies *Application - identifies the scope of the UI Policy. Important to correctly identify the UI Policy's scope to ensure the logic does not inadvertently impact other areas of SNOW *Active- Select the checkbox to make the UI Policy active *Short description- supply a short explanation of what the UI Policy is for. The value in this field appears in the debugging information

Open Form Designer

1. In Studio, open Forms & UI > Forms > <Form of interst> 2. If creating a new View, open any form for the same table and create a new View from within the form

Personalize a field's style

1. In studio, create a new Style 2. Configure the Table and Field name 3. If configuring a choice list for a particular value enter the value in the Value field. 4. Enter the preferred CSS style commands in the Style field.

Steps to create View

1. In the Form Design header, open the View picker and select New 2. Enter a View name 3. Select the OK button 4. Configure the new view

Steps to modify a View

1. In the Form Design header, open the View picker and select the View of Interest 2. Configure the view

Add field to form from a reference fields table

1. In the main SNOW browser window, open a table's form 2. Open the"Additional actions context menu"(trigram) menu and select Configure > Form Layout 3. Select a reference field the Available slushbucket then select the Expand selected reference field button 4. Select a field in the Available slushbucket button then select the Add button 5. Use the Up and Down buttons to place the field at the location of your choice.

Follow these steps to delete a View

1. Open System UI > Forms 2. Use filter to search for table and view 3. Open the view of interest for editing 4. Select the Delete button 5. When prompted, confirm the deletion

Create New UI Policy (STEP 2)

2. Configure the conditions under which the UI Policy runs

Create New UI Policy (STEP 3)

3. Right click the form header and select Save from context menu

Configure the UI Policy (STEP 4)

4. Configure the UI Policy Actions: *Field name- field for which the UI Policy applies an action *Mandatory- how the UI policy affects the mandatory state of the field *Visible- how the UI policy affects the visible state of the field *Read Only- how the UI policy affects the read only state of the field

Views (Applications)

Add an applications's form to existing Views: *Default *Mobile *Ess

Working with Views

Add or modify Views

Working with Sections

Add, delete or modify Sections *Sections are logical groupings of fields *A section without a title is a continutation of the last sections with a title. This allows you to combine multiple layout formats (e.g. 1 column for an annotation, 2 columns for short fields, 1 column for larger text fields) all within the same form layout area. Select the section title and remove the text

Views (Client Scripts & UI Policy scripts)

Client Scripts and UI Policy scripts can execute selectively based on Views

GlideUser

Client-side scripting object: g_user -Property/Values are information about the currently logged in user -Contains methods for checking roles for the currently logged in user *Automatically Instantiated for client-side scripts