Understanding ServiceNow Data Access Methods and GlideAjax Implementation Challenges

Introduction

Modern enterprise applications demand robust and efficient data handling mechanisms. ServiceNow, as a leading enterprise platform, provides various methods for accessing and manipulating data across its ecosystem. This technical documentation explores these methods in depth, with particular focus on GlideAjax implementations in Catalog Client Scripts and Record Producers. We'll examine common challenges, architectural considerations, and implementation strategies that ensure reliable data transfer between client and server components.

Understanding ServiceNow's Data Access Architecture

ServiceNow's data access architecture is built on a multi-layered approach, providing different methods of data interaction depending on the context and requirements. Each layer serves specific purposes and comes with its own set of considerations.

ServiceNow Data Access Methods

1. GlideRecord API

• What it is: GlideRecord is a server-side JavaScript API in ServiceNow. It is the primary and most fundamental way to interact with the ServiceNow database from server-side scripts. Think of it as your "database query object" within ServiceNow scripting.

What it's used for: GlideRecord is used for performing CRUD (Create, Read, Update, Delete) operations on ServiceNow tables. This means you can:

Where it's used

GlideRecord is exclusively used in server-side scripts. This includes:

• Script Includes: For reusable server-side logic.
• Business Rules: To execute scripts before/after database operations or display actions.
• Workflows: To automate processes and interact with records.
• Scheduled Jobs: To run scripts at scheduled intervals.
• Server-side GlideAjax: In the server-side script include handling AJAX requests.
• Transform Maps (onBefore/onAfter scripts): When importing data.
• Inbound Email Actions (Scripts): When processing incoming emails.

var gr = new GlideRecord('sys_user');
gr.get('sys_id_value');  // Direct access
        

The most straightforward method for server-side record access. Ideal for:

• Direct record retrieval
• Complex queries
• Record operations (insert/update/delete)

2. GlideElement

• What it is: GlideElement is a server-side JavaScript API in ServiceNow. It represents a single field of a GlideRecord object. When you iterate through records using gr.next() in a GlideRecord query, gr.fieldName (e.g., gr.short_description) returns a GlideElement object for that specific field on the current record.
• What it's used for: GlideElement provides methods to work with individual field values of a record retrieved by GlideRecord. It's primarily used to:

• Get field values: Retrieve the value of a field in different formats (display value, actual value, etc.).
• Set field values: Change the value of a field (though you typically set values directly on the GlideRecord object like gr.short_description = '...').
• Get field metadata: Access information about the field itself, such as its type, label, or choice list.
• Where it's used: GlideElement is also server-side and is always used in conjunction with GlideRecord. You get GlideElement objects when you access fields of a GlideRecord object.

// Accessing field values
current.field_name;
current.reference_field.field_name;  // Dot-walking

