SAP S/4HANA mit Kubernetes erweitern: Side-by-Side Extensions

TL;DR

• Side-by-Side Extensions auf Kubernetes halten den S/4HANA-Core sauber und vereinfachen zukuenftige Upgrades erheblich.
• SAP Cloud Application Programming Model (CAP) laesst sich in Standard-Containern deployen und braucht keine BTP-Laufzeit zwingend.
• Die Anbindung an S/4HANA erfolgt ueber OData V2/V4 APIs oder event-basiert ueber SAP Event Mesh.
• Helm Charts und eine CI/CD-Pipeline machen Deployments reproduzierbar und ermoeglichen schnelle Iterationen.
• DSGVO-Anforderungen lassen sich durch gezieltes Hosting in EU-Regionen und Verschluesselung auf Transport- und Storage-Ebene erfuellen.

Warum Side-by-Side statt In-App Extension?

SAP bietet zwei Erweiterungsmodelle: In-App (direkt im S/4HANA-Stack via ABAP) und Side-by-Side (eigene Anwendung, die ueber APIs kommuniziert). In-App ist einfacher fuer kleine Anpassungen, aber jede Core-Modifikation wird bei S/4HANA-Upgrades zum Problem.

Die Clean-Core-Strategie ist kein theoretisches Ideal. SAP hat mit S/4HANA Cloud die Moeglichkeit fuer Core-Modifikationen stark eingeschraenkt. Wer on-premise betreibt und spaeter in die Cloud migrieren will, tut gut daran, heute schon Side-by-Side zu bauen.

Architektur-Ueberblick

Die typische Architektur sieht so aus:

S/4HANA stellt OData-Services bereit und publiziert Business Events. SAP BTP (optional) fungiert als Middleware mit Event Mesh, Connectivity Service und API Management. Der Kubernetes-Cluster hostet die eigentlichen Extension-Services.

Der Connectivity Service von SAP ist relevant, wenn S/4HANA on-premise laeuft und nicht direkt aus dem Internet erreichbar ist. Er baut ueber den SAP Cloud Connector einen Tunnel auf. Laeuft S/4HANA bereits in der Cloud oder in einem Netzwerk, das vom Kubernetes-Cluster erreichbar ist, kann die Anbindung direkt erfolgen.

Drei Integrationsmuster kommen in der Praxis vor:

Synchron via OData: Die Extension ruft S/4HANA-APIs auf, um Stammdaten zu lesen oder Belege anzulegen. Das ist der haeufigste Fall. Latenz und Fehlerbehandlung muessen sorgfaeltig implementiert werden.

Asynchron via Event Mesh: S/4HANA emittiert Business Events (z.B. "Kundenauftrag angelegt"), die ein Service im Kubernetes-Cluster konsumiert. Gut fuer Szenarien, in denen die Extension auf Aenderungen reagiert, ohne S/4HANA zu pollen.

Batch via CPI/Integration Suite: Fuer groessere Datentransfers, z.B. naechtliche Abgleiche von Materialstammdaten. Nicht elegant, aber in der Praxis oft noetig.

CAP-Anwendung containerisieren und deployen

SAP CAP (Cloud Application Programming Model) ist ein Framework fuer die Entwicklung von Business-Anwendungen. Es generiert OData-Services aus CDS-Modellen und bietet eingebaute Integration mit SAP-Services. CAP-Apps lassen sich als Docker-Container bauen und auf jedem Kubernetes-Cluster deployen.

Ein minimales Dockerfile fuer eine CAP-Anwendung (Node.js-basiert):

FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY . .
RUN npx cds build --production

FROM node:20-alpine
WORKDIR /app
COPY --from=build /app/gen/srv ./
COPY --from=build /app/node_modules ./node_modules
EXPOSE 4004
USER node
CMD ["node", "server.js"]

Multi-Stage Build haelt das finale Image klein. Der USER node-Eintrag stellt sicher, dass der Prozess nicht als Root laeuft -- wichtig fuer Pod Security Standards.

