Fortsetzbare PrestaShop-9-Importe: Lieferantenfeeds ohne Datenverlust

Ein großer Lieferantenimport scheitert selten an einer günstigen Grenze. Der Prozess kann nach dem Speichern eines Produkts, aber vor der Fortschrittsaufzeichnung stoppen, nach dem Herunterladen eines Bildes, aber vor dessen Zuordnung oder nach dem Lesen einer halben Datei, die der Lieferant anschließend ersetzt.

Das Ziel ist nicht lediglich, einen PHP-Prozess länger am Leben zu halten. Teilfortschritte sollen nachvollziehbar und fortsetzbar sein, ohne Produkte zu duplizieren, Aktualisierungen zu verlieren oder veraltete Bestandsdaten anzuwenden. Dafür braucht es zuerst ein Importmodell und erst danach eine schnellere Schleife.

Dieser Artikel beschreibt einen moduleigenen Entwurf zur Datenübernahme für PrestaShop 9. Er setzt weder eine integrierte Warteschlange noch eine Checkpoint-Tabelle oder eine allgemeine Lieferantenimport-API voraus. Wählen Sie unterstützte Domänenoperationen, die zu den von Ihrer Integration geschriebenen Feldern passen.

Ein wiederkehrender Import benötigt auch einen zuverlässigen Cronjob-Entwurf: Checkpoints der Quelle allein verhindern weder überlappende Worker noch unsichere Wiederholungen.

Die Quelle vor der Verarbeitung fixieren

Geben Sie jedem empfangenen Feed eine unveränderliche Identität, etwa eine Lieferantenkennung zusammen mit einer Inhaltsprüfsumme und einem Empfangsdatensatz. Speichern Sie die exakt zu verarbeitende Datei an einem kontrollierten Ort. Ein erneuter Versuch sollte dieselben Bytes lesen, sofern ein Operator nicht ausdrücklich einen neuen Import anlegt.

Öffnen Sie nicht wiederholt eine wechselnde Download-URL des Lieferanten und bezeichnen dies als denselben Auftrag. Ändert sich der Inhalt zwischen Versuchen, kann eine Datensatznummer oder ein Offset auf andere Daten zeigen. Der Importer kann dann unbemerkt Datensätze überspringen oder zwei Bestandsaufnahmen vermischen.

Dokumentieren Sie Format, Kodierung, Trennzeichen, erwartete Spalten und die Bedeutung des Feeds laut Lieferant. Handelt es sich um eine vollständige Katalogaufnahme oder Änderungsdaten? Bedeutet Abwesenheit Löschung, keine Änderung oder eine vorübergehende Auslassung? Diese Regeln bestimmen das Abgleichverhalten.

Prüfen Sie die Datei vor Schreibvorgängen. Lehnen Sie unerwartete Kopfzeilen, unmögliche Kodierung oder eine verdächtig unvollständige Lieferung gemäß dem vereinbarten Feed-Vertrag ab. Eine kurze Datei kann gültige Änderungsdaten oder eine abgeschnittene Gesamtaufnahme enthalten; der Importer darf das nicht erraten.

Bewahren Sie die Quellenidentität in jedem Fehlerbericht auf, damit ein Entwickler die genaue Eingabe reproduzieren kann.

Die Identität vor dem Erstellen oder Aktualisieren von Produkten klären

Eine SKU ist nicht automatisch ein global eindeutiger PrestaShop-Entitätsschlüssel. Lieferanten können Referenzen wiederverwenden, Kombinationen können eigene Kennungen besitzen und verschiedene Shops können denselben externen Artikel absichtlich unterschiedlich zuordnen.

Erstellen Sie einen Zuordnungsvertrag mit Lieferant, externer Artikelidentität und erforderlichem Shop- oder Zielgeltungsbereich. Ordnen Sie diese Identität dem passenden Produkt oder der passenden Kombination zu. Erzwingen Sie Eindeutigkeit auf derselben Ebene wie die Suche.

Enthält ein Feed doppelte externe Identitäten, stellen Sie diese unter Quarantäne oder lösen Sie sie mit einer ausdrücklichen Regel auf. Lassen Sie nicht stillschweigend die letzte Zeile gewinnen, sofern das nicht im Lieferantenvertrag dokumentiert ist. Halten Sie fest, welche Zeilen kollidierten und welche Maßnahme ergriffen wurde.

