Agentic-Commerce-Feed: was Shopware tatsächlich prüft

Ein Produktfeed für KI-Einkaufsplattformen ist schnell erzeugt. Ob er angenommen wird, entscheidet sich an Details, die man einer Datei nicht ansieht. Shopware 6.7 bringt dafür einen eigenen Validator mit.

Wir wollten wissen, was er tatsächlich findet. Also haben wir ihn nicht gelesen, sondern ausgeführt.

Der Aufbau

Der Validator heisst OpenAiProductExportValidator und sitzt im Produktexport, nicht im Verkaufskanal. Wir haben ihn in einer laufenden 6.7.13.1-Installation instanziiert, einen Produktexport mit dem Provider open-ai und dem Dateiformat jsonl gebaut und elf Zeilen durchgereicht: eine vollständige und zehn, in die je ein gezielter Defekt eingebaut war.

Gemessen wurde nur eines — wie viele Einträge landen in der Fehlersammlung.

Das Ergebnis

Zehn von zehn. Der Validator lässt keinen der gebauten Defekte durch, und die korrekte Zeile geht fehlerfrei durch. Auch die Prüfung über Zeilengrenzen hinweg greift: Zwei Zeilen mit derselben item_id werden erkannt, obwohl jede für sich in Ordnung ist.

Eine defekte JSONL-Zeile erzeugt einen Fehlereintrag und keine Ausnahme — die Datei wird also nicht als Ganzes verworfen.

Der eigentliche Befund

Interessanter als die zehn Treffer ist, was auf dem Weg dorthin passiert ist.

Unser erster Durchlauf meldete null Fehler in allen elf Fällen. Nicht weil der Validator schlecht wäre, sondern weil er gar nicht gelaufen ist. Drei Vorbedingungen führen dazu, dass er ohne jede Meldung zurückkehrt:

Erstens: der Provider muss stimmen. Die Basisklasse bricht sofort ab, wenn der Produktexport nicht den passenden Provider trägt:

if ($productExportEntity->getProvider() !== $this->getProviderTechnicalName()) {
    return;
}

Kein Fehler, kein Hinweis. Ein Export mit falschem Provider sieht aus wie ein Export ohne Beanstandung.

Zweitens: das Dateiformat muss jsonl sein. Ist es das nicht, entsteht ein Fehler mit dem Feldnamen file_format — und die Prüfung endet, bevor eine einzige Zeile angesehen wurde. Das ist die freundlichere der drei Bedingungen, weil sie wenigstens etwas meldet.

Drittens — und das ist die wichtigste: Ist das Funktionsmerkmal für 6.8 aktiv, überspringt der Kern die Prüfung vollständig:

if (Feature::isActive('v6.8.0.0')) {
    // provider validation ships with SwagAgenticCommerce as of 6.8
    return;
}

Auf einem System, auf dem dieses Merkmal eingeschaltet ist, prüft der Kern also nichts — und meldet auch nicht, dass er nichts prüft.

Warum das zählt

Ein Prüfschritt, der unter bestimmten Bedingungen schweigt, ist gefährlicher als gar keiner. Er erzeugt dieselbe Ausgabe wie ein bestandener Test.

Wer einen Feed vorbereitet, sollte deshalb nicht fragen „gab es Fehler", sondern „wurde überhaupt geprüft". Ein einfacher Gegentest genügt: eine bewusst kaputte Zeile einschleusen. Kommt kein Fehler, prüft das System nicht — dann ist die Ursache eine der drei Bedingungen oben.

Dieses Muster ist nicht auf Shopware beschränkt. Es ist dieselbe Fehlerklasse wie eine Erweiterung, die nach einem Update still nichts mehr beiträgt: wenn der Shopware-Kern eine Plugin-Route verdrängt.

Was das für die Produktdaten heisst

Die Prüfliste des Validators ist unabhängig von Agentic Commerce brauchbar, weil sie beschreibt, was ein Käufer vor der Entscheidung sehen will. Drei Felder fallen in Projekten regelmässig durch:

return_policy ist eine URL. Ein Freitext wie „14 Tage Rückgaberecht" fällt durch. Es braucht eine erreichbare Seite.

store_country erwartet einen Ländercode. „Deutschland" wird abgelehnt, DE nicht.

price braucht eine Währung. Eine nackte Zahl reicht nicht.

Dazu kommt die Bedingung, die selbstgebaute Exporte am häufigsten bricht: Ist listing_has_variations wahr, wird group_id zur Pflicht — und item_id muss über den gesamten Feed eindeutig sein, nicht nur je Produkt.

Welche Felder insgesamt geprüft werden und wie der Verkaufskanal dazu passt, steht in Der Agentic-Commerce-Verkaufskanal in Shopware 6.7.

So stellen Sie den Test nach

Sie brauchen keine Testinstallation mit Produktdaten. Es genügt:

1. OpenAiProductExportValidator mit einem JsonlRowParser instanziieren
2. einen ProductExportEntity anlegen, provider auf open-ai und fileFormat auf jsonl setzen
3. eine JSONL-Zeile als String übergeben und die Fehlersammlung zählen

Der Aufwand liegt bei Minuten. Der Erkenntnisgewinn liegt darin, dass Sie danach wissen, ob Ihre Pipeline geprüft wird — statt es anzunehmen.