Das zugehoerige Helm Chart fuer das Deployment:

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-cap-srv
  labels:
    app.kubernetes.io/name: {{ .Release.Name }}
    app.kubernetes.io/component: cap-server
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app.kubernetes.io/name: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app.kubernetes.io/name: {{ .Release.Name }}
    spec:
      securityContext:
        runAsNonRoot: true
        fsGroup: 1000
      containers:
        - name: cap-srv
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: 4004
              name: http
          env:
            - name: CDS_ENV
              value: production
            - name: SAP_OData_URL
              valueFrom:
                secretKeyRef:
                  name: {{ .Release.Name }}-sap-credentials
                  key: odata-url
            - name: SAP_CLIENT_ID
              valueFrom:
                secretKeyRef:
                  name: {{ .Release.Name }}-sap-credentials
                  key: client-id
            - name: SAP_CLIENT_SECRET
              valueFrom:
                secretKeyRef:
                  name: {{ .Release.Name }}-sap-credentials
                  key: client-secret
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi
          livenessProbe:
            httpGet:
              path: /health
              port: http
            initialDelaySeconds: 10
          readinessProbe:
            httpGet:
              path: /health
              port: http
            initialDelaySeconds: 5

Die values.yaml dazu:

replicaCount: 2
image:
  repository: registry.example.com/sap-extension
  tag: "1.0.0"

Deployment ueber die Pipeline:

helm upgrade --install sap-extension ./charts/sap-extension \
  --namespace sap-extensions \
  --set image.tag="${CI_COMMIT_SHORT_SHA}" \
  --wait --timeout 300s

Der --wait-Parameter stellt sicher, dass der Helm-Release erst als erfolgreich gilt, wenn alle Pods ready sind. Das ist wichtig fuer CI/CD-Pipelines, die bei Fehlern abbrechen sollen.

OData-Anbindung in der Praxis

Die Kommunikation mit S/4HANA ueber OData hat Eigenheiten, die man kennen muss:

Authentifizierung: S/4HANA APIs verwenden typischerweise OAuth2 (Client Credentials Flow) oder Basic Auth ueber den Connectivity Service. Die Credentials gehoeren in Kubernetes Secrets, nicht in Environment-Variablen oder Config-Dateien.

Pagination: OData-Services liefern standardmaessig maximal 1000 Eintraege. Wer mehr braucht, muss $skip und $top oder Server-Driven Paging implementieren.

Fehlerbehandlung: S/4HANA kann mit HTTP 503 antworten, wenn das System ueberlastet ist. Retry-Logik mit Exponential Backoff ist Pflicht. Ein Circuit Breaker (z.B. via Istio oder in der Anwendung) verhindert, dass ein ausgefallenes S/4HANA den gesamten Extension-Service blockiert.

Batch Requests: OData unterstuetzt $batch-Requests, um mehrere Operationen in einer HTTP-Anfrage zu buendeln. Das reduziert Roundtrips und verbessert die Performance bei Massendatenverarbeitung.

Managed Kubernetes oder Self-Hosted?

Fuer SAP-Erweiterungen gelten dieselben Ueberlegungen wie fuer andere Workloads, mit einem Zusatz: Der Cluster muss das S/4HANA-Netzwerk erreichen koennen.

Wer S/4HANA on-premise betreibt und den Kubernetes-Cluster in der Cloud laufen lassen will, braucht eine zuverlaessige Netzwerkverbindung. Ein Site-to-Site VPN oder eine Dedicated Interconnect-Leitung sind Optionen. Der SAP Cloud Connector ist eine weitere, SAP-spezifische Loesung, die ueber SAP BTP laeuft.

Monitoring und Observability

SAP-Erweiterungen muessen anders ueberwacht werden als reine Microservices, weil ein Teil der Verarbeitungskette ausserhalb des Clusters liegt (im S/4HANA-System).

Wichtige Metriken:

• OData Response Time: Wie schnell antwortet S/4HANA auf API-Calls? Erhoehte Latenz deutet auf Lastprobleme im SAP-System hin.
• Error Rate der API-Calls: Wie viele Requests scheitern? Aufgeschluesselt nach HTTP-Statuscode.
• Event Processing Lag: Wenn Event Mesh verwendet wird: Wie gross ist die Verzoegerung zwischen Event-Emission und -Verarbeitung?
• Pod Restart Count: Haeufige Restarts deuten auf Memory Leaks oder Fehlkonfigurationen hin.

Prometheus mit Grafana eignet sich hervorragend fuer die Cluster-seitigen Metriken. Die SAP-seitigen Metriken koennen ueber den SAP Cloud ALM oder ueber Custom Exporters erfasst werden. Fuer eine umfassende Monitoring-Strategie ist der Artikel Kubernetes Monitoring: Kosten senken mit Open Source eine gute Ergaenzung.

DSGVO-Anforderungen bei SAP-Erweiterungen

SAP-Systeme verarbeiten fast immer personenbezogene Daten: Kundenstammdaten, Mitarbeiterinformationen, Lieferantenkontakte. Wenn diese Daten in eine Kubernetes-basierte Extension fliessen, gelten die DSGVO-Anforderungen auch dort.

