Über das Projekt
RC TRITEC stellt Isotope und Forschungschemikalien her. Über 200 Produkte mussten auf der Website aktualisiert werden. Die Daten dazu stecken in PDFs, pro Produkt ein Datenblatt, und jedes PDF ist anders aufgebaut.
Ohne Tool hiesse das: jemand öffnet jedes der 200+ PDFs einzeln, kontrolliert die Felder, zieht die Bilder raus und tippt alles von Hand ins Strapi-CMS. Diese Arbeit wäre beim Kunden gelandet. Zig Stunden, fehleranfällig, und niemand fängt gerne damit an.
Meine Lösung ist eine Python-Pipeline. Sie liest die PDFs mit Docling aus, mappt die Felder aufs Strapi-Schema und zeigt in einem HTML-Report pro Produkt, was vorhanden ist, was fehlt und welche Bilder rausgeholt wurden. Erst wenn das passt, geht alles per API ins CMS.
Stack & Architektur
- Docling: bewusst gewählt, weil ich sauberes Markdown aus den PDFs brauche.
- Python: folgt aus Docling.
- Strapi: war gesetzt, die Website lief schon darauf.
- REST API: die Strapi-API macht das Anlegen und Aktualisieren der Produkte einfach.
Der interessante Teil ist nicht das Mapping, sondern der Report. Nichts wird blind hochgeladen. Die Pipeline erzeugt eine HTML-Übersicht, die jedes Produkt auflistet: welche Felder vollständig sind, wo Lücken klaffen, welche Bilder extrahiert wurden. Dazu vergleicht sie den aktuellen Strapi-Stand mit dem, was im PDF steht. So sehe ich auf einen Blick, wo Backend und PDF auseinanderlaufen, bevor ich etwas anfasse.
Das Schema kam von Strapi, die Übernahme war entsprechend direkt. Der Aufwand steckte woanders.
Herausforderungen
Die PDFs waren uneinheitlich. Dieselbe Information hiess in einem PDF anders als im nächsten, manche Felder fehlten ganz. Das Mapping war darum nicht trivial: ich musste die unterschiedlichen Feldnamen zusammenführen und einzelne Teile per Regex aus dem Markdown ziehen.
Dazu kam die Abklärung, welcher Wert überhaupt korrekt ist. Der Report deckte Diskrepanzen zwischen Strapi-Backend und PDF auf: fehlende Nummern, komische Nummern, PDFs die nicht zum Produkt passten. Jeden dieser Fälle musste ich prüfen statt blind übernehmen. Genau dafür war der Report da.
Ergebnisse
Alle Produkte sind importiert. Die Bilder wurden automatisch aus den PDFs gezogen, das allein hätte dem Kunden Kopfschmerzen gemacht. Der Import lief am Ende ohne Probleme durch.
Der grösste Gewinn ist die gesparte Handarbeit. Jemand hätte sonst 200+ PDFs öffnen, die Felder kontrollieren und in einer Excel nachschauen müssen, welche Kategorie wohin gehört. Das fällt komplett weg. Der Kunde war sehr froh, vor allem über die aufgedeckten Inkonsistenzen, die sonst unbemerkt geblieben wären.
Lessons Learned
Docling liefert stark. Die Markdown-Qualität war besser als erwartet. Knifflig wird es nur, wenn die PDF-Struktur eigenwillig ist, dann leidet das Mapping.
Der Report war den Aufwand wert. Er hat sehr viele Mapping-Probleme sichtbar gemacht, die ich danach korrigieren konnte. Ohne ihn hätte ich die Fehler erst im Backend gefunden, oder gar nicht.
Schnell prototypen, dann am Report nachschärfen. Würde ich wieder so bauen. Der Report macht Probleme sofort sichtbar, und der Code-Fix ist eine Sache von Minuten.
