JTL-Connector

Was macht der JTL-Connector genau?

Wer JTL-Wawi als Warenwirtschaft nutzen will, aber nicht JTL-Shop als Frontend, braucht eine Brücke zwischen den Systemen. Genau das ist die Aufgabe des JTL-Connectors: Er gleicht die zentralen Handelsdaten zwischen Wawi und einem Fremdshop ab, ohne dass die Wawi dafür ihre Rolle als führendes System verliert.

Synchronisiert werden im Kern dieselben Datenobjekte wie bei der nativen JTL-Shop-Anbindung:

• Artikel — Stammdaten, Beschreibungstexte, Bilder, Kategorien
• Bestände — laufender Abgleich, damit kein Kanal überverkauft
• Preise — inklusive Kundengruppen- oder Staffelpreisen, je nach Endpoint
• Bestellungen — vom Fremdshop zurück in die Wawi zur weiteren Auftragsabwicklung

Der Unterschied zum JTL-Worker liegt nicht in dem, was übertragen wird, sondern darin, wie: Der Worker spricht die native JTL-Shop-Schnittstelle, der Connector eine offenere, generische Schnittstelle, die sich an unterschiedliche Zielsysteme anpassen lässt.

Wie ist der Connector technisch aufgebaut?

Der JTL-Connector besteht aus zwei Bausteinen. Der Connector-Kern läuft auf Seiten der Wawi und stellt eine standardisierte Datenschicht bereit — quelloffen und unabhängig vom eigentlichen Zielsystem. Darauf setzt ein Endpoint auf: ein Plugin oder eine Erweiterung im Zielshop, das die generischen Connector-Datenstrukturen in die Sprache des jeweiligen Systems übersetzt, etwa in Shopware-Entities, die WooCommerce-REST-API oder die Shopify-Admin-API.

Diese Trennung ist der eigentliche Clou des Konzepts: Der Kern muss nicht für jedes Shopsystem neu erfunden werden, nur der Endpoint unterscheidet sich. Für Entwickler bedeutet das auch, dass sich fehlende Felder oder Sonderlogik gezielt am Endpoint nachrüsten lassen, ohne den Connector-Kern selbst anzufassen — ähnlich wie bei einer klassischen API-Schnittstelle, bei der die eigentliche Übersetzungsarbeit an den Rändern passiert, nicht im Kern.

JTL-Connector vs. JTL-Worker

Für Händler, die ohnehin JTL-Shop einsetzen, bleibt der Worker die einfachere, wartungsärmere Wahl. Der Connector kommt erst ins Spiel, wenn das Frontend bewusst außerhalb der JTL-Familie liegen soll — etwa, weil ein bestehender Shopify- oder Shopware-Shop nicht abgelöst werden soll, die Warenwirtschaft aber trotzdem auf JTL-Wawi umgestellt wird.

Welche Shopsysteme werden unterstützt?

Am ausgereiftesten ist in der Praxis die Anbindung an WooCommerce, für die ein offizieller Endpoint existiert. Für Shopware, Shopify und weitere Systeme gibt es Endpoints von Drittanbietern und spezialisierten Agenturen — hier lohnt sich vor der Entscheidung ein genauer Blick auf Pflegestand, unterstützte Felder und die Häufigkeit von Updates, denn die Qualität schwankt zwischen den Anbietern spürbar. Ein Endpoint, der seit Jahren nicht mehr aktualisiert wurde, ist bei größeren Shop- oder API-Updates ein Risiko.

Wo liegen die Grenzen des Connectors?

Der Connector deckt das Kerngeschäft solide ab, stößt aber an mehreren Stellen an Grenzen:

• Komplexe Varianten und Staffelpreise werden nicht immer vollständig abgebildet, wenn der Endpoint sie nicht explizit unterstützt.
• Sonderfelder aus der Wawi, die im Zielshop keine direkte Entsprechung haben, brauchen individuelle Mapping-Logik.
• Multishop-Setups mit mehreren angebundenen Fremdshops erhöhen den Pflegeaufwand nicht linear, sondern eher überproportional, weil jede Instanz eigene Kategoriezuordnungen und Preislogik braucht.
• Sehr komplexe Produktdatenmodelle — etwa mit vielen Attributgruppen und Cross-Selling-Regeln — sprengen häufig den Rahmen der generischen Connector-Struktur; hier hilft eher ein vorgeschaltetes PIM-System, das die Datenaufbereitung übernimmt, bevor sie überhaupt beim Connector ankommt.

