Test SAP Cloud ALM Connectivity

Prepare your Infrastructure and Connections for SAP Cloud ALM

If SAP Cloud ALM has to communicate with various other ALM tools (SaaS as well as on-prem) like Jira, ServiceNow, Azure DevOps, SAP Solution Manager ChaRM or FocusedBuild for SAP Solution Manager 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 SAP Cloud ALM, the other ALM products and the middleware server on OS level (called middleware OS in the following text).

This blog post shows how to test the communication between SAP Cloud ALM and a Linux or Windows server to ensure the communication on infrastructure level.
The communication is tested in both directions between SAP Cloud ALM and the middleware OS. 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 Conigma Connect as a middleware itself. This is also helpful later in daily operation.

There are two types of network connections to test:

• From the endpoint system to the middleware OS which will later run Conigma Connect (called inbound connection below).

• From the middleware OS which will later run Conigma Connect 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 blog post, the tests are described using the mock server Mockoon (=open source) in its portable version. It is available for Linux and Windows. An analogous procedure is also valid for any other mock server. On SAP Cloud ALM side the BTP destination test 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 analogously to Docker-based infrastructures.

Inbound Connection Test for SAP Cloud ALM to the Middleware OS

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

On the Middleware Server

Run Mockoon on the middleware server.
Download via 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 SAP Cloud ALM

Go to the BTP account and subaccount hosting your SAP Cloud ALM.
There open the destinations section.
Click on “New Destination” to create a test destination.

Fill the destination data with you Mockoon server URL and other data as in the screenshot below. Port 443 is the default one in that case.

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.

Finally save and click on “Check Connection”.

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 then offers the possibility of further analysis.

Outbound Connection Test from the Middleware OS to SAP Cloud ALM

The following section describes how to test an outbound connection to SAP Cloud ALM.
First you have to find out against which SAP Cloud ALM base URL you test your outbound connection. For that navigate to your SAP Cloud ALM start page.
The base URL can be copied from the browser URL window:

In this case the base URL is https://XXXXX.alm.cloud.sap.
Add the path /api/calm-tasks/v1/ to the base URL (we are testing with SAP Cloud ALM’s Tasks API in this example).
This results in the URL https://XXXXX.alm.cloud.sap/api/calm-tasks/v1/.

From the middleware OS: Test if the SAP Cloud ALM API can be reached.

In Linux
curl <URL>
(e.g. curl https://XXXXX.alm.cloud.sap/api/calm-tasks/v1/)

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

NOTE: The status code "401 Unauthorized" is expected here, since we are not using OAuth for this test (we just do an infrastructure and not an authorization test)
In the event of an error, for example, something like "Time Out" or another error as " Unauthorized " 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 SAP Cloud ALM:

$URI = "https://XXXXX.eu20.alm.cloud.sap/api/calm-tasks/v1/";
Invoke-WebRequest -Verbose -Method GET -Uri $URI;

The required response for a successful test is as follows:

NOTE: The status code "401 Unauthorized" is expected here, since we are not using OAuth for this test (we perform an infrastructure and not an authorization test).
In case of an error, for example, something like "Time Out" or another error as "Unauthorized" 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 operation for error analysis (e.g. expired server certificate for HTTPS connections).