Advanced MID Server Series – Part 1 – Scripting Deep Dive

Introduction

In this series of posts, we are going to take a look at some more of the more imaginative use cases for the MID Server. To start our series, and to provide a solid foundation to build upon for future posts, we will cover MID Server scripting.

The MID Server scripting environment, like the ServiceNow platform itself, is built on a ServiceNow fork of the RhinoJS JavaScript engine. This engine is a Java implementation of the JavaScript standard that was designed to provide scripting ability to Java server and desktop applications.

One of the great features of the RhinoJS engine is the ability to access the Java environment in which it is running. Those of us who’ve been around ServiceNow for a while will recall being able to do this on the platform itself, not just the MID Server, but ServiceNow chose (quite rightly) to stop this. Generally, in the ServiceNow world, we refer to these as “Package” calls, simply because that is the syntax for accessing the Java system.

e.g.

var Date = new Packages.java.util.Date();

One of the downfalls of using Java in the RhinoJS engine, and more specifically in ServiceNow, is the lack of IntelliSense in the code editor, like that which you’d find in a dedicated Java IDE. This can make using the Java environment more complex, but certainly not impossible.

Java classes, like the example provided above, are generally very well documented. Once you understand how to use them within the RhinoJS environment, they can give you incredible opportunity to develop some complex and non-natively supported functionality for the ServiceNow platform.

How to script on the MID Server

Now that we’ve got a little background on the scripting environment available to us, we can start exploring how to write script for the MID Server.

Like the native platform, it’s possible to write Script Includes that can be called from other scripts. You can access these by navigating to All > MID Server > Script Includes The good news is that you can write these in the same way that you will already be used to with Script Includes that run on platform.

var MyClass = Class.create();
MyClass.prototype = {
    initialize: function() {
    },

    type: 'MyClass'
};

The bad news is that the default script you see above is not automatically generated for you. See this article if you’d like to add this functionality to your instance.

As we saw above, when we want to use Java classes, we must prepend the Java class name with “Packages.”. So let’s work on a little example to get us started.

var MyClass = Class.create();
MyClass.prototype = {
    initialize: function() {
    },
    
    // Simple method to get the date/time of the MID Server
    getMIDDateTime: function() {
        var dateTime = Packages.java.time.ZonedDateTime.now()
        return dateTime.toString();
    },
    
    type: 'MyClass'
};

Granted, this is not exactly the most exciting or imaginative use of a MID Server Script Include, but it provides a simple to understand example. It is worth pointing out that in this example, we have used a static method to obtain the current date/time. We know it’s static, as we’ve not had to initialise the Java class through the use of the ‘new’ keyword. Why do I point this out? Because it’s useful to know the difference between static and instance methods in Java, especially when trying to understand JavaDoc documentation.

This looks like it could get messy!

You’d be right. Package calls are generally quite long, as you have to provide the full java class path every time. We can organise our script a little better to make our code more readable. Your future self/colleagues will thank you for it.

Let’s stick a reference to the class inside the ‘initialize’ method and refactor our code.

var MyClass = Class.create();
MyClass.prototype = {
    initialize: function() {
        this.ZonedDateTime = Packages.java.time.ZonedDateTime;
    },
    
    // Simple method to get the date/time of the MID Server
    getMIDDateTime: function() {
        var dateTime = this.ZonedDateTime.now()
        return dateTime.toString();
    },
    
    type: 'MyClass'
};

By doing this, we’ve made a reusable reference to the Java class that we can reuse as many times as we like throughout our Script Include, saving us from typing it out loads of times and making our code more readable and easier to manage. Great work!

OK, so where do I go from here?

Great question! The rest of this Advanced MID Server Series will explore how we can take advantage of the MID Server to achieve some more interesting and complex outcomes. We will be covering the following areas:

Before we end this article though, it’d be remiss of me to not show how you would run a MID Server Script.

Running MID Server Scripts

ServiceNow provide a Script Include called JavascriptProbe. This Script Include provides all that you need in order to execute a MID Server Script. See below for an example of how we would run our MyClass Script Include from above to get the current date and time from the MID Server.

var jsProbe = new JavascriptProbe('MID_SERVER_NAME');
jsProbe.setName('Testing MyClass Script Include');
jsProbe.setJavascript('new MyClass().getMIDDateTime()');
var strEccSysId = jsProbe.create();

var instanceUrl = gs.getProperty('glide.servlet.uri')

gs.info('Here is the ECC queue entry that was created: ' + instanceUrl + '/ecc_queue.do?sys_id=' + strEccSysId);

gs.info('Here is the ECC queue list where you\'ll find the output from the MID Server: ' + instanceUrl + '/ecc_queue_list.do?sysparm_query=response_to%3D' + strEccSysId);

Make sure to change the MID_SERVER_NAME on line 1, otherwise that script is good to go. The output should be two links, the first will take you to the ECC Queue entry that was created for the MID Server to process. The second link will take you to a list view of the ECC Queue table, you should eventually see one record here representing the response from the MID server.

Conclusion

We’ve now learned how to write script for the MID Server by utilising MID Server Script Includes. As a bonus, you may also now have a new Client Script on your platform that will create the default script for you, just like standard Script Includes.

We’ve also covered how we access the Java system within the RhinoJS environment using Package calls, and we’ve started to think about organising our script so that we don’t make it hard to understand or maintain in future.

Finally we’ve learned how to execute a script on the MID Server by using the JavascriptProbe. In the next Article we’ll be delving into the JavascriptProbe and creating a “BetterJavascriptProbe” that’ll keep you more secure and add some additional useful functionality.

Share this with your network

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Related Posts

Begin typing your search term above and press enter to search. Press ESC to cancel.

Back To Top