Vermeiden Sie bei regulären Importen unscharfe Zuordnung anhand des Produktnamens. Namen sind beschreibend und können sich ändern. Benötigt der anfängliche Abgleich eine manuelle Zuordnung, behalten Sie diese als kontrollierten Einrichtungsschritt bei und speichern Sie die daraus entstehende Zuordnung.

Prüfen Sie vor dem Erstellen einer neuen Entität vorhandene Zuordnungen und ungeklärte frühere Versuche. Ein Absturz nach der Erstellung, aber vor dem Speichern der Zuordnung könnte sonst beim Neustart ein weiteres Produkt erzeugen. Erstellung und Zuordnung brauchen nach Möglichkeit eine atomare Grenze, andernfalls eine Abgleichstrategie.

Datensätze streamen und auch die Validierung begrenzen

Inkrementelles Lesen vermeidet das Laden eines gesamten Feeds in den Speicher. Streaming allein begrenzt den Speicher aber nicht, wenn die Anwendung jeden geparsten Datensatz, Fehler oder jedes hydratisierte Objekt behält.

Der folgende PHP-Generator liest eine lokale CSV-Datei datensatzweise. Er ist ein Parserbeispiel, kein vollständiger PrestaShop-Importer. Er setzt das CSV-Escape-Argument ausdrücklich, statt sich auf dessen wechselndes Standardverhalten zu verlassen. PHP-CSV-Referenz.

<?php
function readSupplierRows(string $path): Generator
{
    $stream = fopen($path, 'rb');
    if ($stream === false) {
        throw new RuntimeException('Cannot open supplier file');
    }
    try {
        $header = fgetcsv($stream, 0, ',', '"', '');
        if ($header === false || count(array_unique($header)) !== count($header)) {
            throw new RuntimeException('Missing or duplicate CSV headers');
        }
        foreach (['external_id', 'quantity'] as $required) {
            if (!in_array($required, $header, true)) {
                throw new RuntimeException('Required CSV column is absent');
            }
        }
        $record = 1;
        while (($fields = fgetcsv($stream, 0, ',', '"', '')) !== false) {
            ++$record;
            if ($fields === [null]) {
                continue;
            }
            if (count($fields) !== count($header)) {
                throw new RuntimeException('Column mismatch at record ' . $record);
            }
            yield $record => array_combine($header, $fields);
        }
    } finally {
        fclose($stream);
    }
}

Behandeln Sie die gelieferten Werte als nicht vertrauenswürdige Zeichenketten. Validieren Sie Kennungen, Zahlenbereiche und Feldlängen vor Zuordnung oder Speicherung. Ergänzen Sie formatspezifische Behandlung für Byte-Reihenfolge-Markierungen, Kodierung und fehlerhafte Inhalte. Begrenzen Sie die Datensatzgröße bei der Übernahme oder in einem Parser für bösartige oder ungewöhnlich große Eingaben; inkrementelles Lesen allein begrenzt kein riesiges CSV-Feld.

Der Datensatzzähler ist eine logische Parserposition und nicht unbedingt eine physische Zeilennummer, da CSV-Felder in Anführungszeichen Zeilenumbrüche enthalten können. Bewahren Sie diese Unterscheidung in Fehlerberichten und im Checkpoint-Entwurf.

Den Fortschritt zusammen mit der beschriebenen Arbeit festschreiben

Ein Checkpoint sollte die unveränderliche Quelle, Parserposition oder Partition, Zuordnungsversion und letzte festgeschriebene Einheit identifizieren. Verschieben Sie ihn erst, nachdem der zugehörige Schreibvorgang dauerhaft gespeichert wurde.

Schreiben Sie bei lokaler transaktionaler Arbeit fachliche Änderung und Fortschrittsdatensatz gemeinsam fest, soweit die unterstützte Domänenoperation und der Speicher dies zulassen. Umschließen Sie nicht beliebige Kernbefehle und externe Nebenwirkungen mit einer Transaktion in der Annahme, dass alles gemeinsam zurückgesetzt wird.

