SAP Cloud ALM Connectivity auf Betriebssystem-Ebene testen

Bereiten Sie Ihre Infrastruktur und Verbindungen für SAP Cloud ALM vor

Wenn SAP Cloud ALM mit verschiedenen anderen ALM-Tools (SaaS und On-Prem) wie Jira, ServiceNow, Azure DevOps, SAP Solution Manager ChaRM oder FocusedBuild for SAP Solution Manager über Conigma Connect integriert werden soll, ist es ein guter Ansatz, im Vorfeld die Voraussetzungen auf Netzwerkebene sicherzustellen.
Oftmals erfordern Netzwerkkomponenten wie SAP CPI / SAP Integration Suite, Firewalls, Reverse Proxies, MID Server, etc. oder Herausforderungen wie fehlende Zertifikate verschiedene Maßnahmen für eine Kommunikation zwischen SAP Cloud ALM, den anderen ALM Produkten und dem Middleware Server auf Betriebssystemebene (im folgenden Text Middleware OS genannt).

Dieser Blogbeitrag zeigt, wie man die Kommunikation zwischen SAP Cloud ALM und einem Linux- oder Windows-Server testet, um die Kommunikation auf Infrastrukturebene nachzuweisen.
Die Kommunikation wird in beide Richtungen zwischen SAP Cloud ALM und dem Middleware-Betriebssystem getestet. Ein solcher Test hilft, Kommunikationsprobleme im Vorfeld zu erkennen und bietet somit die Möglichkeit, solche Probleme in einer früheren Projektphase zu lösen. Diese Kommunikation wird auf OS-Ebene getestet und ist unabhängig von Conigma Connect als Middleware selbst. Dies ist auch später im täglichen Betrieb hilfreich.

Es gibt zwei Arten von Netzwerkverbindungen, die getestet werden können:

• Von SAP Cloud ALM zum Middleware-Betriebssystem, auf dem Conigma Connect später läuft (im Folgenden als Inbound-Connection bezeichnet).

• Vom Middleware-Betriebssystem, auf dem später Conigma Connect läuft, zu SAP Cloud ALM (im Folgenden Outbound-Connection genannt).

Um die korrekte Einrichtung von Netzwerkverbindungen für eingehende Verbindungen zu testen, verwenden unsere Kunden in der Regel einen Mock-Server, der API-Aufrufe empfangen und protokollieren kann (siehe Abbildung unten). In diesem Blogbeitrag werden die Tests unter Verwendung des Mock-Servers Mockoon (=open source) in seiner portablen Version beschrieben. Er ist für Linux und Windows verfügbar. Ein analoges Vorgehen gilt aber auch für jeden anderen Mock-Server. Auf Seiten von SAP Cloud ALM wird die BTP-Destinations-Testfunktion verwendet.

Outbound connections werden dagegen in der Regel mit betriebssystembezogenen Verfahren getestet, z. B. mit Windows Powershell oder Linux curl (siehe auch Abbildung unten).

Allgemeiner Hinweis: Der beschriebene Ansatz gilt sinngemäß auch für Docker-basierte Infrastrukturen.

Inbound Connection Test für SAP Cloud ALM zum Middleware OS

Dieses Kapitel beschreibt den Test der eingehenden Verbindung von SAP Cloud ALM zu dem Middleware-Betriebssystem, auf dem der Conigma Connect Server installiert wird.

Auf dem Middleware Server

Führen Sie Mockoon auf dem Middleware-Server aus.
Herunterladen über https://mockoon.com/ (verfügbar für Windows, Linux und Docker).

In Mockoon: Port und (falls gewünscht) HTTPS-Einrichtungsdaten eingeben.

Starten Sie nun den Mockoon-Server.

In SAP Cloud ALM

Gehen Sie zu dem BTP-Account und Subaccount, das Ihr SAP Cloud ALM hostet.
Öffnen Sie dort den Abschnitt Ziele.
Klicken Sie auf “New Destination” um ein Testziel zu erstellen.

Füllen Sie die Zieldaten mit der URL Ihres Mockoon-Servers und anderen Daten wie im Screenshot unten. Port 443 ist in diesem Fall der Standardport.

Für den Endpunkt in der obigen Abbildung müssen Sie entweder
<your_mockoon_server_name>:<port>/users
oder
<your_mockoon_server_ip>:<port>/users.

Speichern Sie abschließend und klicken Sie auf "Verbindung prüfen".

Das Ergebnis sollte wie folgt aussehen (Statuscode 200 bedeutet "o.k."):

Im Falle eines Fehlers enthält das Feld HTTP-Status den Wert <> 200. Die Fehlermeldung bietet dann die Möglichkeit zur weiteren Analyse.

Outbound Connection Test vom Middleware OS zu SAP Cloud ALM

Der folgende Abschnitt beschreibt, wie Sie eine ausgehende Verbindung zu SAP Cloud ALM testen können.
Zunächst müssen Sie herausfinden, gegen welche SAP Cloud ALM-Basis-URL Sie Ihre ausgehende Verbindung testen. Dazu navigieren Sie zu Ihrer SAP Cloud ALM-Startseite.
Die Basis-URL kann aus dem URL-Fenster des Browsers kopiert werden:

In diesem Fall lautet die Basis-URL https://XXXXX.alm.cloud.sap.
Fügen Sie den Pfad /api/calm-tasks/v1/ zur Basis-URL hinzu (in diesem Beispiel testen wir mit der Tasks-API von SAP Cloud ALM).
Daraus ergibt sich die URL https://XXXXX.alm.cloud.sap/api/calm-tasks/v1/.

Über das Middleware-Betriebssystem: Testen Sie, ob die SAP Cloud ALM API erreicht werden kann.

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

Erwartetes Ergebnis von curl ("Unauthorized" ist in diesem Fall positiv):

HINWEIS: Der Statuscode "401 Unauthorized" wird hier erwartet, da wir für diesen Test kein OAuth verwenden (wir führen nur einen Infrastruktur- und keinen Autorisierungstest durch)
Im Falle eines Fehlers erscheint z.B. etwas wie "Time Out" oder ein anderer Fehler als "Unauthorized" im Protokoll. Typische Fehler sind z. B. zertifikatsbezogen.

In Windows

Verwenden Sie das folgende PowerShell-Skript oder ein ähnliches, um die Verbindung zu SAP Cloud ALM zu überprüfen:

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

Die erforderliche Antwort für einen erfolgreichen Test lautet wie folgt:

HINWEIS: Der Statuscode "401 Unauthorized" wird hier erwartet, da wir für diesen Test kein OAuth verwenden (wir führen einen Infrastruktur- und keinen Autorisierungstest durch). Im Falle eines Fehlers erscheint im Protokoll z. B. etwas wie "Time Out" oder ein anderer Fehler als "Unauthorized". Typische Fehler sind z.B. zertifikatsbezogen.

Zusammenfassung

Die oben beschriebenen Tests sind nicht nur vor der Installation von Conigma Connect zu empfehlen. Vielmehr können sie auch im täglichen Betrieb zur Fehleranalyse genutzt werden (z. B. abgelaufenes Serverzertifikat bei HTTPS-Verbindungen).