Produktdaten in 45 Minuten verarbeiten – mit einer schrittweise optimierten ERP-Integration.
Ein SAP-System liefert XML-Dateien per SFTP, ein Magento-Shop benötigt aktuelle Produkte, Bilder und PDFs. Eine neue Integrationsschicht mit Azure Functions ersetzt den störanfälligen Windows-Service.
Anonymisierter Bericht aus der Integrationspraxis. Die Ergebnisse beziehen sich auf das beschriebene System und den dokumentierten Betriebszeitraum von 14 Monaten.
Ausgangslage und Aufgabe
Die vorhandene Verarbeitung lief auf einer dedizierten Windows-VM. Ein Import brauchte sechs bis acht Stunden, Fehler erforderten häufig manuelle Eingriffe. Ein einzelner langsamer oder fehlgeschlagener API-Aufruf konnte den gesamten Lauf beeinträchtigen.
Meine Arbeit in diesem Projekt umfasste Architektur und technische Umsetzung der Integrationslösung. Die Verbesserung entstand aus mehreren Optimierungsschritten im Betrieb; die Kennzahlen beschreiben das Gesamtsystem und keinen isolierten Beratereffekt.
Die wesentlichen Entscheidungen
- Verarbeitungsschritte über Queues entkoppeln, damit Fehler nicht jeden weiteren Schritt blockieren.
- Große XML-Dateien streamen und API-Aufrufe unter Beachtung der Zielsystem-Limits parallelisieren.
- Wiederholungen, Fehlerablage und Monitoring als Bestandteil der Lösung behandeln.
- Verarbeitungszustände für Nachvollziehbarkeit und Reporting in SQL speichern.
| Messgröße | Ausgangslage | Ergebnis |
|---|---|---|
| Import von 50.000 Produkten | 6–8 Stunden | 45 Minuten |
| Zuverlässigkeit | 23 % fehlerhafte Importläufe | 99,97 % Erfolgsrate im beschriebenen Betrieb |
| Tägliches Volumen | Begrenzung durch feste VM-Kapazität | 50.000–200.000 Produktupdates |
Ein erfolgreicher Importlauf und die Erreichbarkeit einer Anwendung sind unterschiedliche Messgrößen. Die Erfolgsrate ist daher keine Uptime-Angabe.
Wirtschaftlichkeit: ein Kostenmodell mit offengelegten Annahmen
Der Projektbericht vergleicht jährliche Infrastruktur- und Betriebsaufwände. Interne Betriebs- und Incident-Zeit wird mit 100 € pro Stunde bewertet. Das ist ein Rechenansatz für gebundene Kapazität und nicht automatisch eine Auszahlungseinsparung.
| Bestandteil | Alte Lösung | Neue Lösung |
|---|---|---|
| Infrastruktur und Plattformdienste | 2.880 € | 3.600 € |
| Angesetzte Betriebs- und Incident-Zeit | 20.400 € | 1.200 € |
| Summe | 23.280 € | 4.800 € |
Die rechnerische Differenz beträgt 18.480 € pro Jahr, rund 79 %. Bei den im Bericht angesetzten 60.000 € Entwicklungsaufwand ergibt sich eine einfache Amortisation nach rund 3,3 Jahren ab voller Wirksamkeit. Dies ist eine Hochrechnung, kein innerhalb der 14 Betriebsmonate bereits realisierter Gesamtertrag. Finanzierungskosten und zusätzliche Umsätze sind darin nicht berücksichtigt.
Was schwierig blieb
Serverless bringt Cold Starts, Ausführungsgrenzen und verteilte Fehlersuche mit sich. Warme Instanzen verbessern das Antwortverhalten, erhöhen aber die Infrastrukturkosten. Im Kostenmodell kommt der wirtschaftliche Nutzen vor allem aus weniger Betriebsarbeit und Fehlerbehandlung.
Übertragbarkeit auf Ihr Vorhaben
Der Ansatz passt zu entkoppelbaren Integrationsschritten. Ob er für Ihre Datenmengen und Zielsysteme sinnvoll ist, hängt von API-Limits, Wiederholbarkeit der Verarbeitung und Betriebsanforderungen ab.
Vollständiger technischer Projektbericht mit Architektur und Kostenansätzen →