Test Azure DevOps Connectivity on OS Level

Prepare your Infrastructure and Connections for Azure DevOps

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 Azure DevOps and a Linux or Windows server to ensure on infrastructure level e. g. for an integration of Azure DevOps 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 Azure DevOps to the Conigma Connect Server (called inbound connection below).

• From the Conigma Connect Server to Azure DevOps (called outbound connection below).

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 Azure DevOps side the built-in Service Hooks 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 Azure DevOps to the Middleware OS

This chapter describes the test of the inbound connection from Azure DevOps 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 Azure DevOps

Go to the project settings and start to create a subscription in the service hooks settings:

NOTE: We will later delete this subscription, so no persistent change will be made.

Choose to create a WebHook.

Select a setting which is fine to be there for the dummy webhook during test time.

It does not matter which you choose, we will trigger the hook manually anyhow. Example:

Enter the POST data.

The URL will be <your Mockoon URL with port>/content/xyz

 Also make sure to send no details in order to perform an immediate test.

Save the test hook.

Now open the hook again an execute "Test".

NOTE: If you receive a "Success" and not "Queued" here, the test is successful and you can continue with deleting the test hook.

If the request execution is queued, please check the test hook history:

Expected result:

After success you can delete the WebHook again.

 Outbound Connection Test from the Middleware OS to AzureDevOps

The following section describes how to test an outbound connection to Azure DevOps.

First build your companies API base URL:

https://dev.azure.com/<mycompany>/<myproject>/_apis

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

In Linux:
curl -i <URL>
(e.g. curl -vi https://dev.azure.com/<mycompany>/<myproject>/_apis)

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

NOTE: The status code "302 Found" is expected here, since a redirection to the login page takes place.

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 Azure DevOps:

$URI = "https://dev.azure.com/<mycompany>/<myproject>/_apis";

Invoke-WebRequest -Verbose -Method GET -Uri $URI

The required response for a successful test is as follows:

NOTE: The status code "203 Non-Authoritative Information" is expected here, since no login has taken place.

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).