var gr = new GlideRecord('incident');
if (gr.get('sys_id', 'your_incident_sys_id')) {
    var shortDescriptionElement = gr.short_description; // shortDescriptionElement is a GlideElement object        

Used for:

• Field value access
• Reference field traversal
• Field metadata operations

3. g_form Client API

• What it is: g_form is a client-side JavaScript API in ServiceNow. It provides methods to interact with and manipulate forms that are currently displayed in the user's browser.
• What it's used for: g_form is used in client-side scripts (primarily Client Scripts and UI Policies) to:
• Get and Set Field Values on the Form: Retrieve the current value of a field from the form and set the value of a field.
• Control Form Display: Hide/show fields, make fields read-only/editable, make fields mandatory/optional.
• Add/Remove Form Messages: Display informational, warning, or error messages on the form.
• Submit or Cancel the Form: Trigger form submission or cancel form actions.
• Get User and Session Information: Access information about the current user and session.
• Make Asynchronous Calls to Server-Side (GlideAjax): Initiate GlideAjax calls to server-side Script Includes to fetch or process data without reloading the entire page.

Where it's used: g_form is used in client-side scripts only. The most common types are:

• Client Scripts: Scripts that execute in the user's browser based on events on the form (e.g., onChange, onSubmit, onLoad).
• UI Policies (Execute client script: true): UI Policies can execute client-side JavaScript to dynamically control form behavior.
• Catalog Client Scripts (Service Catalog): Client scripts specifically for catalog items and record producers.

// Client Side

g_form.getValue('field_name');
g_form.setValue('field_name', value);

// Client Script (e.g., onChange Client Script on 'category' field)
function onChange(control, oldValue, newValue, isLoading, isTemplate) {
    if (newValue == 'Software') {
        g_form.setValue('assignment_group', 'Software Support'); // Set 'assignment_group' field value
    } else {
        g_form.clearValue('assignment_group'); // Clear 'assignment_group' field value
    }
}

// Getting field value
var categoryValue = g_form.getValue('category');
gs.log('Category selected: ' + categoryValue); // gs.log in client-side scripts logs to the browser console        

Client-side form manipulation for:

• Form field access
• Value setting
• Field property manipulation

GlideAjax: Bridge Between Client and Server

GlideAjax acts as the communication channel or bridge that allows client-side JavaScript to reach across to the server-side and:

1. Send a request from the client-side to the server-side. This request specifies what server-side script (specifically a function in a Script Include) needs to be executed and can also include parameters.
2. Execute a server-side Script Include function. This function, running on the server, can use server-side APIs like GlideRecord to access the database, perform calculations, enforce business rules, etc.
3. Return data or a result from the server-side back to the client-side. The server-side function can return data (often in JSON format) or a simple value back to the client.
4. Process the response on the client-side. The client-side JavaScript receives the response and can then use it to update the form, display messages, or perform other actions in the user's browser.

// Server-side (Script Include)
var UserDataHandler = Class.create();
UserDataHandler.prototype = Object.extendsObject(AbstractAjaxProcessor, {
    getUserData: function() {
        // Server processing
        return result;
    }
});

// Client-side
var ga = new GlideAjax('UserDataHandler');
ga.addParam('sysparm_name', 'getUserData');
ga.getXMLAnswer(function(answer) {
    // Handle response
});        

"Blink of an Eye" Speed and Client-Side Updates:

GlideAjax Speed , The "blink of an eye" speed with GlideAjax is achieved because:

• Direct Function Call: The client script directly calls a specific, often optimized, function in a Script Include.
• Minimal Overhead: GlideAjax is designed for this type of quick client-server exchange, minimizing overhead.
• Targeted Operations: Script Include functions called by GlideAjax are usually written to perform a specific, focused task (e.g., data lookup, simple calculation) efficiently.
• Asynchronous Nature (Non-Blocking UI): The asynchronous nature of GlideAjax prevents the browser from freezing while waiting for the server response, making the UI seem responsive even if there's a slight delay.

Common GlideAjax Challenges and Solutions

1. Data Packaging Issues

Problem:1. String Concatenation Method (Problematic)

var UserDataFetcher = Class.create();
UserDataFetcher.prototype = Object.extendsObject(AbstractAjaxProcessor, {
    getUserData: function() {
        var grUser = new GlideRecord('sys_user');
        if(grUser.get(this.getParameter('sysparm_user_id'))) {
            // Problematic: Concatenating multiple values into a string
            return grUser.first_name + '|' + 
                   grUser.title + '|' + 
                   grUser.location.name + '|' + 
                   grUser.department.name;
        }
        return '';
    }
});        

Technical Challenges in String Concatenation

1.Parsing Architecture Limitations

The delimiter-based parsing approach introduces several technical constraints:

1. Data Integrity RisksDelimiter collision possibilitiesNull value handling complicationsType information loss during transmission
2. Maintenance ComplexityIndex-dependent data accessOrder-sensitive implementationLimited debugging capabilities

2. System Performance Impact

String concatenation operations affect system performance through:

1. Memory ManagementString immutability overheadTemporary object creationGarbage collection impact
2. Processing OverheadMultiple concatenation operationsParsing computation requirementsType conversion processing

Why is it called "Problematic" rather than "Wrong"?

It's "problematic" because it works functionally in simple cases. You can get the data to the client using this method. However, it's not the best practice or the most robust, maintainable, or scalable approach, especially when dealing with structured data in web development scenarios like AJAX communication.

Structured Solution Approach

Properly Structured Script Include

The Better Alternative: Using Structured Data (JSON - JavaScript Object Notation):

The preferred and best practice approach in ServiceNow and modern web development for sending data from server-side scripts to client-side scripts (especially via AJAX) is to use JSON (JavaScript Object Notation).

var UserDataFetcher = Class.create();
UserDataFetcher.prototype = Object.extendsObject(AbstractAjaxProcessor, {
    getUserData: function() {
        try {
            var userSysId = this.getParameter('sysparm_user_id');
            
            if (!userSysId) {
                return this._createResponse('error', null, 'No user ID provided');
            }

            var grUser = new GlideRecord('sys_user');
            if (!grUser.get(userSysId)) {
                return this._createResponse('error', null, 'User not found');
            }

            // Structured data object
            var userData = {
                personal: {
                    first_name: this._getFieldValue(grUser, 'first_name'),
                    last_name: this._getFieldValue(grUser, 'last_name'),
                    title: this._getFieldValue(grUser, 'title')
                },
                organizational: {
                    department: this._getReferenceValue(grUser, 'department', 'name'),
                    location: this._getReferenceValue(grUser, 'location', 'name'),
                    manager: this._getReferenceValue(grUser, 'manager', 'name')
                },
                system: {
                    active: this._getFieldValue(grUser, 'active'),
                    created: this._getFieldValue(grUser, 'sys_created_on')
                }
            };

            return this._createResponse('success', userData, null);

        } catch (ex) {
            return this._createResponse('error', null, ex.message);
        }
    },

    _getFieldValue: function(gr, fieldName) {
        return gr.getValue(fieldName) || '';
    },

    _getReferenceValue: function(gr, refField, displayField) {
        if (gr[refField].nil()) {
            return '';
        }
        return gr[refField][displayField].toString() || '';
    },

    _createResponse: function(status, data, message) {
        return JSON.stringify({
            status: status,
            data: data,
            message: message,
            timestamp: new GlideDateTime().getDisplayValue()
        });
    }
});        

Benefits of Using JSON:

• Structured Data: JSON represents data in a structured, key-value pair format, making it inherently organized and easy to understand.
• Easy Client-Side Parsing: JavaScript has built-in functions (JSON.parse()) to easily parse JSON strings into JavaScript objects.
• Readability and Maintainability: Code that constructs and processes JSON is much more readable and maintainable than code that deals with delimited strings.
• Flexibility and Scalability: JSON is highly flexible and can easily accommodate more complex data structures, including nested objects and arrays, if your data requirements grow.
• Standard Web Data Format: JSON is the de facto standard for data exchange on the web, making it universally understood and supported across different technologies.

2. Reference Field Handling

return grUser.location.name; // May return undefined

// Corrected Approach --
var locationName = '';
if (grUser.location.name) {
? ? locationName = grUser.location.name.toString();
}        

Here's what can go wrong:

1. grUser.location might be null: In ServiceNow, a reference field like location in the sys_user table might be empty for a particular user. This means grUser.location could be null.
2. Dot-walking on a potentially null object: If grUser.location is null, then attempting to access .name on a null object (grUser.location.name) in JavaScript will result in an error or, more likely in ServiceNow's GlideRecord context, return undefined. JavaScript doesn't throw an error in strict mode for this in all contexts, it often just returns undefined.
3. undefined in the GlideAjax Response: If grUser.location.name evaluates to undefined, this undefined value is what gets included in your concatenated string (or potentially as a value in a JSON response if you were returning JSON). When this response reaches the client-side JavaScript, you'll be working with undefined values, which can lead to unexpected behavior or errors in your client-side code if you're not prepared to handle them.

3.Multiple Field Management

Why the Perception of "Problem" with Multiple Fields and GlideAjax?

The perceived "problem" isn't with GlideAjax's capability, but often with the following implementation issues:

1. Inefficient Data Transfer (Especially with String Concatenation):

Problematic Approach (Similar to String Concatenation for Single Values): Just as we discussed string concatenation being problematic for single values, it becomes significantly worse when dealing with multiple fields. Developers might try to concatenate multiple field values into a single delimited string to send via GlideAjax. For example:

// Client-side (problematic):
var field1Value = g_form.getValue('field1');
var field2Value = g_form.getValue('field2');
var field3Value = g_form.getValue('field3');

var dataString = field1Value + '|' + field2Value + '|' + field3Value; // Concatenate

var ga = new GlideAjax('MyScriptInclude');
ga.addParam('sysparm_name', 'processMultipleFields');
ga.addParam('sysparm_data', dataString); // Send concatenated string
// ... GlideAjax call ...

// Server-side Script Include (problematic parsing):
processMultipleFields: function() {
    var dataString = this.getParameter('sysparm_data');
    var values = dataString.split('|'); // Parse back into array
    var field1Value = values[0];
    var field2Value = values[1];
    var field3Value = values[2];

    // ... GlideRecord operations using field1Value, field2Value, field3Value ...
}        

Why this is problematic for multiple fields:

• Parsing Becomes Complex and Error-Prone: As the number of fields increases, parsing delimited strings becomes increasingly complex and difficult to maintain. Any change in field order or the presence of delimiters within the field values themselves can break the parsing logic.
• Lack of Structure: A single string lacks structure. It's hard to manage if you have different data types, nested data, or need to handle optional fields.
• Difficult to Scale and Maintain: Modifying or adding new fields requires careful adjustments on both the client and server sides to maintain the correct concatenation and parsing order.

Error Handling and Recovery

Challenge Description

Error handling in GlideAjax implementations often fails to account for various failure scenarios, leading to poor user experience and system instability.

Technical Impact

1. Unhandled server exceptions
2. Network failure scenarios
3. Session management issues
4. Incomplete error recovery procedures

Architectural Solutions

A comprehensive error handling strategy should include:

1. Error ClassificationSystem-level errorsBusiness logic errorsNetwork connectivity issuesSession management failures
2. Recovery ProceduresImplement automatic retry mechanismsDefine fallback proceduresEstablish clear error communication protocols

Performance Optimization

Challenge Description

GlideAjax implementations often suffer from performance issues due to inefficient data handling and poor resource utilization.

Technical Impact

1. Excessive server resource utilization
2. Network bandwidth consumption
3. Client-side processing overhead
4. Poor user interface responsiveness

Architectural Solutions

Performance optimization requires a multi-faceted approach:

1. Data OptimizationImplement data pagination strategiesDefine clear data chunking protocolsEstablish efficient caching mechanisms
2. Resource ManagementImplement request batchingDefine clear resource allocation strategiesEstablish connection pooling protocols

Scalability Considerations

Challenge Description

GlideAjax implementations often face scalability challenges when dealing with increasing data volumes and user loads.

Technical Impact

1. Degraded performance under load
2. Resource contention issues
3. Increased response times
4. System stability concerns

Architectural Solutions

Ensuring scalability requires:

1. System ArchitectureImplement proper load balancingDefine clear scaling strategiesEstablish resource allocation protocols
2. Request ManagementImplement request throttlingDefine clear timeout proceduresEstablish concurrent request handling protocols

Conclusion

Successful GlideAjax implementations require careful consideration of these technical challenges and systematic implementation of appropriate solutions. Key recommendations include:

1. Architectural PlanningDevelop clear data structuresImplement comprehensive error handlingEstablish performance monitoring
2. Implementation StrategyFollow established best practicesImplement proper testing proceduresMaintain clear documentation
3. Maintenance ProceduresRegular performance monitoringSystematic error trackingContinuous optimization

This technical analysis provides a foundation for understanding and addressing common GlideAjax challenges in ServiceNow implementations. Future considerations should include emerging patterns in web services, evolving browser capabilities, and new ServiceNow platform features.

If you want to learn more about this kind of discussion and live training or podcasts then join the Linkedin Group https://bit.ly/SNowRealCaseTraining