Veröffentlicht am

Kubernetes EDI-Anbindung für Maschinenbau-Zulieferer

Teilen:
Authors

TL;DR

  • OEMs fordern von Zulieferern elektronischen Datenaustausch per EDI (EDIFACT, VDA-Standards) -- ohne EDI keine Auftraege
  • EDI-Integration ist technisch komplex: AS2, OFTP2, verschiedene Nachrichtenformate und OEM-spezifische Profile
  • Auf Kubernetes lassen sich EDI-Connectoren als Container betreiben -- wartbar, skalierbar und ueberwachbar
  • EDI-Spezialisten sind auf dem Arbeitsmarkt kaum verfuegbar, was Mittelstaendler vor grosse Probleme stellt
  • Ein Managed Service mit EDI- und Kubernetes-Expertise ist fuer Zulieferer mit 100 bis 1.000 Mitarbeitern die wirtschaftlichste Loesung

Kubernetes fuer Maschinenbau-Zulieferer: EDI-Anbindung OEMs ohne Spezialwissen

Maschinenbau-Zulieferer kennen das Problem: Der OEM schickt eine Mail mit dem Betreff "EDI-Anbindung bis Q3 erforderlich" und ploetzlich steht ein Projekt an, fuer das intern weder Know-how noch Personal vorhanden ist. EDIFACT, VDA 4905, AS2, OFTP2 -- fuer die meisten IT-Abteilungen im Mittelstand sind das Fremdwoerter.

Gleichzeitig ist die Konsequenz klar: Ohne EDI-Anbindung keine Lieferabrufe, keine automatisierten Bestellungen, kein Geschaeft mit dem OEM. Dieser Artikel zeigt, wie Zulieferer EDI-Integrationen auf Kubernetes betreiben -- zuverlaessig, wartbar und ohne internes EDI-Team.

EDI im Maschinenbau: Was OEMs fordern

Electronic Data Interchange (EDI) ist der standardisierte elektronische Austausch von Geschaeftsdokumenten zwischen Unternehmen. Im Maschinenbau ist EDI fuer die Zusammenarbeit mit grossen OEMs Pflicht.

Gaengige EDI-Standards

StandardVerbreitungTypische Verwendung
EDIFACT (UN/CEFACT)InternationalBestellungen, Lieferscheine, Rechnungen
VDA 4905Deutsche AutomobilindustrieLieferabrufe
VDA 4913Deutsche AutomobilindustrieLieferscheine
VDA 4915Deutsche AutomobilindustrieFeinabrufe
ANSI X12NordamerikaBestellungen (850), Rechnungen (810)
ODETTEEuropaeische AutomobilindustrieTransportavise

OEM-spezifische Anforderungen

Jeder OEM hat eigene Anforderungen an Format, Protokoll und Prozess:

OEMEDI-StandardTransportprotokollBesonderheiten
VolkswagenVDA + EDIFACTOFTP2Eigenenes Lieferanten-Portal
BMWVDA + EDIFACTOFTP2Strenge Zeitfenster
BoschEDIFACTAS2Mehrere Nachrichtentypen
SiemensEDIFACTAS2/HTTPSGlobale Standards
Daimler/MercedesVDA + EDIFACTOFTP2OEM-spezifische Erweiterungen
John DeereANSI X12AS2Nordamerikanischer Standard

Typische EDI-Nachrichtentypen

EDIFACT-TypVDA-AequivalentInhaltRichtung
DELFORVDA 4905Lieferabruf/ForecastOEM zu Zulieferer
DELJITVDA 4915Feinabruf (JIT)OEM zu Zulieferer
DESADVVDA 4913Lieferschein/ASNZulieferer zu OEM
INVOICVDA 4906RechnungZulieferer zu OEM
ORDERS--BestellungOEM zu Zulieferer
ORDCHG--BestellaenderungOEM zu Zulieferer

Transportprotokolle: AS2 und OFTP2

EDI-Nachrichten werden nicht per E-Mail verschickt. Es gibt spezialisierte Transportprotokolle mit Empfangsbestaetigung, Verschluesselung und Nichtabstreitbarkeit.

AS2 (Applicability Statement 2)

