ServiceNow Connectivity auf Betriebssystem-Ebene testen

Vorbereitung von Infrastruktur und Verbindungen für ServiceNow

Für die Kommunikation zwischen verschiedenen SAP ALM Werkzeugen eignet sich die Middleware Conigma™ Connect bestens. SAP-Anwenderunternehmen sollten aber im Vorfeld die Voraussetzungen auf Netzwerkebene prüfen. Denn Netzwerkkomponenten – wie SAP CPI / SAP Integration Suite, Firewalls, Reverse Proxies, MID Server etc. – haben oft nicht die erforderlichen Zertifikate. Darum bedarf verschiedener Maßnahmen für die Kommunikation zwischen den SAP ALM Tools und dem Middleware Server auf Betriebssystemebene (im folgenden Text Middleware OS genannt).

Dieser Blogartikel erläutert, wie SAP-Anwenderunternehmen die Kommunikation zwischen einer ITSM-Lösung wie ServiceNow und einem Linux- oder Windows-Server testen können, um auf Infrastrukturebene eine Integration von ServiceNow SaaS und SAP Solution Manager ChaRM oder FocusedBuild for SAP Solution Manager sicherzustellen. Das entsprechende Vorgehen gilt analog für SAP Solution Manager on-prem und in der Private Cloud.

Die Kommunikation muss für jede Plattform und jedes Betriebssystem in beide Richtungen getestet werden. Ein solcher Test hilft, Kommunikationsprobleme im Voraus zu erkennen und bietet daher 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:

• Vo ServiceNow zum Conigma Connect Server (im Folgenden Inbound-Connection genannt).

• Vom Conigma Connect Server zu ServiceNow (im Folgenden Outbound-Connecton genannt).

Um die korrekte Einrichtung von Netzwerkverbindungen für Inbound-Connections zu testen, verwenden unsere Kunden in der Regel einen Mock-Server, der API-Aufrufe empfangen und protokollieren kann (siehe Abbildung unten). In diesem Blogartikel werden die Tests unter Verwendung des Mock-Servers 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 ServiceNow-Seite wird die eingebaute REST-Message Funktion verwendet. Outbound-Connections werden dagegen in der Regel mit betriebssystembezogenen 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.

Architektur des Testaufbaus

Test der Inbound-Connection von ServiceNow zum Middleware OS

Dieses Kapitel beschreibt den Test der eingehenden Verbindung von ServiceNow zu m Middleware-OS, auf dem der Conigma Connect Server installiert wird.

Auf dem Middleware Server

Führen Sie Mockoon auf dem Middleware-Server aus. Download unter https://mockoon.com/ (verfügbar für Windows, Linux and Docker). Geben Sie in Mockoon Port und (falls gewünscht) HTTPS-Einrichtungsdaten ein.

Starten Sie nun den Mockoon-Server.

In ServiceNow

Navigieren Sie zur Verwaltung ausgehender REST-Anrufe.

Neuen Anruf erstellen:

Endpunkt pflegen und einen neuen HTTP-Methodenaufruf erstellen:

Für den Endpunkt im obigen Bild müssen Sie entweder

<your_mockoon_server_name>:<Port>/user oder

<your_mockoon_server_ip>:<port>/user eingeben.

Die HTTP-Methode "Default_GET" wird automatisch von ServiceNow erstellt. Der Endpunkt wird automatisch von der übergeordneten Rest Message übernommen. Das bedeutet, dass die Rest-Message direkt über die HTTP-Methode getestet werden kann.

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

Im Falle eines Fehlers enthält das Feld HTTP-Status einen Wert <> 200. Die Fehlermeldung bietet in Verbindung mit dem JSON-Body der Antwort die Möglichkeit einer weiteren Analyse.

Test der Outbound-Connection vom Middleware OS nach ServiceNow

Der folgende Abschnitt beschreibt, wie SAP-Anwenderunternehmen eine ausgehende Verbindung zu ServiceNow testen können. Zunächst müssen Sie herausfinden, gegen welche ServiceNow-Basis-URL Sie Ihre ausgehende Verbindung testen. Navigieren Sie dazu zum REST API Explorer in ServiceNow.

So finden Sie Ihre API-Basis-URL. Diese wird für den entsprechenden ausgehenden Aufruf vom Middleware-OS benötigt.

n diesem Fall lautet die Basis-URL "https://devXXXXX.service-now.com/api".

Vom Middleware-Betriebssystem aus: Testen Sie, ob die ServiceNow-API erreicht werden kann.

In Linux:

curl -vi <URL>

(z. B. curl -vi https://devXXXXX.service-now.com/api)

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

HINWEIS: Der Statuscode "400 Bad Request" wird hier erwartet, da keine echte Sub-API angesprochen wurde. Wenn er zusammen mit dem korrekten JSON-Body "Requested URI does not represent any resource" auftritt, ist die Verbindung in Ordnung.

Im Fehlerfall erscheint z.B. etwas wie "Time Out" oder ein anderer Fehler wie "Bad Request" im Log. Typische Fehler können auch zertifikatsbezogen sein.

In Windows:

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

$URI = "https://XXXXXXXX.service-now.com/api";

Clear - Variable Response;

Clear - Variable ErrHead;

Clear - Variable ErrBody;

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

}

catch {
  $Response = $_.Exception.Response;

  $ErrHead = $Response.StatusCode;

  $ErrBody =
      [System.IO.StreamReader] ::new ($Response.GetResponseStream()).ReadToEnd()
};

$ErrHead;
$ErrBody

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

HINWEIS: Der Statuscode "400 Bad Request" wird hier erwartet, da keine echte Sub-API angesprochen wurde. Wenn er zusammen mit dem korrekten JSON-Body "Requested URI does not represent any resource" auftritt, ist die Verbindung in Ordnung.

Im Fehlerfall erscheint z.B. etwas wie "Time Out" oder ein anderer Fehler wie "Bad Request" im Log. Typische Fehler können auch zertifikatsbezogen sein.

Zusammenfassung

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