Bei einem Unternehmensimport sollte man nicht zwischen dem Abbruch eines ganzen Stapels wegen einer fehlerhaften Zeile und der Übernahme fragwürdiger Daten wählen müssen. Die Datenquarantäne bei PHP-Importen bietet eine dritte Möglichkeit: gültige Datensätze übernehmen, solche mit Handlungsbedarf isolieren und genügend Kontext bewahren, um sie sicher zu klären.
Eine Quarantäne ist nicht einfach ein Fehlerordner oder eine Tabelle für fehlgeschlagene Zeilen. Sie ist ein operativer Ablauf mit Klassifizierungsregeln, expliziten Statuswerten, kontrollierter Korrektur und Wiederholungen, die keine Effekte doppelt auslösen. Für den Entwurf sollte zunächst vereinbart werden, was „gültig“ für das Unternehmen bedeutet und welche Aktionen die einzelnen Rollen ausführen dürfen.
Klassifizieren Sie Fehler, bevor Sie über jede Zeile entscheiden
Ein Import umfasst meist verschiedene Prüfungen. Werden diese getrennt, lässt sich das Ergebnis verständlich erläutern und entscheiden, ob ein Datensatz weiterverarbeitet, abgelehnt oder menschlich überprüft werden muss.
- Strukturvalidierung: Prüft Format und grundlegende Inhalte: vorhandene Spalten, Datentypen, interpretierbare Datumsangaben, Pflichtfelder und angemessene Grenzwerte. Eine nicht lesbare Datei kann die Verarbeitung des Stapels verhindern; ein ungültiges Datum in einer einzelnen Zeile sollte dies normalerweise nicht tun.
- Geschäftsregeln: Prüft Domänenbedingungen, etwa einen nicht negativen Preis, einen aktiven Kunden oder eine zulässige Kategorie. Manche Verstöße können abgelehnt werden, andere hängen möglicherweise von einer operativen Entscheidung ab.
- Konflikte mit bestehenden Daten: Erkennt beispielsweise eine externe ID, die bereits einem anderen Datensatz zugeordnet ist, oder eine Aktualisierung auf Grundlage einer veralteten Version. Solche Konflikte lassen sich nicht immer durch eine Korrektur der Datei lösen; möglicherweise sind ein Abgleich oder eine Überprüfung erforderlich.
Legen Sie für jeden Fehlertyp eine Richtlinie fest. Für ein fehlendes optionales Feld kann ein Standardwert zulässig sein; eine mehrdeutige Identität sollte nicht durch die willkürliche Auswahl eines Datensatzes aufgelöst werden. Vermeiden Sie sowohl übermäßig großzügige Regeln als auch die Einstufung jedes Mangels als fatalen Fehler. Die Entscheidung sollte die Auswirkungen einer Datenübernahme und die Kosten eines Abbruchs des Stapels berücksichtigen.
Modellieren Sie explizite Statuswerte und Übergänge
Verwenden Sie Statuswerte mit operativer Bedeutung, statt die Situation aus leeren Feldern oder Textmeldungen abzuleiten. Ein erstes Modell kann pending, accepted, rejected und needs_review umfassen. Ergänzen Sie Statuswerte wie processing oder resolved nur dann, wenn sie tatsächlichen Übergängen in Ihrem Ablauf entsprechen.
Dokumentieren Sie, welche Übergänge zulässig sind. Eine ausstehende Zeile wird beispielsweise validiert; erfüllt sie die Regeln, wird sie akzeptiert, und liegt ein überprüfbarer Konflikt vor, wird sie zur Überprüfung vorgemerkt. Eine korrigierte Zeile kann erneut validiert werden, eine bereits akzeptierte Zeile sollte jedoch nicht noch einmal wie ein neuer Datensatz verarbeitet werden. Erfassen Sie den Status des Stapels getrennt: Ein Stapel kann akzeptierte und quarantänisierte Zeilen enthalten. „Teilweise abgeschlossen“ beschreibt das Ergebnis daher besser als ein einzelner Erfolgs- oder Fehlerindikator.
Die Statuswerte sollten überprüfbaren Entscheidungen entsprechen. „Abgelehnt“ sollte bedeuten, dass die geschäftliche Änderung nicht angewendet wurde; „Überprüfung erforderlich“ bedeutet, dass eine Person eine Entscheidung treffen muss. Wenn das Überschreiben bestehender Daten erlaubt ist, legen Sie fest, wer dies unter welchen Bedingungen darf.
Bewahren Sie das Original auf und erläutern Sie jede Entscheidung
Speichern Sie die ursprüngliche Eingabe der Zeile und getrennt davon ihre normalisierten Werte und das Validierungsergebnis. So lassen sich Abweichungen untersuchen – etwa Unterschiede zwischen einem übermittelten Datum und seiner Interpretation –, ohne dass die transformierte Version zum einzigen verfügbaren Nachweis wird.
Eine Persistenzstruktur kann eine Stapel-ID, die Zeilennummer, die Quelle, eine Dateireferenz, den ursprünglichen Inhalt, den Status, erkannte Fehler, Erstellungs- und Auflösungszeitpunkte sowie die verantwortliche Person enthalten. Erfassen Sie Gründe als stabile Codes und verständliche Meldungen: Ein Code wie customer_id_ambiguous erleichtert das Filtern und Auswerten von Fällen; die Meldung sollte erklären, welche Daten geprüft werden müssen. Verlassen Sie sich für die Klassifizierungslogik nicht ausschließlich auf Freitext.
Bewahren Sie auch den Kontext auf, der zur Reproduktion der Analyse erforderlich ist: Version oder ID der verwendeten Regeln, externe ID und für den Konflikt relevante Daten. Speichern Sie keine Geheimnisse oder unnötigen personenbezogenen Daten in technischen Protokollen. Legen Sie Zugriffskontrollen und eine Aufbewahrungsfrist fest, die der Sensibilität und den geltenden Pflichten entsprechen. Wenn die vollständige Datei Informationen enthalten kann, die zur Klärung einer Zeile nicht benötigt werden, begrenzen Sie deren Offenlegung.
Korrigieren und wiederholen Sie die Verarbeitung, ohne Effekte zu duplizieren
Eine sichere Wiederholung beginnt damit, die Zeile vom Verarbeitungsversuch zu unterscheiden. Weisen Sie jeder Zeile innerhalb ihres Geltungsbereichs eine stabile Identität zu, beispielsweise über die Kombination aus Stapel und Zeilenindex oder einen validierten externen Schlüssel. Legen Sie bei wiederholbaren Importen außerdem einen Idempotenzschlüssel fest, mit dem sich derselbe Vorgang erkennen lässt. Die Wahl hängt davon ab, ob das erneute Laden derselben Datei Daten aktualisieren, ignorieren oder eine neue Version erstellen soll.
Wenden Sie beim Verarbeiten einer Zeile die geschäftliche Schreiboperation und die Statusänderung nach Möglichkeit atomar an: Beide Vorgänge werden gemeinsam bestätigt oder keiner von ihnen. In PHP kann eine Datenbanktransaktion Änderungen schützen, die dieselbe Verbindung verwenden; einen Aufruf einer externen API macht sie nicht von sich aus atomar. Verwenden Sie für externe Effekte eine mit dem empfangenden System kompatible Strategie, etwa Idempotenzschlüssel, eine transaktionale Outbox-Tabelle oder eine für den Anwendungsfall konzipierte Kompensation.
Führen Sie nach einer Korrektur die relevanten Validierungen erneut aus und bewahren Sie den bisherigen Verlauf auf. Löschen Sie den ursprünglichen Fehler nicht, sondern fügen Sie einen neuen Versuch mit seinem Ergebnis hinzu. Wenn sich Regeln oder Referenzdaten ändern, geben Sie an, welche Version angewendet wurde, und verhindern Sie, dass eine Wiederholung eine bereits akzeptierte Entscheidung unbemerkt ändert. Die Wiederholung sollte nur die ausgewählten Datensätze betreffen und nicht unterschiedslos den gesamten Stapel erneut ausführen.
Entwerfen Sie einen operativen und auditierbaren Prüfprozess
Die Prüfoberfläche sollte bei der Entscheidungsfindung helfen und nicht lediglich eine technische Ausnahme anzeigen. Zeigen Sie den empfangenen Wert, den Grund, das betroffene Feld und den relevanten Kontext an sowie – sofern dies sicher ist – einen Korrekturvorschlag. Ermöglichen Sie Filter nach Status, Stapel, Fehlertyp und Alter; machen Sie kenntlich, welche Zeilen bereits Effekte ausgelöst haben und welche nicht.
Erfassen Sie, wer den Fall geprüft hat, wann dies geschah, welchen Wert die Person geändert hat, welche Entscheidung getroffen wurde und aus welchem Grund. Unterscheiden Sie die Korrektur durch eine verantwortliche Person von einer automatischen Transformation. Vergeben Sie Berechtigungen entsprechend den Zuständigkeiten: Wer eine Datei importieren darf, sollte nicht automatisch auch Konflikte genehmigen oder akzeptierte Datensätze ändern dürfen. Ziehen Sie bei Änderungen mit erheblichen Auswirkungen eine zusätzliche Freigabe in Betracht.
Vermeiden Sie, dass das Werkzeug das Überschreiben von Informationen ohne Warnung erleichtert. Prüfen Sie vor der Annahme einer Korrektur erneut Eindeutigkeit, Berechtigungen und den aktuellen Status des Datensatzes. Hat eine andere Person den Wert geändert, seit der Konflikt festgestellt wurde, zeigen Sie diesen Umstand zur Klärung an, statt eine veraltete Aktualisierung anzuwenden.
Testen Sie Teilausfälle und Wiederherstellung
Tests sollten sowohl die Regeln als auch das Verhalten des Ablaufs abdecken. Berücksichtigen Sie Dateien mit gemischten gültigen und ungültigen Zeilen, unerwartete Formate, Konflikte, vorübergehende Datenbankfehler und wiederholte Verarbeitungsversuche. Prüfen Sie, ob eine abgelehnte Zeile die Annahme der übrigen Zeilen nicht verhindert, sofern dies der vereinbarten Richtlinie entspricht, und ob ein Fehler innerhalb einer Transaktion keine Teilergebnisse hinterlässt.
- Die erneute Verarbeitung einer Zeile mit demselben Idempotenzschlüssel dupliziert weder Datensätze noch externe Aktionen.
- Durch die Korrektur eines Feldes ist eine erneute Validierung möglich, ohne das Original oder den Verlauf zu löschen.
- Eine bereits akzeptierte Zeile wird durch die Wiederholung einer anderen Zeile nicht erneut angewendet.
- Konflikte, die zwischen Überprüfung und Klärung erkannt werden, werden nicht unbemerkt überschrieben.
- Fehlermeldungen ermöglichen das Ergreifen geeigneter Maßnahmen, ohne unnötig sensible Daten offenzulegen.
Beobachten Sie in der Produktion das Volumen und Alter der quarantänisierten Datensätze, die häufigsten Gründe, die Lösungsquote und fehlgeschlagene Wiederholungen. Ein anhaltender Anstieg kann auf eine Änderung im Quellsystem, eine veraltete Regel oder unklare Ladeanweisungen hindeuten. Eine Quarantäne erfüllt ihren Zweck, wenn sie solche Ursachen sichtbar macht und ihre kontrollierte Behebung ermöglicht – nicht, wenn sie zu einem unbegrenzt wachsenden Speicher für Ausnahmen wird.