Wann lohnt sich der Umstieg auf den Connector?

Sinnvoll ist der JTL-Connector vor allem, wenn die Stärken von JTL-Wawi — GoBD-konforme Belegführung, DATEV-Export, deutsche Versanddienstleister nativ, eine große Agentur- und Plugin-Landschaft — genutzt werden sollen, ohne das bestehende Shop-Frontend aufzugeben. Wer dagegen ohnehin plant, komplett auf JTL-Shop umzusteigen, spart sich mit der nativen Worker-Anbindung eine zusätzliche Fehlerquelle und geringeren Pflegeaufwand.

Typischer Ablauf einer Connector-Einrichtung

Eine Connector-Anbindung folgt in der Praxis fast immer derselben Reihenfolge:

1. Endpoint auswählen und prüfen — passenden Endpoint für das Zielsystem finden, Funktionsumfang und Pflegestand vorab bewerten.
2. Testumgebung aufsetzen — Connector-Kern und Endpoint zunächst gegen eine Kopie des Shops und eine Testinstanz der Wawi laufen lassen, nie direkt gegen das Live-System.
3. Feldmapping definieren — festlegen, welches Wawi-Feld auf welches Zielfeld im Shop abgebildet wird, inklusive Sonderfällen wie Varianten oder Staffelpreisen.
4. Erstsynchronisation und Stichproben — einen überschaubaren Teil des Sortiments übertragen und die Ergebnisse im Zielshop manuell gegenprüfen, bevor das gesamte Sortiment folgt.
5. Laufender Betrieb mit Monitoring — Synchronisationsintervalle festlegen und eine Kontrolle einrichten, die einen stillstehenden Connector zeitnah meldet.

Wie beim JTL-Worker gilt auch hier: Der größte Zeitanteil entfällt selten auf die technische Installation, sondern auf sauberes Feldmapping und Tests — wer diesen Schritt abkürzt, zahlt die Zeit später in Form von Datenkorrekturen im Livebetrieb zurück.

Connector und Multichannel-Strategie

Für Händler, die parallel mehrere Verkaufskanäle betreiben, ist der Connector meist nur ein Baustein neben der Marktplatz-Anbindung über eazyAuction. Die Wawi bleibt dabei die zentrale Datenquelle für Artikel und Bestand, während Connector und eazyAuction parallel unterschiedliche Ausgabekanäle bedienen — ein Fremdshop auf der einen, Amazon oder eBay auf der anderen Seite. Wichtig ist dabei, dass beide Synchronisationswege unabhängig überwacht werden: Fällt der Connector aus, bleibt der Marktplatz-Vertrieb über eazyAuction trotzdem funktionsfähig und umgekehrt, solange die Wawi selbst als gemeinsame Datenbasis intakt bleibt.

Typische Fehler bei der Connector-Einrichtung

1. Endpoint-Qualität nicht vorab geprüft — ein veralteter oder schlecht gepflegter Drittanbieter-Endpoint wird schnell zum Flaschenhals bei jedem Shop-Update.
2. Feldmapping zu spät durchdacht — wer Sonderfelder erst nach dem Go-Live entdeckt, muss bestehende Datensätze nachträglich korrigieren.
3. Kein Monitoring der Synchronisation — anders als beim Worker gibt es keine einheitliche Job-Historie über alle Endpoints hinweg; ein Ausfall bleibt sonst unbemerkt.
4. Multishop ohne getrenntes Testkonzept — Änderungen an einer Connector-Instanz versehentlich auf eine andere übertragen, weil Konfigurationen nicht sauber getrennt sind.
5. Connector als Ersatz für fehlende Datenpflege missverstanden — der Connector synchronisiert vorhandene Daten, er bereinigt keine unsauberen Artikelstammdaten.

Die Einrichtung eines JTL-Connectors ist selten ein Standardprojekt von der Stange, sondern verlangt individuelles Feldmapping und Tests je Zielsystem. Als E-Commerce-Agentur übernehmen wir die Anbindung und richten sie gemeinsam mit der JTL-Wawi-Basis ein.