Alle Beiträge
Integration

S/4HANA Events mit EMIS, Teil 3: S/4HANA Private Cloud vorbereiten

In Teil 2 haben wir die BTP-Seite fertig eingerichtet: Die EMIS-Instanz wartet mit Queue und Topic-Subscription auf Events. Jetzt kommt das S/4HANA-System an die Reihe. Bei der Private Cloud Edition (PCE) gibt es dabei eine Besonderheit, die gerne unterschätzt wird: Das System gehört zwar dem Kunden, das Netzwerk aber verwaltet SAP. Bevor der erste Channel aktiviert werden kann, braucht es deshalb einen Service Request an SAP, einen Daemon-User mit der richtigen Rolle und die passende Zertifikatskette in STRUST. Genau diese drei Vorarbeiten erledigen wir in diesem Teil.

Warum bei PCE ein Service Request nötig ist

Ein S/4HANA-System in der Private Cloud Edition läuft in einer von SAP Enterprise Cloud Services (ECS) verwalteten Landschaft auf einem Hyperscaler. Der ausgehende HTTPS-Verkehr verlässt das System nicht direkt, sondern läuft über einen von SAP betriebenen Web-Proxy, typischerweise auf Port 3128. Dieser Proxy arbeitet mit einer Allowlist: Nur explizit freigeschaltete Ziel-URLs kommen durch.

Diagramm Netzwerkpfad: S/4HANA PCE über SAP-verwalteten Web-Proxy (Port 3128) zum EMIS-Messaging-Endpoint (AMQP over WebSocket); OAuth-Token-Endpoint auf der BTP bereits erreichbar
Der Outbound-Pfad aus der PCE-Landschaft: Der Messaging-Endpoint braucht die Proxy-Freischaltung, der OAuth-Token-Endpoint auf der BTP ist bereits erreichbar.

Die nummerierten Schritte im Diagramm:

  1. Das EEE-Framework baut die Verbindung auf; ausgehender HTTPS-Verkehr läuft immer über den SAP-verwalteten Web-Proxy (Port 3128).
  2. Der Messaging-Endpoint (AMQP over WebSocket, Port 443) ist nur mit Allowlist-Eintrag erreichbar; die Freischaltung erfolgt per Service Request an SAP ECS.
  3. Der OAuth-Token-Endpoint liegt auf der BTP und ist ohne Freischaltung erreichbar.

Was passiert ohne Freischaltung? Der Verbindungsversuch scheitert mit einer Meldung wie dieser im ICM-Trace:

IcmConnInitClientSSL: Proxy connection failed to
HTTP:<root URL>:443 via Proxy:3128 failed (Proxy Returned 403 Forbidden)

Das dokumentiert SAP selbst im KBA 3454314 (dort am Beispiel der Cloud-ALM-Registrierung, der Mechanismus ist derselbe). Die Folge für unser Szenario: Egal wie sauber SM59, OAuth-Client und Channel konfiguriert sind, ohne Allowlist-Eintrag bleibt die Verbindung zu EMIS tot. Und weil der Proxy von SAP betrieben wird, kann der Kunde die Freischaltung nicht selbst vornehmen. Es braucht einen Service Request an SAP ECS.

Mein Rat aus der Praxis: Diesen Request ganz an den Anfang des Projekts stellen. Die Bearbeitung dauert nach meiner Erfahrung ein bis drei Werktage; eine offizielle SAP-Zusage ist das nicht. Wer den Request erst stellt, wenn die Channel-Konfiguration ansteht, verliert genau diese Tage.

Den Service Request stellen

In SAP for Me gibt es dafür einen fertigen Request-Typ: "Allowlist Squid Proxy access HTTP/HTTPS(80/443): OUTBOUND to EXTERNAL". Eine formlose Beschreibung ist nicht nötig, das Formular fragt alle Angaben ab.

Freigeschaltet werden muss nur ein Ziel: der Messaging-Host aus messaging[amqp10ws].uri im Service Key der EMIS-Instanz (Teil 2). Er hat die Form eu10.a.eventmesh.integration.cloud.sap, wobei eu10 hier nur als Beispiel für die Region des eigenen Tenants steht. Im Formular wird allein dieser Hostname eingetragen, ohne Protokoll und ohne Port.

Der OAuth-Token-Endpoint braucht keine Freischaltung: Er liegt auf der BTP (<subdomain>.authentication.<region>.hana.ondemand.com) und ist aus der PCE-Landschaft bereits erreichbar.