Ist Atomarität nicht verfügbar, machen Sie den Schreibvorgang sicher wiederholbar oder gleichen Sie sein Ergebnis vor der Wiederholung ab. Bei einer absoluten Mengenaufnahme kann die Wiederholung derselben akzeptierten Version sicher sein, wenn die Integration klare Zuständigkeitsregeln für den Bestand hat. Ein erneutes Dekrement ist ein anderer Vorgang und benötigt eine stabile Ereignisidentität.

Ein Stapel sollte klein genug für Wiederholungen und groß genug zur Vermeidung übermäßigen Zusatzaufwands sein. Wählen Sie seine Größe anhand gemessenen Verhaltens und transaktionaler Grenzen statt anhand einer aus einem anderen Shop kopierten universellen Zahl.

Verfolgen Sie Ergebnisse je Datensatz getrennt vom am weitesten fortgeschrittenen Checkpoint, wenn Fehler übersprungen werden können. Andernfalls kann das Fortschreiten über eine fehlerhafte Zeile diese aus der zukünftigen Verarbeitung verschwinden lassen. Ein quarantänisierter Datensatz sollte Quellenidentität, Grund und Wiederholungs- oder Korrekturweg behalten.

Bildbeschaffung von der Katalogspeicherung trennen

Bilder bringen Netzwerkzeitüberschreitungen, Dateivalidierung und zusätzliche Zustandsübergänge mit sich. Jede Produkttransaktion während des Wartens auf Downloads offenzuhalten erschwert die Wiederherstellung.

Erwägen Sie einen separaten Bildarbeitsdatensatz, der mit dem unveränderlichen Feed-Artikel und dem vorgesehenen Produkt oder der Kombination verknüpft ist. Der Katalogschritt erfasst die gewünschte Bildidentität; ein Worker lädt das Bild herunter, validiert es und ordnet es über den unterstützten Medienablauf zu.

Prüfen Sie vor dem Abruf die Regeln für entfernte Quellen. Beschränken Sie Protokolle und Ziele angemessen, begrenzen Sie Weiterleitungen, Zeit und Größe und lehnen Sie unerwartete Inhalte ab. Eine Dateinamenerweiterung allein beweist kein gültiges Bild. Das sind Anforderungen an den Importerentwurf, keine Aussagen über einen bestimmten Kern-Downloader.

Laden Sie in kontrollierten temporären Speicher herunter und übernehmen Sie nur validierte Inhalte in den endgültigen Speicher. Bewahren Sie eine stabile externe Bildidentität oder Prüfsumme, damit Wiederholungen abgeschlossene Arbeit erkennen, statt Duplikate zuzuordnen.

Entscheiden Sie, wie ein Bildfehler die Veröffentlichung beeinflusst. Das Produkt kann unveröffentlicht bleiben, bis erforderliche Medien bereitstehen, oder das Unternehmen kann eine teilweise Katalogaktualisierung erlauben. Legen Sie diese Regeln ausdrücklich fest, statt die Worker-Zeitplanung über die Kundenansicht entscheiden zu lassen.

Nebenläufigkeit und veraltete Feeds gezielt behandeln

Zwei Importe für denselben Lieferanten und Shop können konkurrieren, obwohl jeder einzeln fortsetzbar ist. Legen Sie fest, ob sie parallel laufen dürfen und welche Feed-Revision einen Datensatz aktualisieren darf.

Wurde bereits eine neuere Bestandsaufnahme angewendet, darf ein älterer Wiederholungsversuch diese nicht allein deshalb überschreiben, weil er später endet. Speichern Sie eine Quellenrevision oder ein Ordnungstoken, wenn der Lieferantenvertrag eines bereitstellt, und erzwingen Sie einheitliche Vergleichsregeln.

Koordinieren Sie auch andere Schreibzugriffe. Mitarbeiter können Produktbeschreibungen bearbeiten, während ein Feed Bestände aktualisiert. Definieren Sie Feldzuständigkeiten, damit der Import nur seine eigenen Felder ändert. Das Speichern eines vollständigen Objekts auf Grundlage einer alten Leseoperation kann unbeteiligte manuelle Änderungen überschreiben.

Klären Sie beim Bestand, ob der Lieferant physischen Bestand, verfügbaren Bestand oder eine andere Menge liefert. Die Integration muss Reservierungen und Bestellablauf des Shops über unterstützte Bestandsoperationen berücksichtigen. Schreiben Sie nicht direkt in eine Kern-Bestandsspalte, nur weil diese der gelieferten Zahl ähnelt.

