CSV-Import automatisieren: Auslöser, Ablauf, Fehlerfall

Jedes Unternehmen, das regelmäßig externe Daten bezieht, kennt das: Eine CSV-Datei kommt rein — per E-Mail, per FTP, per Lieferantenportal — und irgendjemand sorgt dafür, dass sie irgendwie im System landet. Manchmal ein Skript, das von Hand gestartet wird. Manchmal ein Mensch, der die Werte tippt. Manchmal beides, abwechselnd, je nachdem wer gerade Zeit hat.

Das ist kein Randproblem. Es ist ein wiederkehrender Prozess, der sich jede Woche wiederholt, Ressourcen bindet und Fehler produziert — still und ohne Protokoll. Dieser Artikel beschreibt, wie man ihn automatisiert. Nicht als Überblick über Automatisierungstools, sondern als einen einzigen konkreten Ablauf: von der ersten Datei bis zum letzten Fehlerlog.

Der Auslöser: Wie der Prozess beginnt

Der erste Design-Entscheid ist, was den Prozess startet. Drei Varianten kommen in der Praxis vor:

• Polling: Ein Dienst prüft in festen Intervallen — z. B. alle 15 Minuten — ob eine neue Datei an einem bekannten Ort liegt. SFTP-Ordner, S3-Bucket, freigegebenes Verzeichnis. Einfach umzusetzen, funktioniert zuverlässig, hat aber eine strukturelle Latenz: Wenn die Datei um 08:01 Uhr eintrifft und das nächste Polling um 08:15 Uhr stattfindet, wartet der Prozess 14 Minuten.
• Webhook / Datei-Ereignis: Das sendende System meldet aktiv, dass eine neue Datei bereitliegt. Schneller, aber man ist abhängig davon, dass der Sender zuverlässig meldet — und das tun viele ältere Systeme nicht.
• E-Mail-Eingang: Manche Lieferanten schicken die Datei als Anhang. Hier lässt sich ein dediziertes Postfach überwachen, das neue Mails automatisch auswertet. Funktioniert gut, solange das Dateiformat und der Absender stabil sind.

Welche Variante passt, hängt von der Quelle ab, nicht von der Präferenz. Polling ist oft der pragmatischste Start, weil er keine Abhängigkeiten beim Sender erzeugt.

Ein Aspekt, der früh entschieden werden muss: Was gilt als „neue" Datei? Nur der Dateiname? Der Hash des Inhalts? Beide? Wer Dateinamen nach Schema wie preisliste_2024-08-01.csv erwartet, wird früher oder später eine Datei gleichen Namens mit geändertem Inhalt bekommen. Eine Prüfsumme über den Dateiinhalt ist zuverlässiger.

Der Ablauf in vier Schritten

Nach dem Trigger folgt der eigentliche Ablauf. Er lässt sich in vier Schritte zerlegen.

Eingang und Deduplizierung

Bevor irgendetwas verarbeitet wird, fragt das System: Habe ich diese Datei schon gesehen? Dazu wird ein Hash der Datei (z. B. SHA-256 des Inhalts) gegen eine Tabelle bereits importierter Dateien geprüft.

Das klingt trivial, ist es aber nicht. Lieferanten schicken manchmal dieselbe Datei mehrfach — als Korrektur, als Bestätigung, aus Versehen. Ohne Deduplizierung läuft jeder Import doppelt durch. Die Tabelle muss nicht komplex sein: Dateiname, Hash, Eingangszeit, Verarbeitungsstatus — das reicht.

Strukturprüfung vor dem Import

Bevor eine einzige Zeile die Datenbank berührt, prüft das System die Struktur der Datei. Stimmen die Spaltenüberschriften? Ist das Encoding korrekt (UTF-8 vs. Windows-1252 ist ein klassischer Stolperstein)? Stimmt das Trennzeichen — Komma oder Semikolon? Gibt es überhaupt Zeilen?

Wenn hier etwas nicht stimmt, bricht der Prozess ab — mit einer klaren Fehlermeldung, die beschreibt, was erwartet wurde und was ankam. Ein Import, der schweigend fehlschlägt, ist schlimmer als einer, der laut scheitert.

Diese Prüfung sollte keine Zeile der Geschäftslogik kennen. Sie prüft nur die Form, nicht den Inhalt.

Zeile für Zeile: Was zählt als gültig?

Auf Zeilenebene wird inhaltlich geprüft. Pflichtfelder vorhanden? Datentypen korrekt? Referenzen auf bekannte Entitäten — z. B. Artikelnummern oder Lieferanten-IDs — auflösbar?

Hier trennt sich ein guter Prozess von einem schlechten: Wie geht er mit teilweise ungültigen Daten um? Drei Ansätze sind verbreitet:

• Alles oder nichts: Wenn eine Zeile ungültig ist, schlägt der gesamte Import fehl. Sicher, aber starr.
• Gültige importieren, ungültige überspringen: Flexibel, aber man verliert Daten ohne Protokoll.
• Gültige importieren, ungültige in Quarantäne: Der pragmatischste Weg. Gültige Zeilen werden verarbeitet, ungültige in einer separaten Tabelle mit Fehlergrund abgelegt — für manuelle Nachbearbeitung.

Die Quarantäne-Variante erfordert etwas mehr Aufwand beim Aufbau, zahlt sich aber aus: Niemand verliert Daten, und jeder Fehler ist nachvollziehbar.

Import und Rückmeldung

Nach erfolgreicher Validierung wird importiert. Ob das ein Upsert (einfügen oder aktualisieren), ein reines Insert oder das Ersetzen einer kompletten Tabelle ist, hängt von der Logik ab. Die Wahl hat Konsequenzen für Konsistenz und Performance, die man einmal bewusst treffen sollte.