AS2 nutzt HTTP/S als Transportschicht und bietet:

  • Verschluesselung (S/MIME)
  • Digitale Signaturen
  • MDN (Message Disposition Notification) als Empfangsbestaetigung
  • Synchrone und asynchrone Zustellung

OFTP2 (Odette File Transfer Protocol 2)

OFTP2 ist in der europaeischen Automobilindustrie Standard:

  • TLS-Verschluesselung
  • Grosse Dateien (kein Groeenlimit)
  • Automatische Wiederaufnahme bei Verbindungsabbruch
  • EERP (End-to-End Response) als Empfangsbestaetigung
  • Kompression

AS2-Connector auf Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: as2-connector
  namespace: edi-integration
  labels:
    protocol: as2
spec:
  replicas: 2
  selector:
    matchLabels:
      app: as2-connector
  template:
    metadata:
      labels:
        app: as2-connector
    spec:
      containers:
      - name: as2
        image: registry.internal/as2-server:v3.2.0
        ports:
        - containerPort: 8443
          name: https
        - containerPort: 9090
          name: metrics
        env:
        - name: AS2_STATION_ID
          value: "ZULIEFERER-AG"
        - name: MDN_MODE
          value: "sync"
        - name: ENCRYPTION_ALGORITHM
          value: "AES256"
        - name: SIGNATURE_ALGORITHM
          value: "SHA256"
        - name: MESSAGE_STORE_PATH
          value: "/data/messages"
        - name: RETRY_COUNT
          value: "3"
        - name: RETRY_INTERVAL_MIN
          value: "15"
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "1"
            memory: "1Gi"
        volumeMounts:
        - name: as2-certs
          mountPath: /etc/as2/certs
          readOnly: true
        - name: message-store
          mountPath: /data/messages
      volumes:
      - name: as2-certs
        secret:
          secretName: as2-certificates
      - name: message-store
        persistentVolumeClaim:
          claimName: edi-message-store

OFTP2-Connector auf Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: oftp2-connector
  namespace: edi-integration
  labels:
    protocol: oftp2
spec:
  replicas: 2
  selector:
    matchLabels:
      app: oftp2-connector
  template:
    metadata:
      labels:
        app: oftp2-connector
    spec:
      containers:
      - name: oftp2
        image: registry.internal/oftp2-server:v2.5.0
        ports:
        - containerPort: 6619
          name: oftp2-tls
        - containerPort: 9090
          name: metrics
        env:
        - name: OFTP2_SSID
          value: "O0177ZULIEFERER-AG"
        - name: OFTP2_PASSWORD
          valueFrom:
            secretKeyRef:
              name: oftp2-credentials
              key: password
        - name: TLS_VERSION
          value: "1.3"
        - name: EERP_ENABLED
          value: "true"
        - name: COMPRESSION
          value: "zlib"
        - name: RESTART_ENABLED
          value: "true"
        - name: MAX_RECORD_SIZE
          value: "131072"
        volumeMounts:
        - name: oftp2-certs
          mountPath: /etc/oftp2/certs
          readOnly: true
        - name: message-store
          mountPath: /data/messages
      volumes:
      - name: oftp2-certs
        secret:
          secretName: oftp2-certificates
      - name: message-store
        persistentVolumeClaim:
          claimName: edi-message-store

Die RESTART_ENABLED-Option ist fuer grosse EDI-Dateien wichtig: Bei einem Verbindungsabbruch wird die Uebertragung an der Stelle fortgesetzt, an der sie unterbrochen wurde. Das spart Bandbreite und Zeit.

EDI-Nachrichtenverarbeitung auf Kubernetes

Neben dem Transport muessen EDI-Nachrichten geparsed, validiert, transformiert und ins ERP-System uebertragen werden.

Verarbeitungs-Pipeline

apiVersion: apps/v1
kind: Deployment
metadata:
  name: edi-processor
  namespace: edi-integration
