TL;DR

• Handelsunternehmen brauchen ERP-Integration (SAP, Microsoft Dynamics) als Rueckgrat ihrer IT -- auf Kubernetes laesst sich das ohne interne Middleware-Spezialisten loesen
• API-Gateway-Patterns ersetzen klassische ESB-Middleware und reduzieren Komplexitaet und Lizenzkosten
• SAP-Anbindung per RFC/BAPI oder OData laeuft als containerisierter Connector mit definierten SLAs
• Der Fachkraeftemangel bei Integrationsspezialisten macht Self-Managed-Ansaetze fuer den Mittelstand unrealistisch
• Managed Kubernetes mit Integrations-Expertise liefert stabile ERP-Kopplung ab dem ersten Tag

Kubernetes fuer Handelsunternehmen: ERP-Anbindung ohne Middleware-Experten

Handelsunternehmen im Mittelstand -- ob Grosshandel, Fachhandel oder Handelsgruppe -- leben von reibungslosen Prozessen: Bestellung, Lagerhaltung, Kommissionierung, Versand, Retoure. All diese Prozesse laufen ueber das ERP-System. Und genau hier wird es kompliziert.

Die Anbindung von E-Commerce-Plattformen, Warenwirtschaft, Logistikpartnern und POS-Systemen an SAP oder Microsoft Dynamics ist technisch anspruchsvoll. Klassische Middleware (SAP PI/PO, BizTalk, MuleSoft) erfordert teure Spezialisten, die auf dem Arbeitsmarkt kaum zu finden sind. Kubernetes bietet einen modernen Weg, diese Integrationen zuverlaessig und wartbar zu betreiben.

Die Integrations-Herausforderung im Handel

Ein typisches Handelsunternehmen mit 500 Mitarbeitern hat 15 bis 30 Systeme, die miteinander kommunizieren muessen. Das ERP-System steht im Zentrum, aber drumherum gibt es einen Zoo aus Spezialsystemen.

Typische Systemlandschaft

Das Problem mit klassischer Middleware

Traditionell werden diese Integrationen ueber einen Enterprise Service Bus (ESB) oder eine Integrationsplattform geloest:

Das gemeinsame Problem: Alle diese Loesungen erfordern spezialisierte Middleware-Experten. Ein SAP PI/PO-Berater kostet 1.400-1.800 EUR/Tag. Ein MuleSoft-Entwickler ist in Deutschland schwer unter 90.000 EUR/Jahr zu bekommen. Fuer ein Handelsunternehmen mit 500 Mitarbeitern ist das kaum tragbar.

API-Gateway-Pattern als Alternative

Auf Kubernetes laesst sich die ERP-Integration ueber ein API-Gateway-Pattern loesen. Statt eines monolithischen ESB gibt es kleine, spezialisierte Connector-Services, die ueber ein zentrales Gateway kommunizieren.

Architektur: API-Gateway statt ESB

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-gateway
  namespace: erp-integration
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-gateway
  template:
    metadata:
      labels:
        app: api-gateway
    spec:
      containers:
      - name: gateway
        image: registry.internal/api-gateway:v4.1.0
        ports:
        - containerPort: 8443
          name: https
        env:
        - name: RATE_LIMIT_PER_SECOND
          value: "500"
        - name: CIRCUIT_BREAKER_THRESHOLD
          value: "5"
        - name: CIRCUIT_BREAKER_TIMEOUT_S
          value: "30"
        - name: TLS_ENABLED
          value: "true"
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "1"
            memory: "1Gi"
        livenessProbe:
          httpGet:
            path: /health
            port: 8443
            scheme: HTTPS
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8443
            scheme: HTTPS
          periodSeconds: 5

Die Circuit-Breaker-Konfiguration ist fuer ERP-Integrationen entscheidend: Wenn SAP nicht antwortet, darf das nicht die gesamte Systemlandschaft lahmlegen. Nach 5 fehlgeschlagenen Aufrufen oeffnet der Circuit Breaker und liefert eine kontrollierte Fehlermeldung statt endloser Timeouts.

SAP-Connector auf Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sap-connector
  namespace: erp-integration
  labels:
    integration: sap
    protocol: rfc
spec:
  replicas: 2
  selector:
    matchLabels:
      app: sap-connector
  template:
    metadata:
      labels:
        app: sap-connector
    spec:
      containers:
      - name: connector
        image: registry.internal/sap-connector:v2.3.0
        env:
        - name: SAP_HOST
          valueFrom:
            secretKeyRef:
              name: sap-credentials
              key: host
        - name: SAP_CLIENT
          value: "100"
        - name: SAP_SYSTEM_NUMBER
          value: "00"
        - name: CONNECTION_POOL_SIZE
          value: "10"
        - name: RETRY_MAX_ATTEMPTS
          value: "3"
        - name: RETRY_BACKOFF_MS
          value: "1000"
        ports:
        - containerPort: 8080
          name: http
        - containerPort: 9090
          name: metrics
        volumeMounts:
        - name: sap-jco-lib
          mountPath: /opt/sap/lib
          readOnly: true
      volumes:
      - name: sap-jco-lib
        secret:
          secretName: sap-jco-libraries

