GlideAJAX Equivalent for Service Portal – Getting Server Data from Client

Note: This article requires basic familiarity with coding Service Portal widgets.

In the Service Portal, the scripting environment is different from the ServiceNow backend. Portal widgets utilize AngularJS, which introduces a model-view-controller approach to passing data and handling what is presented to the end user. Sometimes it is necessary, like on the backend, to access server-side data from arbitrary records in response to form behavior, button clicks, or other client-side triggers. One way to do this without requiring a page reload is to use the “get” function.

From the client controller, which is assigned to the variable “c” by default, server functions are accessible from the “server” attribute (so, c.server). The server object contains functions like “update” (c.server.update()), which is a commonly used function to pass the client-side data object to the server. Another function, and the one this article is concerned with, is the “get” function (c.server.get()).

The “get” function allows functionality that behaves similarly to backend GlideAJAX. It takes a JSON object as an argument that contains any number of attributes that you would like to pass to the backend, and requires one attribute to be called “action” that is set to the name of a server-side script that you would like to process your input.  (After the “get” call, you’ll want to append a call to the “then” function that will operate as a callback, but this will be explained in detail below.)

Note: Due to an Angular quirk, on the client side, the action name must be all lowercase, with each word separated by underscores. This is interpreted on the server in camel-case with the underscores removed. For example, if you pass the object:

{date: parms.newValue, 
action: "get_schedule_data"}

Your server-side function must be named “getScheduleData”.

Once the “get” function runs, the server side script will run and will receive an input object with attributes that match those created as part of your “get” call. So, using the above object as an example, inpute.date and input.action will be available. To catch your intention on the server side, you can condition a block of code that looks like this:

if(input && input.action == "get_schedule_data"){
	getScheduleData(input.date);
}

The bare “input” condition ensures the input object exists (ie. this is not the initial widget load) and the second condition recognizes the action that was defined. The inside of the “if” contains a call to the defined function, where the other parameter is passed (as an example).

You must ensure you have a function defined with the matching name (eg. getScheduleData) that is also configured for the correct set of parameters. Within this function, to send data back to the client, you should set attributes on the data object (eg. data.schedList = ??).

When the function terminates, the values you set will be made available within the client-side callback function. Your full client-side function should look like:

c.server.get({
	date: reqDate, 
	action: "get_schedule_data"
}).then(function(response) {
	//Process your response
	c.data.schedList = response.data.schedList;
});

As shown above, the values you assigned to the data object on the server-side will be accessible from the response.data object.

Within portal widgets, there are several acceptable ways to accomplish similar things. This method is a responsive way to interact with the server, especially if you need to access data not contained within the record the widget is concerned with.