spec:
  replicas: 3
  selector:
    matchLabels:
      app: edi-processor
  template:
    metadata:
      labels:
        app: edi-processor
    spec:
      containers:
      - name: processor
        image: registry.internal/edi-processor:v4.0.1
        env:
        - name: INPUT_QUEUE
          value: "edi-inbound"
        - name: OUTPUT_QUEUE
          value: "erp-import"
        - name: ERROR_QUEUE
          value: "edi-errors"
        - name: VALIDATION_STRICT
          value: "true"
        - name: MAPPING_CONFIG_PATH
          value: "/config/mappings"
        - name: DUPLICATE_CHECK
          value: "true"
        - name: ARCHIVE_ENABLED
          value: "true"
        - name: ARCHIVE_RETENTION_DAYS
          value: "3650"
        ports:
        - containerPort: 8080
          name: http
        - containerPort: 9090
          name: metrics
        volumeMounts:
        - name: mapping-config
          mountPath: /config/mappings
          readOnly: true
      volumes:
      - name: mapping-config
        configMap:
          name: edi-mapping-configs

Die ARCHIVE_RETENTION_DAYS: 3650 (10 Jahre) ist kein Zufall. Handelsrechtliche Aufbewahrungspflichten verlangen die Archivierung von Geschaeftsdokumenten fuer 10 Jahre. EDI-Nachrichten sind Geschaeftsdokumente.

EDI-Mapping: OEM-spezifische Transformation

Jeder OEM verwendet leicht unterschiedliche EDI-Profile. Ein Lieferabruf von VW sieht anders aus als einer von BMW, auch wenn beide auf VDA 4905 basieren.

apiVersion: v1
kind: ConfigMap
metadata:
  name: edi-mapping-configs
  namespace: edi-integration
data:
  vw-delfor.yaml: |
    source: EDIFACT-DELFOR-D96A
    target: SAP-IDOC-DELFOR
    oem: volkswagen
    mappings:
      - source-segment: BGM
        target-field: BELNR
        description: "Dokumentennummer"
      - source-segment: DTM+137
        target-field: BEDAT
        description: "Dokumentendatum"
      - source-segment: NAD+BY
        target-field: KUNNR
        description: "Kundennummer VW"
      - source-segment: LIN
        target-field: MATNR
        description: "Materialnummer"
      - source-segment: QTY+1
        target-field: MENGE
        description: "Abrufmenge"

  bmw-delfor.yaml: |
    source: EDIFACT-DELFOR-D97A
    target: SAP-IDOC-DELFOR
    oem: bmw
    mappings:
      - source-segment: BGM
        target-field: BELNR
        description: "Dokumentennummer"
      - source-segment: DTM+137
        target-field: BEDAT
        description: "Dokumentendatum"
      - source-segment: NAD+BY
        target-field: KUNNR
        description: "Kundennummer BMW"
        transformation: "prefix:BMW-"

Monitoring: EDI-Ausfaelle frueh erkennen

Ein fehlgeschlagener EDI-Austausch kann dazu fuehren, dass Lieferabrufe nicht ankommen und Lieferungen nicht rechtzeitig versandt werden. Das Monitoring muss EDI-spezifische Metriken ueberwachen.

EDI-spezifische Alerts

apiVersion: v1
kind: ConfigMap
metadata:
  name: edi-alerts
  namespace: monitoring
data:
  alerts.yaml: |
    groups:
    - name: edi-monitoring
      rules:
      - alert: EDIConnectionDown
        expr: edi_connection_status{protocol="oftp2"} == 0
        for: 5m
        labels:
          severity: critical
          team: edi
        annotations:
          summary: "OFTP2-Verbindung zu OEM unterbrochen"
          description: "Keine Verbindung zu {{ $labels.partner }} seit 5 Minuten"

      - alert: EDIProcessingErrors
        expr: rate(edi_processing_errors_total[15m]) > 0
        for: 1m
        labels:
          severity: warning
          team: edi
        annotations:
          summary: "EDI-Verarbeitungsfehler"
          description: "Fehler bei Verarbeitung von {{ $labels.message_type }}"

      - alert: EDINoMessagesReceived
        expr: time() - edi_last_message_received_timestamp > 86400
        labels:
          severity: warning
          team: edi
        annotations:
          summary: "Seit 24h keine EDI-Nachrichten empfangen"
          description: "Partner {{ $labels.partner }}: Letzter Empfang vor ueber 24h"

      - alert: EDIMDNPending
        expr: edi_mdn_pending_count > 0
        for: 30m
        labels:
          severity: warning
        annotations:
          summary: "Ausstehende MDN-Bestaetigungen"

