mid_server_-_Google_Search

In a post I created a while ago, I talked about passing parameters from a ServiceNow script to a MID Server script include via the ECC Queue. (see Javascript Probes and MID Server Script Includes)

This is typically a fine practice. However, if one of those parameters contains a password to a third party system, then that password will be in plain text format on the ECC Queue. Some people are OK with this since ECC Queue entries are limited to System Admins, etc, however others still do not feel comfortable having a password in plain text on the queue.

You can get around this problem in two ways: 1) Create a MID Server property and store the password there, or 2) Use RemoteGlideRecord from the MID Server Script include to query a system property on the fly.

MID Server Property Method

You can create MID Server properties in the ServiceNow instance by browsing to MID Server > Properties.

ServiceNow_Service_Automation

In this example, I created a MID Server Property called “john.test”, with a value of “andersen”.

ServiceNow_Service_Automation-2

Your MID Server Script Include can access a MID Server property but instantiating the “Packages.com.service_now.mid.service.Config” class and leveraging the “getProperty” function.

In the follow code snippet, I am going to get the value of my “john.test” MID Server Property:

1
2
3
config = Packages.com.service_now.mid.services.Config.get();
var test = config.getProperty("john.test");
ms.log("TEST: " + test);

When I execute this code in my MID Server Background Scripts module, I get the following results:

MID Server background script result:

*** Script: TEST: andersen

RemoteGlideRecord Process

The RemoteGlideRecord method leverages a MID Server library call by the name of “Packages.com.glide.communications.RemoteGlideRecord”. This method is similar to the “GlideRecord” API but instead of querying the database within an instance, it makes a SOAP Web Service call to an instance to get the data required for the GlideRecord call.

In order to leverage this, however, you need to set the authentication for the call. This can typically be done by the MID Server user, as long as that user has rights to access the data from the RemoteGlideRecord call. In this case, my MID Server user is the “admin” user, and I know that that user has rights to query the sys_properties table.

In the following example, I am using the RemoteGlideRecord call to query the sys_properties table for a property called: “glide.installation.name”.

1
2
3
4
5
6
7
8
9
10
config = Packages.com.service_now.mid.services.Config.get();
var user =    config.getProperty("mid.instance.username");
var password =config.getProperty("mid.instance.password");

var rgr = new Packages.com.glide.communications.RemoteGlideRecord("https://MYINSTANCE.service-now.com", "sys_properties");
rgr.setBasicAuth(user, password);
rgr.addQuery("name", "glide.installation.name");
rgr.query();
rgr.next();
ms.log("Glide Installation Name: " + rgr.getValue("value"));

I get the following result when I execute this script in my MID Server Background Scripts Module:

MID Server background script result:

*** Script: Glide Installation Name: Demo Server
Slow execution (141ms) of script: ad_hoc:null

Notice the “Slow Execution” warning I got. That is due to the fact that I made a SOAP web service call back to the instance during my script to get a system property value.

Pros and Cons

The MID Server Property method is nice because these properties get cached on the MID Server so that the script doesn’t have to make a SOAP call during the execution in order to get the sensitive data. However, this does require additional set up on your part to create the MID Server Property and maintain that record.

RemoteGlideRecord is flexible and can read any database table in the system that you have rights to access. This lets you query more that just system properties. Also, you don’t have to set anything special up on the ServiceNow instance, you just access data that is already there. However, I do not like the fact that RemoteGlideRecord has to make individual SOAP calls to the instance to get that data. This can slow your scripts down a little bit and it may have an impact on the instance. If you are just querying a password value, then it may not be much of an impact at all, but the risk still exists.

In summary, I prefer the MID Server Property method. It does require that I set up that property, but in the overall scheme of things, I like the fact that I don’t have to make additional web service calls during my script execution. Also, I have no guarantee that the MID Server user will have the correct roles required to do the RemoteGlideRecord call that I am performing.