Application Components

Here are the main application components of the Itential Automation Services Application:

• Client GUI React Application
• Server Scripted REST API
• Triggered Jobs Table
• IAP Instances Config Table
• Actions
• Flows
• MID Server Support

Client GUI React Application

The Client GUI React Application, which runs in a browser, is a standalone application that will be installed into your ServiceNow instance. This Application component exists in the latest version of the Itential Automation Services Application available on the ServiceNow Store.

This part of the overall package allows you to integrate to Itential, choose an automation, and trigger that automation to start. You can provide the information that is required for the automation and then submit that data to have the automation started in Itential.

Server Scripted REST API

In the initial version of the Itential Automation Services Application, the Client GUI React Application would directly call Itential. As Itential expanded its support to include additional authentication methods, a decision was made to move the Itential integration to the ServiceNow server.

The newer, recent version of the Itential Automation Services Application includes Server Script Include and Scripted REST API calls. While the Client GUI React Application still runs in a user's browser, it now makes calls back to the ServiceNow server, which then makes the call to Itential. The browser no longer needs access to Itential - only the ServiceNow Server will need access.

Triggered Jobs Table

The Triggered Jobs table contains information for all Itential Automations that have been started in ServiceNow. This includes automations starting through the Client GUI React Application or through the Itential Start Endpoint and Itential Start Manual Actions.

You can review this table to see the automations. While there is a script to update the status of the jobs, it is currently set to run on demand so the job statuses are not automatically updated. You can set a scheduled job to update this table as often as you would like.

Figure 1: Triggered Jobs Table

IAP Instances Config Table

The IAP Instances Config Table contains config details and other settings for your Itential Automation Services Application instance, including name, hostname, auth_type, and other fields. These instance settings are used to set permissions and control how Itential Actions and Flows connect, execute and run Itential Automation Services Application in ServiceNow.

Figure 2: Instances Table

Actions

The Itential Automation Services Application now includes Itential-built Actions. An Action is a reusable operation that enables process analysts to automate ServiceNow platform features without having to write code. These actions need to be incorporated into Flows which are then integrated into other ServiceNow Processes (e.g. Change) via triggers.

These actions have been built to work regardless of the way you are authenticating to Itential. You will notice there are duplicate actions - one for connecting to Itential through a MID Server, and one for connecting directly (without a MID Server). MID Servers are generally utilized when going from a public ServiceNow instance to an instance of Itential that resides in a private customer network.

Flows

The Itential Automation Services Application now includes Itential-built example Flows. These Flows provide an example of when you might want to trigger an Itential Automation within ServiceNow processes. They define the data that would be needed by the Itential actions. An advantage of considering the example Flows is seeing how Itential handles the different types of authentications within the Flows.

The Itential Flow examples also determine whether a MID Server has been defined for connectivity to Itential. If a MID Server has been provided, the Flow will use the Actions for using a MID Server and if a MID Server has not been provided the Flow will utilize the Action without the MID Server.

Since Flows are triggered within a business process, customers would need to create their own Flows which define when in their process they want to trigger Itential automations. They also need to define where in their data the necessary input to the Itential automation should come from.

Figure 3: Actions & Flows

MID Server Support

The Itential Automation Services Application now supports the inclusion of MID Servers when necessary for integration from ServiceNow to Itential. A MID Server provides a more secure way of going from ServiceNow server on the public internet to an Itential Server in the customer’s private network.

Both the Client GUI React Application and the Actions contained with the Itential Automation Services Application have been built to work with or without a MID Server.

Figure 4: Application Architecture