Der Alert EDINoMessagesReceived ist besonders wichtig: Wenn ein OEM ploetzlich keine Lieferabrufe mehr schickt, kann das auf ein Konfigurationsproblem hindeuten. Ohne diesen Alert wuerde das erst auffallen, wenn die Produktion stillsteht.

Grundlagen zum Monitoring auf Kubernetes unter Kubernetes Monitoring und Observability.

Warum EDI-Spezialisten fehlen

EDI ist eine Nischenkompetenz. Die Technologie existiert seit den 1970er Jahren, aber die Zahl der Experten schrumpft:

FaktorAuswirkung
Demografischer WandelViele EDI-Experten gehen in Rente
Fehlende AusbildungKein Studiengang lehrt EDI explizit
Geringe AttraktivitaetJunge Entwickler bevorzugen moderne Technologien
NischenmarktWenige Anbieter, wenige Berater
OEM-spezifisches WissenJeder OEM hat eigene Anforderungen

Fuer einen Maschinenbau-Zulieferer mit 300 Mitarbeitern ist es praktisch unmoeglich, einen EDI-Spezialisten einzustellen und zu halten. Die Gehaelter in Grosskonzernen und bei Beratungshaeusern sind hoeher, und die Aufgabe ist im Mittelstand oft nur eine Teilzeitbeschaeftigung.

Managed Service: EDI-Integration als Service

Ein Managed Kubernetes Service mit EDI-Expertise loest das Problem: Der Anbieter betreibt die EDI-Infrastruktur auf Kubernetes und bringt das noetige Fachwissen mit.

Was ein Managed EDI Service leisten muss

LeistungBeschreibung
Protokoll-SupportAS2, OFTP2, HTTPS, SFTP
Format-SupportEDIFACT, VDA, ANSI X12, CSV, XML
OEM-OnboardingEinrichtung neuer OEM-Verbindungen
Mapping-EntwicklungOEM-spezifische Nachrichtentransformation
ERP-IntegrationAnbindung an SAP, Dynamics, proALPHA
Monitoring24/7-Ueberwachung aller EDI-Verbindungen
FehlerbehandlungAnalyse und Behebung von Mapping-Fehlern
ComplianceArchivierung, GoBD-Konformitaet

Kostenvergleich: EDI-Loesungen

AnsatzEinmalige KostenLaufende Kosten/JahrRisiko
Interner EDI-Spezialist20.000 EUR (Einarbeitung)80.000-100.000 EURKuendigung, Bus-Faktor 1
EDI-Dienstleister (klassisch)15.000-30.000 EUR (Setup)24.000-60.000 EURLock-in, intransparente Kosten
Cloud-EDI-SaaS5.000-10.000 EUR12.000-36.000 EURDatenhoheit, Abhaengigkeit
Managed Kubernetes + EDI10.000-20.000 EUR48.000-84.000 EURAnbieterabhaengigkeit

Der Managed-Kubernetes-Ansatz liegt auf den ersten Blick nicht am guenstigsten. Der entscheidende Vorteil: Die EDI-Integration laeuft auf derselben Plattform wie alle anderen Workloads. Es gibt keine separate EDI-Blackbox, sondern transparente, ueberwachbare Container-Workloads. Aenderungen an Mappings und Konfigurationen liegen in Git und sind nachvollziehbar.

Mehr zur Entscheidung zwischen internem Betrieb und Managed Service unter Kubernetes Freelancer vs. Managed Service.

Praxisbeispiel: Zulieferer mit 5 OEM-Anbindungen

Ausgangslage

  • Maschinenbau-Zulieferer, 350 Mitarbeiter
  • 5 OEM-Kunden: VW, BMW, Bosch, Siemens, ein US-amerikanischer OEM
  • Bestehende EDI-Loesung: Lokaler EDI-Konverter (einzelner Windows-Server)
  • Problem: EDI-Administrator geht in Rente, kein Nachfolger

Loesung mit Managed Kubernetes

KomponenteImplementierung
Kubernetes-ClusterOn-Premises, 3 Master + 4 Worker Nodes
AS2-ConnectorContainer-Deployment, 2 Replicas
OFTP2-ConnectorContainer-Deployment, 2 Replicas
EDI-Processor3 Replicas, Message-Queue-basiert
SAP-ConnectorRFC-basiert, Connection Pool
MonitoringPrometheus + Grafana, OEM-spezifische Dashboards
ArchivierungS3-kompatibel, 10 Jahre Retention