Der SAP-Connector nutzt einen Connection Pool mit 10 persistenten Verbindungen. Das vermeidet den Overhead von staendigem Verbindungsaufbau und entlastet das SAP-System. Die Retry-Logik mit exponentiellem Backoff faengt kurze Ausfaelle ab.

Microsoft Dynamics Connector

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dynamics-connector
  namespace: erp-integration
  labels:
    integration: dynamics
    protocol: odata
spec:
  replicas: 2
  selector:
    matchLabels:
      app: dynamics-connector
  template:
    metadata:
      labels:
        app: dynamics-connector
    spec:
      containers:
      - name: connector
        image: registry.internal/dynamics-connector:v1.5.0
        env:
        - name: DYNAMICS_TENANT_ID
          valueFrom:
            secretKeyRef:
              name: dynamics-credentials
              key: tenant-id
        - name: DYNAMICS_ENVIRONMENT
          value: "production"
        - name: ODATA_BATCH_SIZE
          value: "100"
        - name: OAUTH_SCOPE
          value: "https://org.api.crm.dynamics.com/.default"
        - name: CHANGE_TRACKING_ENABLED
          value: "true"
        ports:
        - containerPort: 8080
          name: http
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

Typische Integrations-Szenarien im Handel

1. Auftragsintegration: Online-Shop zu ERP

Der haeufigste Use Case: Bestellungen aus dem Online-Shop muessen in Echtzeit ins ERP-System.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-sync
  namespace: erp-integration
spec:
  replicas: 2
  selector:
    matchLabels:
      app: order-sync
  template:
    metadata:
      labels:
        app: order-sync
    spec:
      containers:
      - name: sync
        image: registry.internal/order-sync:v3.0.1
        env:
        - name: SOURCE_SYSTEM
          value: "shopware"
        - name: TARGET_SYSTEM
          value: "sap-sd"
        - name: SYNC_MODE
          value: "event-driven"
        - name: DEAD_LETTER_QUEUE
          value: "true"
        - name: MAX_PROCESSING_TIME_S
          value: "30"
        - name: IDEMPOTENCY_CHECK
          value: "true"

Zwei Aspekte sind hier kritisch: Die Dead Letter Queue faengt Auftraege auf, die nicht verarbeitet werden koennen, statt sie zu verlieren. Die Idempotency-Pruefung verhindert doppelte Auftraege bei Retry-Szenarien.

2. Bestandssynchronisation

Bestaende muessen zwischen ERP, Online-Shop und Marktplaetzen synchron sein. Eine Ueberverkauf-Situation kostet Kundenvertrauen und verursacht Stornierungskosten.

3. Marktplatz-Anbindung

Amazon, Otto, Zalando -- jeder Marktplatz hat eigene APIs und Anforderungen:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: marketplace-connector
  namespace: erp-integration
spec:
  replicas: 2
  selector:
    matchLabels:
      app: marketplace-connector
  template:
    metadata:
      labels:
        app: marketplace-connector
    spec:
      containers:
      - name: connector
        image: registry.internal/marketplace-hub:v2.1.0
        env:
        - name: MARKETPLACES
          value: "amazon-de,otto,zalando"
        - name: ARTICLE_SYNC_INTERVAL_MIN
          value: "30"
        - name: ORDER_POLL_INTERVAL_S
          value: "60"
        - name: INVENTORY_UPDATE_MODE
          value: "delta"
        ports:
        - containerPort: 8080

Monitoring und Alerting fuer ERP-Integrationen

ERP-Integrationen muessen ueberwacht werden. Eine fehlgeschlagene Auftragsuebergabe, die erst am naechsten Morgen auffaellt, bedeutet verzoegerte Lieferungen und unzufriedene Kunden.

Integration-Health-Dashboard

apiVersion: v1
kind: ConfigMap
metadata:
  name: integration-alerts
  namespace: monitoring
