- Authors

- Name
- Phillip Pham
- @ddppham
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
| Standard | Verbreitung | Typische Verwendung |
|---|---|---|
| EDIFACT (UN/CEFACT) | International | Bestellungen, Lieferscheine, Rechnungen |
| VDA 4905 | Deutsche Automobilindustrie | Lieferabrufe |
| VDA 4913 | Deutsche Automobilindustrie | Lieferscheine |
| VDA 4915 | Deutsche Automobilindustrie | Feinabrufe |
| ANSI X12 | Nordamerika | Bestellungen (850), Rechnungen (810) |
| ODETTE | Europaeische Automobilindustrie | Transportavise |
OEM-spezifische Anforderungen
Jeder OEM hat eigene Anforderungen an Format, Protokoll und Prozess:
| OEM | EDI-Standard | Transportprotokoll | Besonderheiten |
|---|---|---|---|
| Volkswagen | VDA + EDIFACT | OFTP2 | Eigenenes Lieferanten-Portal |
| BMW | VDA + EDIFACT | OFTP2 | Strenge Zeitfenster |
| Bosch | EDIFACT | AS2 | Mehrere Nachrichtentypen |
| Siemens | EDIFACT | AS2/HTTPS | Globale Standards |
| Daimler/Mercedes | VDA + EDIFACT | OFTP2 | OEM-spezifische Erweiterungen |
| John Deere | ANSI X12 | AS2 | Nordamerikanischer Standard |
Typische EDI-Nachrichtentypen
| EDIFACT-Typ | VDA-Aequivalent | Inhalt | Richtung |
|---|---|---|---|
| DELFOR | VDA 4905 | Lieferabruf/Forecast | OEM zu Zulieferer |
| DELJIT | VDA 4915 | Feinabruf (JIT) | OEM zu Zulieferer |
| DESADV | VDA 4913 | Lieferschein/ASN | Zulieferer zu OEM |
| INVOIC | VDA 4906 | Rechnung | Zulieferer zu OEM |
| ORDERS | -- | Bestellung | OEM zu Zulieferer |
| ORDCHG | -- | Bestellaenderung | OEM 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:
| Faktor | Auswirkung |
|---|---|
| Demografischer Wandel | Viele EDI-Experten gehen in Rente |
| Fehlende Ausbildung | Kein Studiengang lehrt EDI explizit |
| Geringe Attraktivitaet | Junge Entwickler bevorzugen moderne Technologien |
| Nischenmarkt | Wenige Anbieter, wenige Berater |
| OEM-spezifisches Wissen | Jeder 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
| Leistung | Beschreibung |
|---|---|
| Protokoll-Support | AS2, OFTP2, HTTPS, SFTP |
| Format-Support | EDIFACT, VDA, ANSI X12, CSV, XML |
| OEM-Onboarding | Einrichtung neuer OEM-Verbindungen |
| Mapping-Entwicklung | OEM-spezifische Nachrichtentransformation |
| ERP-Integration | Anbindung an SAP, Dynamics, proALPHA |
| Monitoring | 24/7-Ueberwachung aller EDI-Verbindungen |
| Fehlerbehandlung | Analyse und Behebung von Mapping-Fehlern |
| Compliance | Archivierung, GoBD-Konformitaet |
Kostenvergleich: EDI-Loesungen
| Ansatz | Einmalige Kosten | Laufende Kosten/Jahr | Risiko |
|---|---|---|---|
| Interner EDI-Spezialist | 20.000 EUR (Einarbeitung) | 80.000-100.000 EUR | Kuendigung, Bus-Faktor 1 |
| EDI-Dienstleister (klassisch) | 15.000-30.000 EUR (Setup) | 24.000-60.000 EUR | Lock-in, intransparente Kosten |
| Cloud-EDI-SaaS | 5.000-10.000 EUR | 12.000-36.000 EUR | Datenhoheit, Abhaengigkeit |
| Managed Kubernetes + EDI | 10.000-20.000 EUR | 48.000-84.000 EUR | Anbieterabhaengigkeit |
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
| Komponente | Implementierung |
|---|---|
| Kubernetes-Cluster | On-Premises, 3 Master + 4 Worker Nodes |
| AS2-Connector | Container-Deployment, 2 Replicas |
| OFTP2-Connector | Container-Deployment, 2 Replicas |
| EDI-Processor | 3 Replicas, Message-Queue-basiert |
| SAP-Connector | RFC-basiert, Connection Pool |
| Monitoring | Prometheus + Grafana, OEM-spezifische Dashboards |
| Archivierung | S3-kompatibel, 10 Jahre Retention |
Migration
Die Migration von der alten EDI-Loesung auf Kubernetes erfolgte OEM fuer OEM:
| Woche | Aktion |
|---|---|
| 1-2 | Setup Kubernetes-Cluster, Basis-Infrastruktur |
| 3-4 | Siemens (AS2) -- einfachste Anbindung zuerst |
| 5-6 | Bosch (AS2) -- aehnliches Setup wie Siemens |
| 7-8 | US-OEM (AS2, ANSI X12) -- anderes Format |
| 9-12 | VW (OFTP2) -- komplexeste Anbindung |
| 13-14 | BMW (OFTP2) -- nach VW-Erfahrung schneller |
| 15-16 | Parallelbetrieb, Tests, Dekommissionierung alt |
Ergebnisse
| Metrik | Vorher | Nachher |
|---|---|---|
| EDI-Ausfaelle/Jahr | 8-12 | 1 |
| Mittlere Ausfallzeit | 4-8 Stunden | 15 Minuten |
| Personalabhaengigkeit | 1 Person | Managed Service |
| Neue OEM-Anbindung | 6-8 Wochen | 2-3 Wochen |
| Transparenz | Blackbox | Voll ueberwacht |
| Archivierung | Manuell, lueckenhaft | Automatisch, 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
- Kubernetes Automotive: TISAX-zertifizierte Infrastruktur
- Kubernetes Integration Patterns
- Kubernetes Kosten: Intern vs. Extern im Vergleich
- Kubernetes ohne DevOps-Team im Mittelstand
- Kubernetes Betrieb auslagern: Checkliste
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
Kubernetes Omnichannel-Backend für den Einzelhandel
Omnichannel-Backend mit Kubernetes: POS, E-Commerce und Filiale auf einer Plattform synchronisieren, inklusive Managed-Service-Empfehlung für den Mittelstand.
Kubernetes Freelancer vs Managed Service: Kostenvergleich
Kubernetes Freelancer vs Managed Service ehrlich verglichen: Versteckte Kosten, Wissenssilo-Risiko, fehlende SLAs und Break-Even-Analyse für den Mittelstand.
Kubernetes Multi-Standort Logistik ohne IT vor Ort
Wie Logistik-Unternehmen mit 5+ Standorten Kubernetes zentral betreiben, ohne ein IT-Team an jedem Lager. Managed Service Lösung für den Mittelstand.
Kubernetes Fernwartung und IoT im Maschinenbau
Fernwartung und IoT für Maschinenbauer mit Kubernetes am Edge: OPC-UA-Integration, Predictive Maintenance und Field Service ohne eigene DevOps-Abteilung.
Kubernetes MDR-Compliance für Software as Medical Device
MDR-konforme Container-Infrastruktur für Software as Medical Device auf Kubernetes: Audit-Trail, IQ/OQ/PQ-Validierung und regulatorische Anforderungen.