Migration

Die Migration von der alten EDI-Loesung auf Kubernetes erfolgte OEM fuer OEM:

WocheAktion
1-2Setup Kubernetes-Cluster, Basis-Infrastruktur
3-4Siemens (AS2) -- einfachste Anbindung zuerst
5-6Bosch (AS2) -- aehnliches Setup wie Siemens
7-8US-OEM (AS2, ANSI X12) -- anderes Format
9-12VW (OFTP2) -- komplexeste Anbindung
13-14BMW (OFTP2) -- nach VW-Erfahrung schneller
15-16Parallelbetrieb, Tests, Dekommissionierung alt

Ergebnisse

MetrikVorherNachher
EDI-Ausfaelle/Jahr8-121
Mittlere Ausfallzeit4-8 Stunden15 Minuten
Personalabhaengigkeit1 PersonManaged Service
Neue OEM-Anbindung6-8 Wochen2-3 Wochen
TransparenzBlackboxVoll ueberwacht
ArchivierungManuell, lueckenhaftAutomatisch, GoBD-konform

Sicherheit: EDI-Daten schuetzen

EDI-Nachrichten enthalten geschaeftskritische Informationen: Preise, Mengen, Liefertermine. Der Schutz dieser Daten ist essenziell.

Network Policy fuer EDI-Namespace

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: edi-isolation
  namespace: edi-integration
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0
    ports:
    - protocol: TCP
      port: 8443   # AS2
    - protocol: TCP
      port: 6619   # OFTP2
  egress:
  - to:
    - ipBlock:
        cidr: 10.50.0.0/24  # SAP-Netzwerk
    ports:
    - protocol: TCP
      port: 3300
  - to:
    - namespaceSelector:
        matchLabels:
          name: monitoring
    ports:
    - protocol: TCP
      port: 9090
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
    ports:
    - protocol: TCP
      port: 443   # AS2 ausgehend
    - protocol: TCP
      port: 6619  # OFTP2 ausgehend

Checkliste: EDI auf Kubernetes einfuehren

Vor dem Start eines EDI-Projekts auf Kubernetes sollten diese Fragen beantwortet sein:

  • Welche OEMs muessen angebunden werden und welche Protokolle fordern sie?
  • Welche EDI-Nachrichtentypen werden ausgetauscht (DELFOR, DESADV, INVOIC)?
  • Gibt es OEM-spezifische Anforderungen an Zertifikate und Verschluesselung?
  • Welches ERP-System ist im Einsatz und wie sieht die Schnittstelle aus?
  • Muessen EDI-Nachrichten archiviert werden (GoBD)?
  • Gibt es zeitkritische Nachrichtentypen (JIT-Abrufe)?
  • Ist ein 24/7-Betrieb erforderlich?

Wer sich ueber die generelle Kubernetes-Einfuehrung informieren will, findet einen Ueberblick unter Kubernetes fuer Entscheider.

Fazit

EDI-Integration auf Kubernetes ist fuer Maschinenbau-Zulieferer der Weg aus der Abhaengigkeit von einzelnen EDI-Spezialisten und proprietaeren Blackbox-Loesungen. AS2- und OFTP2-Connectoren laufen als Container-Workloads, EDI-Mappings liegen in Git, und das Monitoring zeigt den Status jeder OEM-Verbindung in Echtzeit.

Fuer Mittelstaendler mit 100 bis 1.000 Mitarbeitern ist ein Managed Service die pragmatischste Loesung. Die Kosten sind kalkulierbar, das Risiko des Wissensverlusts entfaellt, und neue OEM-Anbindungen sind in Wochen statt Monaten realisierbar.


Verwandte Artikel


Ihr Unternehmen braucht zuverlaessige EDI-Anbindung an OEMs -- ohne internes EDI-Team? Kontaktieren Sie uns unter /kontakt fuer eine kostenlose Erstberatung. Wir bringen Kubernetes-Betrieb und EDI-Expertise zusammen.

Kubernetes-Beratung gesucht?

Wir helfen deutschen Unternehmen bei der Kubernetes-Implementierung, Migration und Optimierung. DSGVO-konform und praxiserprobt.

📖 Verwandte Artikel

Weitere interessante Beiträge zu ähnlichen Themen