data:
  alerts.yaml: |
    groups:
    - name: erp-integration
      rules:
      - alert: SAPConnectorDown
        expr: up{job="sap-connector"} == 0
        for: 2m
        labels:
          severity: critical
          team: integration
        annotations:
          summary: "SAP-Connector nicht erreichbar"
          description: "Der SAP-Connector antwortet seit 2 Minuten nicht"

      - alert: OrderSyncBacklog
        expr: order_sync_queue_depth > 100
        for: 5m
        labels:
          severity: warning
          team: integration
        annotations:
          summary: "Auftrags-Backlog ueber 100"
          description: "Die Auftrags-Synchronisation hat einen Rueckstau"

      - alert: IntegrationErrorRate
        expr: rate(integration_errors_total[5m]) > 0.05
        for: 3m
        labels:
          severity: warning
        annotations:
          summary: "Fehlerrate ueber 5%"

Zum Thema Monitoring und Alerting auf Kubernetes allgemein: Kubernetes Monitoring und Observability.

Fachkraeftemangel: Warum Integrationsspezialisten fehlen

Der Arbeitsmarkt fuer Integrationsspezialisten ist in Deutschland besonders angespannt:

Die Kombination aus ERP-Wissen, Integrationsexpertise und Container-Know-how ist auf dem Markt nahezu nicht zu finden. Fuer ein Handelsunternehmen mit 500 Mitarbeitern ist es unrealistisch, diese Kompetenz intern aufzubauen und zu halten.

Mehr zu den Herausforderungen beim Aufbau interner Teams unter Kubernetes Team aufbauen: Was es wirklich kostet.

Managed Service: Integration als Service

Ein Managed Kubernetes Service mit Integrations-Expertise loest dieses Dilemma. Der Anbieter bringt sowohl die Kubernetes-Kompetenz als auch das ERP-Integrationswissen mit.

Was ein Managed Service fuer den Handel leisten muss

Kostenvergleich

Der Managed-Service-Ansatz ist nicht nur guenstiger, sondern eliminiert auch das Risiko des Wissensverlusts bei Kuendigungen. Eine detaillierte Betrachtung unter Managed Service vs. Inhouse im Vergleich.

Migration: Vom ESB zu Kubernetes-basierten Integrationen

Die Migration von einer bestehenden Middleware zu Kubernetes muss schrittweise erfolgen. Ein Big-Bang-Ansatz ist im Handel zu riskant -- jede Stunde ohne funktionierende ERP-Integration kostet Umsatz.

Migrations-Phasen

Reihenfolge der Migration

Die Reihenfolge ist entscheidend. Einfache, weniger kritische Integrationen zuerst:

1. BI/Reporting-Feeds -- Unkritisch, Fehler fallen nicht sofort auf
2. CRM-Synchronisation -- Wichtig, aber keine Echtzeitanforderung
3. Bestandssynchronisation -- Geschaeftskritisch, aber gut testbar
4. Auftragsintegration -- Hochkritisch, zuletzt migrieren
5. Marktplatz-Anbindung -- Nach stabiler Auftragsintegration

Sicherheit: DSGVO und Datenschutz bei ERP-Integrationen

ERP-Systeme enthalten personenbezogene Daten: Kundennamen, Adressen, Bestellhistorien. Die Integration muss DSGVO-konform sein.

Network Policies fuer ERP-Namespaces

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: erp-isolation
  namespace: erp-integration
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          tier: frontend
    ports:
    - protocol: TCP
      port: 8443
  egress:
  - to:
    - ipBlock:
        cidr: 10.50.0.0/24  # SAP-Netzwerk
    ports:
    - protocol: TCP
      port: 3300  # SAP RFC
    - protocol: TCP
      port: 8000  # SAP HTTP
  - to:
    - namespaceSelector:
        matchLabels:
          name: monitoring

Mehr zum Thema DSGVO-Compliance unter Kubernetes DSGVO-Compliance.

Fazit

ERP-Integration auf Kubernetes ist fuer Handelsunternehmen der pragmatische Weg aus dem Middleware-Dilemma. API-Gateway-Patterns ersetzen teure ESB-Loesungen, containerisierte Connectoren sind wartbar und skalierbar, und ein Managed Service liefert die fehlende Integrations-Expertise.

Der Schluessel liegt in der schrittweisen Migration: Nicht alles auf einmal umstellen, sondern Integration fuer Integration migrieren. Mit dem richtigen Partner ist das in drei bis sechs Monaten machbar.

Verwandte Artikel

• Kubernetes im Einzelhandel: E-Commerce und POS-Systeme
• Kubernetes Kosten: Intern vs. Extern im Vergleich
• Kubernetes SAP-Integration
• Kubernetes Integration Patterns
• Kubernetes E-Commerce: Black-Friday-Skalierung

Ihr Handelsunternehmen braucht zuverlaessige ERP-Integration ohne interne Middleware-Experten? Kontaktieren Sie uns unter /kontakt fuer eine kostenlose Erstberatung -- wir bringen Kubernetes und ERP-Expertise zusammen.