Wer unsicher ist, welcher Request-Typ passt: Der eigene Technical Service Manager bei SAP hilft hier weiter.

Kundenseitige Vorbedingungen: Rollen und Daemon-User

Während der Service Request bei SAP liegt, können wir die kundenseitigen Hausaufgaben erledigen. Das Enterprise Event Enablement Framework (EEE) bringt dafür fertige Rollen mit, die SAP im Help Portal dokumentiert:

Rolle Zweck
SAP_IWXBE_RT_XBE_ADM Administrator: RFC-Destination, OAuth-Client, Logs, CCMS
SAP_IWXBE_RT_XBE_BUSI Business-Administrator: Event-Topics am Channel pflegen
SAP_IWXBE_RT_XBE_DAEMON Runtime-Rolle für den dedizierten Daemon-User
SAP_IWXBE_RT_XBE_MDT Metadaten-Administrator (Service BROWSER_SRV, Event-Discovery)

Die Rollen lassen sich in PFCG direkt zuweisen: die Admin-Rolle an die Person, die in Teil 4 die Konfiguration durchführt, die Business-Rolle an diejenigen, die später Event-Topics pflegen.

Der wichtigste Punkt ist der Daemon-User. Das EEE-Framework hält die Verbindung zu Event Mesh nicht pro Anwendersitzung offen, sondern über Daemon-Sessions: Hintergrundprozesse, die dauerhaft laufen, die Verbindung halten und Events verarbeiten. Diese Sessions laufen unter einem dedizierten technischen User, der bei der Channel-Anlage in /IWXBE/CONFIG hinterlegt wird. SAP stellt dafür die Rolle SAP_IWXBE_RT_XBE_DAEMON bereit und schreibt im Help Portal ausdrücklich, dass diese Rolle für den korrekten Start des Daemons zugewiesen sein muss.

Konkret heißt das:

  1. Technischen User anlegen (Typ System), zum Beispiel EEE_DAEMON.
  2. Rolle SAP_IWXBE_RT_XBE_DAEMON zuweisen.
  3. Den Usernamen notieren; er wird in Teil 4 bei der Channel-Anlage gebraucht.

Zertifikat-Import via STRUST

Das S/4HANA-System spricht zwei EMIS-Endpoints über TLS an: den OAuth-Token-Endpoint und den Messaging-Endpoint (AMQP over WebSocket). Damit der TLS-Handshake klappt, muss das System der Zertifikatskette dieser Endpoints vertrauen.

Der pragmatische Weg, den auch SAP-Kollegen in der Community beschreiben:

  1. Aus dem Service Key (Teil 2) den Token-Endpoint kopieren; das ist die URL im Feld oa2.tokenendpoint.
  2. Die URL im Browser öffnen. Es erscheint eine Login-Seite, aber das ist egal: Es geht nur um das Zertifikat.
  3. Über das Schloss-Symbol die Zertifikatskette anzeigen und Root- und Intermediate-Zertifikat exportieren (Base-64/PEM).
  4. In STRUST im Knoten SSL Client (Standard) beide Zertifikate importieren und in die Zertifikatsliste aufnehmen. Speichern nicht vergessen.
  5. Dasselbe für den Messaging-Host aus messaging[amqp10ws].uri prüfen. In der Regel hängen beide Endpoints an derselben Root-CA, dann ist nichts weiter zu tun.

Drei Hinweise dazu:

  • Kette statt Leaf: Nicht das Server-Zertifikat selbst importieren, sondern Root und Intermediate. Server-Zertifikate rotieren häufig, die Kette bleibt deutlich länger stabil.
  • Root-Wechsel im Blick behalten: SAP-Cloud-Endpoints nutzen DigiCert-Ketten, und DigiCert tauscht derzeit bei mehreren SAP-Diensten die Root-CA aus (Stichtage im Lauf des Jahres 2026). Beim Import also nicht blind einer Anleitung folgen, sondern die Kette nehmen, die der eigene Tenant tatsächlich präsentiert.
  • Fallback Anonymous: Vereinzelt berichten Praxisblogs, dass der Import in SSL Client (Standard) nicht griff und erst der Knoten SSL Client (Anonymous) half. Wenn der Verbindungstest später trotz korrekter Kette SSL-Fehler wirft, lohnt dieser Blick.

Nach dem Import die PSE-Änderung im ICM wirksam machen (über SMICM), damit die neue Kette beim nächsten Handshake gezogen wird.