Konkrete Massnahmen:

Datenminimierung: Die Extension sollte nur die Felder aus S/4HANA abfragen, die sie tatsaechlich braucht. Ein Reporting-Dashboard fuer Bestellvolumen braucht keine Kundenadressen.

Verschluesselung: TLS fuer alle Verbindungen zwischen Kubernetes und S/4HANA ist Pflicht. Fuer Daten, die in der Extension persistiert werden (z.B. in einer PostgreSQL-Datenbank im Cluster), muss Encryption at Rest konfiguriert sein.

Zugriffsprotokollierung: Audit Logs des Kubernetes API-Servers und Anwendungslogs muessen nachweisen, wer wann auf welche Daten zugegriffen hat.

Auftragsverarbeitungsvertrag: Wenn der Kubernetes-Cluster bei einem externen Provider laeuft, ist ein AVV erforderlich. Der Provider ist Auftragsverarbeiter im Sinne der DSGVO.

Loeschkonzept: Wenn die Extension personenbezogene Daten cached oder persistiert, muss ein Loeschkonzept existieren. Kubernetes CronJobs eignen sich, um Retention-Policies automatisiert durchzusetzen.

Haeufige Fehler bei der SAP-Kubernetes-Integration

Zu enge Kopplung an BTP. SAP BTP bietet bequeme Services, aber jede BTP-Abhaengigkeit erhoert Kosten und Vendor-Lock-in. Pruefen Sie bei jedem BTP-Service, ob eine Open-Source-Alternative existiert. Event Mesh laesst sich durch Apache Kafka ersetzen, API Management durch Kong oder ein Envoy-basiertes API Gateway.

Fehlende Retry-Logik. S/4HANA-Systeme koennen waehrend Batch-Jobs oder Upgrades langsam oder nicht erreichbar sein. Extensions ohne Retry-Logik und Circuit Breaker werden in diesen Phasen instabil.

Monolithische Extension. Manche Teams bauen eine einzige grosse Extension, die 20 verschiedene S/4HANA-Prozesse abdeckt. Das ist ein Monolith in Kubernetes-Verkleidung. Besser: Kleine, fokussierte Services, die jeweils einen Geschaeftsprozess erweitern.

Kein Schema-Versionierung. Wenn sich das OData-Schema in S/4HANA aendert (z.B. nach einem Upgrade), kann die Extension brechen. Contract Testing und Schema-Versionierung verhindern das.

Secrets in Helm values.yaml. SAP-Credentials gehoeren in Kubernetes Secrets oder einen externen Secrets Store, nicht in Helm-Konfigurationsdateien, die im Git-Repository landen.

Schrittweiser Einstieg

Ein realistischer Fahrplan fuer das erste Side-by-Side-Projekt:

Woche 1-2: Use Case definieren. Idealerweise etwas Ueberschaubares: ein Self-Service-Portal, ein Reporting-Dashboard oder ein Approval-Workflow. Den OData-Service im S/4HANA identifizieren oder anlegen.

Woche 3-4: Kubernetes-Cluster aufsetzen (oder Managed Service beauftragen). CAP-Projekt initialisieren, CDS-Modell erstellen, lokale Entwicklung mit cds watch.

Woche 5-6: Containerisierung, Helm Chart erstellen, CI/CD-Pipeline konfigurieren. Erstes Deployment auf einen Staging-Cluster.

Woche 7-8: Integration mit S/4HANA testen. OData-Anbindung, Authentifizierung, Fehlerbehandlung. Lasttests durchfuehren.

Woche 9-10: Monitoring einrichten, Security Review (RBAC, Network Policies, Image Scanning). DSGVO-Check: Wo werden personenbezogene Daten verarbeitet?

Woche 11-12: Go-Live der ersten Extension. Dokumentation, Wissenstransfer ans Team, Retrospektive.

Weiterführende Artikel

• Kubernetes Hosting Kosten: Cloud vs On-Premise hilft bei der Entscheidung fuer das richtige Hosting-Modell.
• Kubernetes CI/CD im Enterprise-Umfeld zeigt Pipeline-Patterns fuer groessere Teams.
• Kubernetes Storage: DSGVO-konforme Loesungen behandelt Persistent Volumes und Backup-Strategien.
• Cloud-Native Migration beschreibt den Migrationspfad von Legacy-Anwendungen.

Sie planen, Ihr S/4HANA-System mit Kubernetes-basierten Extensions zu erweitern, und suchen Unterstuetzung bei Architektur, Implementierung oder Betrieb? Kontaktieren Sie uns unter /kontakt fuer ein unverbindliches Gespraech.