Nach dem Import sendet das System eine Rückmeldung: an ein Log, an ein Dashboard, im Fehlerfall per Benachrichtigung an eine definierte Empfängergruppe. Diese Rückmeldung enthält: Zeitpunkt, Dateiname, Anzahl verarbeiteter Zeilen, Anzahl Fehler, Dauer.

Wo ein Mensch entscheiden muss

Automatisierung löst Routine — nicht Entscheidungen. Es gibt Situationen, die ein Mensch bewerten muss:

• Schemaänderungen: Der Lieferant schickt plötzlich eine neue Spalte oder benennt eine um. Das System erkennt die Abweichung und hält an. Jetzt muss jemand entscheiden: Soll die neue Spalte ignoriert, gemappt oder als Fehler behandelt werden?
• Unbekannte Referenzen: Eine Zeile enthält eine Artikelnummer, die im System nicht existiert. Ist das ein Fehler in der Lieferdatei, oder ein neuer Artikel, der angelegt werden soll? Das kann kein Algorithmus ohne explizite Geschäftsregel entscheiden.
• Überschwellenwerte: Wenn eine Datei erheblich mehr Zeilen enthält als der Durchschnitt, oder wenn ein ungewöhnlich großer Anteil in die Quarantäne wandert, ist das ein Signal. Vielleicht ein legitimer Datensprung, vielleicht ein Fehler beim Sender. Ein Mensch entscheidet, ob der Import freigegeben oder zurückgehalten wird.

Diese Entscheidungspunkte sollten klar dokumentiert und im System als explizite Zustände abgebildet sein — nicht als Kommentar im Code, sondern als Workflow-Status, der für alle sichtbar ist.

Was passiert, wenn etwas schiefgeht

Fehler in automatisierten Prozessen haben zwei Eigenschaften: Sie passieren, und sie passieren zu Zeiten, zu denen niemand hinschaut. Ein robustes System behandelt Fehler nicht als Ausnahme, sondern als Regelfall.

• Temporäre Fehler — Netzwerkausfall, Datenbank kurzzeitig nicht erreichbar — sollten mit Retry-Logik behandelt werden. Exponentielles Backoff ist dabei der Standard: erster Retry nach 1 Minute, zweiter nach 5, dritter nach 20. Nach einer definierten Anzahl von Versuchen wird der Vorgang als fehlgeschlagen markiert und eine Meldung ausgelöst.
• Strukturelle Fehler — falsches Format, Encoding-Problem, fehlende Pflichtfelder auf Dateiebene — sollten sofort eskaliert werden, ohne Retry. Hier hilft kein Warten.
• Partielle Fehler — einzelne Zeilen ungültig — landen in der Quarantäne und werden nicht erneut verarbeitet, ohne manuelle Freigabe.

Wichtig: Jeder Fehler bekommt eine eindeutige ID, die im Log, in der Datenbank und in der Fehlermeldung identisch ist. Das klingt nach Overhead, ist aber der Unterschied zwischen „Ich finde den Fehler in zwei Minuten" und „Ich suche ihn eine Stunde".

Wie man diesen Prozess beobachtet

Ein automatisierter Prozess, den niemand beobachtet, ist ein unkontrollierter Prozess. Beobachtbarkeit beginnt nicht mit einem ausgefeilten Observability-Stack, sondern mit drei einfachen Kennzahlen:

• Importdauer: Wie lange dauert ein typischer Import? Wenn er plötzlich dreimal so lange braucht, stimmt etwas nicht — vielleicht ein fehlender Datenbankindex, vielleicht eine Datei, die signifikant größer geworden ist.
• Fehlerquote pro Datei: Wie viele Zeilen landen durchschnittlich in der Quarantäne? Ein plötzlicher Anstieg deutet auf eine Änderung beim Sender hin — und sollte eine Benachrichtigung auslösen, bevor jemand beim Support anruft.
• Erfolgsrate über Zeit: Wie viele Importe der letzten 30 Tage haben fehlerfrei abgeschlossen? Wenn diese Zahl sinkt, ist das ein frühes Warnsignal, das im Tagesgeschäft sonst unsichtbar bleibt.

Diese Kennzahlen lassen sich in jedem Standard-Monitoring-Tool abbilden. Wichtiger als das Tool ist, dass sie überhaupt existieren — und dass eine konkrete Person benachrichtigt wird, wenn ein Schwellenwert überschritten wird.

Ein einfaches Dashboard, das den Status des letzten Imports, den Inhalt der Quarantäne-Tabelle und die letzten Fehlermeldungen zeigt, ist für viele Teams ausreichend. Es muss kein ausgefeiltes System sein; es muss nur vorhanden sein.

Was dieser Aufwand wert ist

Ein sauber automatisierter CSV-Import ist kein spektakuläres Projekt. Er spart keine Millionen und erscheint in keiner Pressemitteilung. Aber er gibt einem Team zurück, was es sonst Woche für Woche verliert: die Zeit und Aufmerksamkeit, die für dieses Ritual aufgewendet wird.

Der eigentliche Wert liegt nicht in der Automatisierung selbst, sondern in der Erzwingung von Klarheit: Wer darf was entscheiden? Was gilt als gültig? Was passiert, wenn nicht? Diese Fragen existieren vor der Automatisierung auch — sie bleiben nur implizit und unbeantwortet. Ein Prozess, der technisch zu Ende gedacht wird, macht sie sichtbar — und damit bearbeitbar.

Wer verstehen möchte, welche Prozesse sich in welcher Reihenfolge zu automatisieren lohnen, findet auf innosirius.de weitere Beiträge aus der Praxis — ohne Verkaufston, mit konkreten Abwägungen.