Verifikation: Steht der Netzwerkpfad?

Sobald SAP den Request bestätigt hat, lässt sich der Pfad prüfen, ohne dass schon ein Channel existiert. Dazu legen wir die SM59-Destination an, die in Teil 4 ohnehin gebraucht wird:

  1. SM59, neue Destination, Typ G (HTTP-Verbindung zu externem Server).
  2. Zielhost: der Messaging-Host aus dem Service Key, Path Prefix /protocols/amqp10ws. Wichtig: keinen Port eintragen. In meinem Projekt kam die Verbindung mit explizit gesetztem Port nicht zustande, auch wenn der verlinkte SAP-Blog Port 443 nennt.
  3. In den HTTP-Proxy-Optionen den SAP-verwalteten Web-Proxy der PCE-Landschaft eintragen (Port 3128).
  4. Im Reiter "Anmeldung & Sicherheit": SSL aktiv, SSL-Zertifikat "DFAULT SSL Client (Standard)" (kein Tippfehler: die PSE heißt DFAULT).
  5. Verbindungstest ausführen.

Das Ergebnis richtig lesen: Der Test schickt einen unauthentifizierten Request. Bei Erfolg fragt SM59 zunächst nach Benutzername und Passwort; nach der Eingabe meldet der Test HTTP 401 (Unauthorized). Das ist hier kein Fehler, sondern das Erfolgssignal: Die Anfrage hat den Proxy passiert, der TLS-Handshake hat geklappt, und der EMIS-Endpoint hat geantwortet. Genau das wollten wir wissen. Das ist eine Praxis-Heuristik, keine offizielle SAP-Aussage; der offizielle Verbindungstest folgt in Teil 4 mit "Check Connection" in /IWXBE/CONFIG.

Kommt stattdessen ein 403 Forbidden vom Proxy (siehe ICM-Trace), fehlt die Allowlist-Freischaltung oder der Hostname im Request war unvollständig. Bei SSL-Handshake-Fehlern (ICM-Trace: SSLERR_PEER_CERT_UNTRUSTED oder ähnlich) fehlt die Zertifikatskette in STRUST, dann zurück zum vorherigen Abschnitt.

Checkliste und Ausblick

Damit ist das PCE-System vorbereitet:

  • Service Request an SAP ECS gestellt, Messaging-Host freigeschaltet
  • Admin- und Business-Rollen zugewiesen
  • Daemon-User mit Rolle SAP_IWXBE_RT_XBE_DAEMON angelegt
  • Root- und Intermediate-Zertifikat in STRUST importiert
  • SM59-Destination angelegt, Verbindungstest liefert HTTP 401
Erweitertes EMIS-Lösungsdiagramm: S/4HANA PCE mit EEE-Framework, Daemon-User, SM59-Destination und STRUST-Kette, über den SAP-Web-Proxy zu Event Mesh (Queue und Topic-Subscriptions), weiter per AMQP zum iFlow und zum Drittsystem; OAuth-Token-Endpoint (XSUAA) über den Proxy erreichbar
Das Gesamtbild aus Teil 2, erweitert um die Vorarbeiten aus diesem Teil: Daemon-User, SM59-Destination und STRUST-Kette im S/4HANA-System, dazu der freigeschaltete Weg über den Web-Proxy zu EMIS.

Die nummerierten Schritte im Diagramm:

  1. Das EEE-Framework öffnet die Verbindung aus den Daemon-Sessions heraus (User EEE_DAEMON); der Weg führt immer über den SAP-verwalteten Web-Proxy.
  2. Nach der Freischaltung erreicht das System den EMIS-Messaging-Endpoint per AMQP over WebSocket.
  3. Das OAuth-Token holt sich das System per Client-Credentials-Flow am Token-Endpoint (XSUAA).
  4. Der iFlow in Cloud Integration konsumiert die Events per AMQP aus der Queue (Teil 2).
  5. Der iFlow übergibt die Events an das Drittsystem.

In Teil 4 fügen wir alles zusammen: OAuth-Client in OA2C_CONFIG, Channel in /IWXBE/CONFIG (mit dem EMIS-spezifischen Form-Fields-Weg, denn "Create Channel via Service Key" funktioniert für EMIS noch nicht), Outbound-Binding und das erste Test-Event über /IWXBE/EEE_SUPPORT.

Quellen

Weiterführende Links