B2B-Lieferantenkatalog und Preisparser mit Schutz (Cloudflare) und Hochladen auf PostgreSQL und CSV

Die Ausgangssituation ist, dass es eine B2B-Website für einen Autoteilelieferanten gibt (ein geschlossener Katalog mit einem persönlichen Konto) und die interne Preisliste in unserem ERP veraltet ist. Der manuelle Abgleich dauert 6–8 Stunden pro Woche. Der Lieferant verfügt über keine API; Produktkarten und Guthaben sind nur über die Weboberfläche nach der Anmeldung verfügbar. Die Website umfasst Anti-Bot-Maßnahmen (Cloudflare, dynamische Token, teilweises Laden über XHR). Wir müssen die Datenerfassung und Aktualisierung unserer Datenbank für den anschließenden Import in ERP automatisieren.

Technische Umgebung – Linux-Server (Ubuntu 22.04), Docker verfügbar. Bevorzugter Stack – Python 3.11, Playwright oder Selenium + Abfragen an XHR, PostgreSQL 14. Zugriff – Testkonto zur Site, separates Schema in Postgres, SSH zum Server. Bei Bedarf stellen wir einen Proxy zur Verfügung, es ist jedoch wichtig, die Belastung der Website zu minimieren.

Das Ergebnis soll ein Repository mit Code und einer Docker-Umgebung sein, das den Katalog und die Preise nach einem Zeitplan sammelt, in PostgreSQL speichert und zusätzlich einen täglichen CSV-Upload durchführt. Es werden Daten für alle Produkte in den ausgewählten Abschnitten des Katalogs benötigt.

Anforderungen für die Datenerfassung: Sie müssen die SKU/den Artikel des Lieferanten, den Namen, die Marke, die Kategorie/den Pfad im Katalog, den Preis (mit Währung), die verfügbare Menge/den Restbetrag, die Lieferzeit (falls angegeben), den Link zur Karte und das Analysedatum/-uhrzeit extrahieren. Wenn die Karte mehrere Angebote/Lager enthält, speichern Sie jedes Angebot in einer separaten Zeile, die mit der SKU verknüpft ist.

Einschränkungen – durchschnittlich nicht mehr als 1 Anfrage pro Sekunde pro Domain, obligatorische zufällige Verzögerungen, korrekte Verarbeitung von Sperren/Captchas ohne endlose Wiederholungen, Speicherung von Login/Passwort nur über Umgebungsvariablen/Geheimnisse, ohne fest codierte Anmeldeinformationen. Der Parser muss gegen teilweise Netzwerkausfälle resistent sein und dort weitermachen können, wo er aufgehört hat.

Phasen – 1) Standortanalyse und Identifizierung von

Akzeptanzkriterien (messbar) – 1) Ein vollständiger Durchlauf durch den Katalog aus 3 ausgewählten Abschnitten ergibt mindestens 95 % der Karten der Anzahl, die die Site im Filter/Zähler des Abschnitts anzeigt (Diskrepanzen sind aufgrund vorübergehend nicht verfügbarer Produkte zulässig), 2) eine erneute Ausführung innerhalb von 24 Stunden aktualisiert nur die geänderten Datensätze und wird ohne manuelles Eingreifen abgeschlossen, 3) die Struktur der PostgreSQL- und CSV-Tabellen entspricht dem vereinbarten Schema, 4) es gibt eine Zusammenfassung in den Protokollen – wie viele Karten verarbeitet wurden, wie viele Fehler nach Typ, wie viele Positionen aktualisiert wurden, 5) Start auf dem Server über Docker Compose mit einem Befehl, 6) die durchschnittliche Auslastung überschreitet das Limit nicht und es gibt keine massiven 403/429 im normalen Modus.

Was wir bereitstellen werden: eine Liste der Katalogabschnitte, Testzugriff, Server, Postgres, ein Beispiel für das erforderliche CSV-Format für ERP (Spalten und Trennzeichen).