Test Conigma CCM oder SAP Solution Manager Connectivity auf Betriebssystem Ebene

Blog vom 07.02.2023

Vorbereitung von Infrastruktur und Connections für Conigma CCM / SAP Solution Manager

Wenn die Kommunikation zwischen verschiedenen SAP ALM Werkzeugen, einschließlich Conigma CCM, SAP Solution Manager ChaRM oder FocusedBuild for SAP Solution Manager, auf Basis von Conigma Connect implementiert werden soll, macht eine Vorabprüfung der Voraussetzungen auf Netzwerkebene Sinn. 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 fehlerfreie Kommunikation zwischen SAP und dem Middleware Server auf OS-Ebene (im folgenden Text Middleware OS genannt).

Dieser Blogbeitrag zeigt, wie die Kommunikation zwischen dem Conigma Connect Zentralsystem (= ABAP basiertes SAP Add-on) und einem Linux oder Windows Server getestet werden kann. Das jeweilige Vorgehen gilt analog für SAP Solution Manager ChaRM sowie FocusedBuild für SAP Solution Manager.

Die Kommunikation wird in beide Richtungen für Windows- und Linux-Server getestet. Solche Tests helfen, Kommunikationsprobleme im Vorfeld zu erkennen und bieten 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 Conigma Connect selbst.

Es gibt zwei Arten von Netzwerkverbindungen, die getestet werden:

  • Vom SAP System zum Conigma Connect Server auf Betriebssystemebene (im Folgenden Inbound-Connection genannt).

  • Vom Conigma Connect Server auf OS-Ebene zum SAP-System (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 Beitrag werden die Tests unter Verwendung des Mock-Servers Mockoon in seiner portablen Version beschrieben. Dieses Open-Source-Produkt ist für Linux und Windows verfügbar (sowie als Docker-Version passend für SAP BTP / Cloud Foundry). Ein analoges Vorgehen funktioniert auch für andere Mockserver. Auf Conigma CCM Seite wird der SAP Standardreport SAPHTML_DEMO01 verwendet. Dieser existiert auch auf SAP Solution Manager Systemen.

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

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

Conigma CCM ABAP Add-on SAP Solution Manager Inbound Outbound Connection to Middleware OS

Inbound-Connection Test von SAP zum Middleware OS

Dieses Kapitel beschreibt den Test der Inbound-Connection von dem SAP-System, das das  Conigma CCM Zentralsystem als ABAP Add-On hostet, zu dem Middleware Betriebssystem, auf dem der Conigma Connect Server installiert wird. Dies gilt auch für SAP Solution Manager Systeme.

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 erforderlich) HTTPS-Einrichtungsdaten eingeben.

Mockoon Enter Port and HTTPS Settings

Starten Sie nun den Mockoon-Server:

Start Mockoon-Server

Auf dem SAP-System
Melden Sie sich nun an Ihrem SAP-System an und führen Sie den ABAP-Report SAPHTML_DEMO1 aus.
Geben Sie in der URL-Leiste entweder
https://<your_mockoon_server_name>:<port>/users
oder
https://<your_mockoon_server_ip>:<port>/users ein.
Drücken Sie schließlich <Enter>.

Das erwartete Ergebnis sollte wie folgt aussehen:

Result

Im Falle eines Fehlers wird eine Fehlermeldung des Browsers angezeigt. Die Fehlermeldung bietet die Möglichkeit zur weiteren Analyse.

Outbound-Connection Test vom Middleware OS zum SAP System

Der folgende Abschnitt beschreibt, wie man eine Outbound-Connection zu dem SAP-System, auf dem das Conigma CCM Zentralsystem (=ABAP Add-on) läuft, testet. Zunächst müssen wir eine geeignete Test-URL in unserem SAP-System finden. Dazu navigieren wir zur Transaktion SICF im SAP-System und wählen einen beliebigen, gerade laufenden Service aus. In unserem Beispiel wählen wir /default_host/sap/url/, es kann aber auch jeder andere existierende Service gewählt werden.

how to test an outbound connection to the SAP system running the Conigma CCM central system (=ABAP add-on)open the service details

Doppelklicken Sie auf den Service, um die Dienstdetails zu öffnen, und kopieren Sie den Dienstpfad (ohne den Teil "default_host"!) und den Dienstnamen. Mit dem Unterpfad/Namen des Dienstes und der Adresse/Port, über die wir versuchen, das System von unserem Middleware-OS aus zu erreichen, können wir die URL wie folgt aufbauen:

http[s]://<SAP System Hostname>:<Port>/<Path>/<Name>

oder

http[s]://<SAP System IP>:<Port>/<Path>/<Name>

z. B. https://sapsys.mycorp.com:8000/sap/url/go.

Von unserem Middleware OS aus testen wir nun die Verbindung.

Linux

Unter Linux verwenden Sie den folgenden Befehl: curl -I <Our SAP System URL>

Das erwartete Ergebnis lautet wie folgt:

Linux result

HINWEIS: Hier wird der Statuscode "401 Unauthorized" erwartet, da es sich hier nicht um Anmeldungen handelt. Jedes andere Ergebnis deutet auf einen Fehler hin und sollte analysiert werden.

Windows

Für Windows verwenden Sie das folgende PowerShell-Skript:
$URI = "http://saps01.emp.intern:53800/sap/url/go";
Invoke-WebRequest -Verbose -Method GET -Uri $URI;

Das erwartete Ergebnis lautet wie folgt:

Windows result

HINWEIS: Hier wird der Statuscode "401 Unauthorized" erwartet, da wir für diesen Test keine Anmeldeinformationen bereitstellen (wir führen einen Infrastruktur- und keinen Autorisierungstest durch). Im Falle eines Fehlers erscheint beispielsweise so etwas wie "Time Out" oder ein anderer Fehler wie "Unauthorized" im Protokoll. Typische Fehler sind z. B. zertifikatsbezogen.

Zusammenfassung

Die oben beschriebenen Tests werden vor der Installation von Conigma Connect empfohlen. Zusätzlich können sie auch im täglichen Betrieb zur Fehleranalyse verwendet werden (z.B. abgelaufenes Serverzertifikat bei HTTPS-Verbindungen).