Sperren können eine Partition serialisieren, lösen aber weder ein unbekanntes entferntes Ergebnis noch eine veraltete Quellenrevision. Verwenden Sie sie zusammen mit Identität und Abgleich. Der Leitfaden zur Cron-Zuverlässigkeit behandelt diese Ausführungsfragen ausführlicher.

Vollständige Bestandsaufnahmen erst nach nachgewiesenem Abschluss abgleichen

Ein vollständiger Katalogfeed kann die Erkennung nicht mehr gelieferter Artikel erfordern. Diese destruktive oder deaktivierende Phase darf erst laufen, wenn der Importer die Verarbeitung einer gültigen vollständigen Aufnahme gemäß Lieferantenvertrag nachweist.

Deaktivieren Sie nicht alle ungesehenen Produkte nach einem Parserfehler oder abgebrochenen Download. Unterscheiden Sie beim Feed zwischen empfangen, validiert, in Verarbeitung und abgeschlossen. Fehlende Datensätze in einer unvollständigen Aufnahme sind kein zuverlässiger Nachweis eines Rückzugs.

Erstellen Sie vor umfassenden abwesenheitsbasierten Änderungen eine überprüfbare Anzahl und, sofern geschäftlich erforderlich, eine Kandidatenliste. Vergleichen Sie diese mit erwarteten Bereichen aus der tatsächlichen Feed-Vereinbarung und der bisherigen Historie. Eine drastische Änderung sollte untersucht statt automatisch als normal behandelt werden.

Trennen Sie Deaktivierung von Löschung, sofern das Unternehmen nicht ausdrücklich Löschung verlangt und sämtliche Folgen verstanden sind. Fortsetzbarkeit umfasst die Wiederherstellung nach fehlerhaften Quelldaten, nicht nur nach Prozessabstürzen.

Das Neustartverhalten durch Fehlerinjektion nachweisen

Verwenden Sie einen kleinen synthetischen Feed mit gültigen Zeilen, einer doppelten Identität, einer ungültigen Menge und einem fehlschlagenden Bild. Stoppen Sie den Worker nach einem festgeschriebenen Stapel und starten Sie ihn neu. Prüfen Sie Fortschritt und resultierenden Katalog.

Stoppen Sie ihn anschließend an der schwierigen Grenze: nachdem ein fachlicher Schreibvorgang abgeschlossen sein könnte, aber vor der Bestätigung. Bestätigen Sie, dass Wiederholung oder Abgleich genau eine beabsichtigte Entität und einen beabsichtigten Effekt erzeugt.

Testen Sie eine zweite Feed-Revision, während die erste noch unerledigte Arbeit hat. Prüfen Sie, dass Ihre Ordnungsregeln veraltete Überschreibungen verhindern. Führen Sie dieselben Testdaten in zwei Shops mit unterschiedlichen Zuordnungen aus, um unbeabsichtigte Vermischung von Geltungsbereichen aufzudecken.

Die Operatoransicht sollte akzeptierte, geänderte, unveränderte, quarantänisierte Datensätze und Datensätze mit ausstehenden Bildern getrennt ausweisen. Eine einzige Importanzahl verbirgt zu viel, um die Wiederherstellung zu unterstützen.

Ein sicherer lang laufender Import ist eine Folge dauerhafter, identifizierbarer Schritte. Unveränderliche Eingabe, genaue Zuordnung, begrenzte Verarbeitung und Checkpoints mit Bezug zu festgeschriebener Arbeit erlauben es, den Prozess ohne Bedeutungsverlust zu stoppen und fortzusetzen, ohne zu erraten, was vor dem Fehler geschah.

Zum grundlegenden Plattformkontext lesen Sie unseren Leitfaden zur Leistung von PrestaShop 9 und wenden Sie die oben beschriebenen versionsspezifischen Prüfungen auf die untersuchte Installation an.

Bei der Auswahl einer Erweiterung sehen Sie sich die PrestaShop-9-Module von PrestaSuite an und vergleichen Sie die dokumentierte Versionsunterstützung und die Integrationsanforderungen mit Ihren eigenen Testergebnissen.