Testen der Azure DevOps Connectivity auf OS Level

Überblick

Wenn eine Kommunikation zwischen verschiedenen ALM-Werkzeugen, einschließlich SAP ALM-Werkzeugen, implementiert werden soll, z.B. unter Verwendung einer Middleware wie Conigma™ Connect, ist es ein guter Ansatz, im Vorfeld die Voraussetzungen auf Netzwerkebene zu prüfen.

Oftmals erfordern Netzwerkkomponenten wie SAP CPI / SAP Integration Suite, Firewalls, Reverse Proxies, MID Server, etc. oder Herausforderungen wie fehlende Zertifikate verschiedene Aktionen für eine Kommunikation zwischen dem ALM-Tool und dem Middleware-Server auf OS-Ebene (im folgenden Text Middleware OS genannt).

Dieser Blogbeitrag zeigt, wie man die Kommunikation zwischen Produkten wie Azure DevOps und einem Linux- oder Windows-Server testet, um auf Infrastrukturebene z. B. eine Integration von Azure DevOps SaaS und SAP Solution Manager ChaRM oder FocusedBuild für SAP Solution Manager sicherzustellen. Das jeweilige Vorgehen gilt analog für SAP Solution Manager on-prem und in der Private Cloud.

Die Kommunikation wird in beide Richtungen für jede Plattform und jedes 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 Betriebssystemebene getestet und ist unabhängig von der Middleware selbst.

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

• Von Azure DevOps zum Conigma Connect Server (im Folgenden Inbound-Connection genannt).

• Vom Conigma Connect Server zu Azure DevOps (im Folgenden als Outbound-Connection bezeichnet).

Um die korrekt eingerichteten Netzwerkverbindungen für eingehende Verbindungen zu testen, verwenden unsere Kunden typischerweise einen Mock-Server, der API-Aufrufe empfangen und protokollieren kann (siehe Bild unten). In diesem Papier werden die Tests mit dem Mock-Server Mockoon 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 Azure DevOps Seite wird die eingebaute Funktion Service Hooks verwendet.

Ausgehende Verbindungen hingegen werden in der Regel mit OS-bezogenen Prozeduren getestet, z.B. Window Powershell oder Linux curl (siehe auch Bild unten).

Allgemeiner Hinweis: Die beschriebene Vorgehensweise gilt auch für Docker-basierte Infrastrukturen.

Architektur des Testaufbaus

Inbound Connection Test für Azure DevOps zum Middleware OS

Dieses Kapitel beschreibt den Test der eingehenden Verbindung von Azure DevOps zu dem Middleware-Betriebssystem, auf dem der Conigma Connect Server installiert werden soll.

Auf dem Middleware Server

Führen Sie Mockoon auf dem Middleware-Server aus.. 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 Azure DevOps

Gehen Sie zu den Projekteinstellungen und beginnen Sie mit der Erstellung eines Abonnements in den Einstellungen der Service-Hooks:

HINWEIS: Wir werden dieses Abonnement später löschen, es wird also keine dauerhafte Änderung vorgenommen.

Wählen Sie, um einen WebHook zu erstellen.

Wählen Sie eine Einstellung, die für den Dummy-Webhook während der Testzeit in Ordnung ist.

Es spielt keine Rolle, welche Sie wählen, wir werden den Hook ohnehin manuell auslösen.

Beispiel:

Geben Sie die POST-Daten ein.

Die URL wird <Ihre Mockoon URL mit port>/content/xyz

Achten Sie auch darauf, keine Details zu senden, um einen sofortigen Test durchzuführen.

Speichern Sie den Test-Hook.

Öffnen Sie nun den Hook erneut und führen Sie "Test" aus.

HINWEIS: Wenn Sie hier ein "Success" und nicht "Queued" erhalten, ist der Test erfolgreich und Sie können mit dem Löschen des Test-Hooks fortfahren.

Wenn die Ausführung der Anfrage in der Warteschlange steht, überprüfen Sie bitte die Historie Ihres Web Hooks:

Expected result:

Nach erfolgreichem Lauf können Sie den WebHook wieder löschen.

Outbound Connection Test vom Middleware OS zu AzureDevOps

Im folgenden Abschnitt wird beschrieben, wie Sie eine ausgehende Verbindung zu Azure DevOps testen.

Erstellen Sie zunächst die API-Basis-URL Ihres Unternehmens:

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

Über das Middleware-Betriebssystem: Testen Sie nun, ob die Azure DevOps API erreicht werden kann.

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

Erwartetes Ergebnis für curl ("Not found" ist positiv im vorliegenden Fall):

HINWEIS: Der Status Code "302 Found" wird hier erwartet, da eine Umleitung auf die Login-Seite erfolgt.

Im Falle eines Fehlers erscheint z. B. so etwas wie "Time Out" oder ein anderer Fehler wie "Bad Request" im Log. Typische Fehler sind z. B. zertifikatsbezogen.

In Windows:
Verwenden Sie das folgende oder ein ähnliches PowerShell-Skript, um die Verbindung zu Azure DevOps zu überprüfen:

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

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

Die erforderliche Reaktion für einen erfolgreichen Test ist wie folgt:

HINWEIS: Der Status Code "203 Non-Authoritative Information" wird hier erwartet, da keine Anmeldung stattgefunden hat. 

Im Falle eines Fehlers erscheint z.B. etwas wie "Time Out" oder ein anderer Fehler wie "Bad Request" im Protokoll. 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).