Test ServiceNow Connectivity on OS Level

Prepare your Infrastructure and Connections for ServiceNow

When communication between different ALM tools, including SAP ALM tools, is to be implemented, e.g. using a middleware like Conigma™ Connect, it is a good approach to upfront check the prerequisites on network level.

Often network components like SAP CPI / SAP Integration Suite, firewalls, reverse proxies, MID servers, etc. or challenges like missing certificates require different actions for a communication between the ALM tool and the middleware server on OS level (called middleware OS in the following text).

This blog post shows how to test the communication between products like ServiceNow and a Linux or Windows server to ensure on infrastructure level e. g. for an integration of ServiceNow SaaS and SAP Solution Manager ChaRM or FocusedBuild for SAP Solution Manager, for example. The respective procedure applies analogously for SAP Solution Manager on-prem and in the private cloud.

The communication is tested in both directions for each platform and operating system. Such a test helps to identify communication problems upfront and therefore provides the possibility to solve such problems in an earlier project phase. This communication will be tested on OS level and is independent from the middleware itself.

There are two types of network connections to test:

• From the endpoint system to the Conigma Connect Server (called inbound connection below).

• From the Conigma Connect Server to the endpoint system (below called Outbound-Connection).

To test the correctly set up network connections for inbound connections, our customers typically use a mock server that can receive and log API calls (see picture below). In this paper, the tests are described using the mock server Mockoon in its portable version. It is available for Linux and Windows. An analogous procedure is also valid for any other mock server. On ServiceNow side the built-in REST message function is used.

Outbound connections, on the other hand, are usually tested using OS-related procedures, e.g. Window Powershell or Linux curl (see also picture below).

General notice: The described approach also applies to Docker-based infrastructures.

Architecture of the test setup

Inbound Connection Test for ServiceNow to the Middleware OS

This chapter describes the test of the inbound connection from ServiceNow to the middleware operating system, on which the Conigma Connect Server will be installed.

On the Middleware Server

Run Mockoon on the middleware server. https://mockoon.com/ (available for Windows, Linux and Docker)

In Mockoon: enter Port and (if requested) HTTPS setup data.

Now start the Mockoon server:

In ServiceNow

Navigate to outbound REST call administration:

Create new call:

Maintain Endpoint and create a new HTTP method call:

For the endpoint in the image above you have to enter either

<your_mockoon_server_name>:<port>/users

or <your_mockoon_server_ip>:<port>/users.

The HTTP method "Default_GET" is created automatically by ServiceNow. The endpoint automatically is taken from the parent Rest Message. This means that the rest message can be tested directly via the HTTP method.

The result should look as follows (status code 200 means “o.k.”):

In case of an error, the HTTP Status field contains a value <> 200. The error message, in conjunction with the JSON body of the response, offers the possibility of further analysis.

Outbound Connection Test from the Middleware OS to ServiceNow

The following section describes how to test an outbound connection to ServiceNow.

First you have to find out against which ServiceNow base URL you test your outbound connection. For that navigate to the REST API Explorer in ServiceNow:

Find you API base URL. This is required for the corresponding outbound call from the middleware OS.

In this case the base URL is "https://devXXXXX.service-now.com/api".

From the middleware OS: Test if the ServiceNow API can be reached.

In Linux:

curl -vi <URL>
(e.g. curl -vi https://devXXXXX.service-now.com/api)

Expected result from curl ("Bad request" is positive in this case):

NOTE: The status code "400 Bad Request" is expected here, since no real sub-API was addressed. If it occurs together with the correct JSON body "Requested URI does not represent any resource", the connection is fine.

In the event of an error, for example, something like "Time Out" or another error as "Bad Request" appears in the log. Typical errors are, for example, certificate related.

In Windows:
Use the following PowerShell Script or a similar one to verify the connection to ServiceNow:

$URI = "https://XXXXXXXX.service-now.com/api";
Clear-Variable Response;
Clear-Variable ErrHead;
Clear-Variable ErrBody;
try {
    Invoke-WebRequest -Verbose -Method GET -Uri $URI
}
    catch {
        $Response = $_.Exception.Response ;
        $ErrHead = $Response.StatusCode ;
        $ErrBody = [System.IO.StreamReader]::new($Response.GetResponseStream()).ReadToEnd()
    };
$ErrHead; $ErrBody

The required response for a successful test is as follows:

NOTE: The status code "400 Bad Request" is expected here, since no real sub-API was addressed. If it occurs together with the correct JSON body "Requested URI does not represent any resource", the connection is fine.

In the event of an error, for example, something like "Time Out" or another error as "Bad Request" appears in the log. Typical errors are, for example, certificate related.

Summary

The above-described tests are not only recommended before installing Conigma Connect. Rather, they can also be used in daily operations for error analysis (e.g., expired server certificate for HTTPS connections).