Ein deutscher Ersatzteilhändler bekommt vom Zulieferer wöchentlich eine 40-Megabyte-XML-Datei. Produktnamen heißen dort „ItemDescription“, Preise stehen in einem Knoten namens „GrossAmount“, Kategorien sind hierarchisch verschachtelt. Der native Import von Magento 2 scheitert an dieser Datei kläglich – und die händische Umwandlung in CSV frisst einen halben Arbeitstag. Genau hier setzt die XSLT-Transformation an: Sie übersetzt beliebige XML-Strukturen in ein Format, das Magento Open Source und Adobe Commerce ohne Umweg verarbeiten.
Warum scheitert der Standard-Import von Magento 2 an Lieferanten-XML?
Die kurze Antwort: Der Kern-Import akzeptiert nur CSV und erwartet exakt die Attributnamen und Spaltenlogik von Magento – jede Abweichung bricht den Lauf ab oder erzeugt fehlerhafte Datensätze. Wer Produkte, Kunden oder Bestellungen aus ERP- und PIM-Systemen oder direkt von Lieferanten anbinden will, steht vor demselben Problem: Kein Lieferant richtet sein Exportformat nach Magentos Wünschen aus. Bisherige Lösungen waren aufwendig. Entweder ein Dienstleister schreibt individuelle Mapping-Skripte, oder eine Middleware wie ein ESB dazwischen formatiert die Daten um. Beides kostet Budget und schafft Abhängigkeiten.
XSLT – Extensible Stylesheet Language Transformations – ist dafür der etablierte Standard aus dem Enterprise-Umfeld. Ein einmal definiertes Stylesheet beschreibt Regel für Regel, wie Knoten der Quelldatei auf Magento-Attribute gemappt werden. Umbenennungen, Verschachtelungen auflösen, Werte zusammenführen, Preise umrechnen: All das passiert deklarativ, ohne Zeilen in PHP.
Wie funktioniert die Transformation im Shop-Alltag?
Der Ablauf ist denkbar einfach: Die Roh-XML kommt per URL, FTP oder Upload ins System, das Stylesheet transformiert sie in eine Magento-kompatible Struktur, danach greift der reguläre Import. Der entscheidende Vorteil liegt in der Wartbarkeit. Ändert der Lieferant sein Format, passt der Integrator ein Stylesheet an – kein Deployment, kein Code-Review, kein Ausfall des Nacht-Crons.
Praxisrelevant wird das bei der FireBear-Erweiterung Improved Import & Export, die XSLT bereits seit mehreren Versionen als Mapping-Ebene unterstützt und unter Magento 2.4.x auf Open Source wie Adobe Commerce läuft. Wer ohnehin mit dieser Extension arbeitet, kann XSLT-Templates direkt im Import-Profil hinterlegen. Alternativ steht es Integratoren frei, die Transformation mit PHP-Bordmitteln (XSLTProcessor) oder einer kleinen CLI-Pipeline vor dem nativen Import zu schalten – das reicht für Shops mit überschaubarer Artikelanzahl völlig aus.
Die gleiche Logik gilt in der Gegenrichtung. Beim Export Richtung Warenwirtschaft, CRM oder Marktplätze erzeugt Magento selten das Format, das das Zielsystem erwartet. Ein Export-Stylesheet formt die Ausgabe so, dass etwa ein SAP-System oder ein Preisportal die Datei ohne Nachbearbeitung schluckt.
Was sollten Shop-Betreiber jetzt konkret prüfen?
Zuerst die Bestandsaufnahme: Welche Schnittstellen laufen heute über händische CSV-Bastelei oder teure Mapping-Skripte? Genau diese Prozesse sind Kandidaten für XSLT. Zweitens die Performance-Grenze im Blick behalten. Sehr große XML-Dateien oberhalb von einigen hundert Megabyte sollten gestreamt oder vorab gesplittet werden, sonst strapaziert die Transformation den Arbeitsspeicher des PHP-Prozesses. Drittens lohnt ein Blick auf die Versionslandschaft: Wer noch auf Magento 2.3.x oder frühen 2.4-Versionen fährt, sollte ohnehin planen – Adobe liefert Sicherheitsupdates nur noch für aktuelle 2.4-Minor-Releases, und moderne Import-Extensions setzen zunehmend PHP 8.2 voraus.
Wer heute Lieferanten-XML per Hand in CSV umwandelt, zahlt doppelt: einmal in Arbeitszeit und noch einmal in Fehleranfälligkeit.
Die ehrliche Einordnung zum Schluss: XSLT ist keine neue Technologie und keine Wunderwaffe. Die Stylesheets wollen gepflegt sein, und bei hochkomplexen ETL-Anforderungen mit Anreicherung aus mehreren Quellen führt an einem echten PIM- oder Integrationslayer kein Weg vorbei. Aber für den klassischen Fall – Lieferant liefert XML, Magento erwartet Magento-Format – ist XSLT die schlankste Lösung, die der Markt kennt. Händler mit mehr als zwei aktiven Lieferantenschnittstellen sollten den Umbau nicht auf die lange Bank schieben: Der ROI rechnet sich typischerweise innerhalb eines Quartals allein über eingesparte Mapping-Stunden.