JTL-Worker

Was macht der JTL-Worker genau?

Der JTL-Worker ist das Bindeglied zwischen der zentralen JTL-Wawi und allen angeschlossenen Verkaufskanälen. Ohne ihn wäre die Wawi ein reines Insel-System — mit ihm werden Änderungen automatisch in beide Richtungen übertragen:

• Wawi → Shop: neue Artikel, Preisänderungen, Bestandsupdates, Kategoriezuordnungen
• Shop → Wawi: eingehende Bestellungen, Kundendaten, Zahlungsstatus
• Wawi → Marktplätze: Angebote, Preise, Bestände über eazyAuction oder native Schnittstellen
• Marktplätze → Wawi: Bestellungen, Nachrichten, Bewertungsdaten

Technisch ist der Worker ein eigenständiger Windows-Dienst, der unabhängig von der Wawi-Anwendung selbst läuft. Er greift auf dieselbe SQL-Server-Datenbank zu und arbeitet eine Warteschlange aus Synchronisationsjobs ab, die die Wawi beim Speichern von Änderungen anlegt. Wichtig dabei: Der Worker verändert selbst keine Geschäftslogik, er überträgt nur Daten — Preisberechnungen, Rabattlogik oder Steuersätze bleiben Aufgabe der Wawi bzw. des Shopsystems.

Wie funktionieren die Abgleich-Intervalle?

Der Worker arbeitet nicht in Echtzeit, sondern in konfigurierbaren Zyklen. Jede Job-Kategorie hat ein eigenes Intervall, das sich an der Dringlichkeit der Daten orientiert:

Wichtig: Kürzere Intervalle bedeuten mehr Last auf Datenbank und API-Schnittstellen der Marktplätze — Amazon und eBay limitieren Anfragen pro Zeiteinheit. Wer zu aggressiv taktet, riskiert Drosselung durch die Marktplatz-APIs statt schnellerer Synchronisation. In der Praxis hat sich eine klare Priorisierung bewährt: Bestand und eingehende Bestellungen eng takten, weil hier jede Verzögerung direkt Umsatz oder Kundenvertrauen kostet — Stammdaten und Beschreibungstexte dagegen deutlich lockerer, weil eine neue Produktbeschreibung selten in der nächsten Minute live sein muss.

Abgleich-Troubleshooting: Wie liest man die Job-Historie?

Bevor an Intervallen oder Server-Ressourcen geschraubt wird, lohnt sich immer zuerst ein Blick in die Job-Historie der JTL-Wawi-Administration. Dort wird jeder Synchronisationsjob mit Status — wartend, läuft, abgeschlossen, fehlgeschlagen — und Zeitstempel protokolliert. In der Praxis tauchen vor allem drei Muster auf:

• Vereinzelte fehlgeschlagene Jobs mit Fehlertext: meist ein konkretes, lösbares Problem — eine ungültige Artikelnummer, ein fehlendes Pflichtfeld für einen Marktplatz oder ein abgelaufenes API-Token. Der Fehlertext grenzt die Ursache in der Regel schon ein.
• Wachsende Warteschlange ohne Fehlermeldungen: Der Worker arbeitet, kommt aber nicht hinterher — ein Kapazitätsproblem, kein Fehler im engeren Sinn. Hier helfen entzerrte Intervalle oder eine Prüfung der Datenbank-Performance, bevor weitere Jobs draufgepackt werden.
• Komplett leere Historie trotz bekannter Änderungen: Das deutet auf einen gestoppten oder abgestürzten Dienst hin — ein Blick in die Windows-Dienste zeigt, ob der Worker-Prozess überhaupt noch läuft.

Treten Fehler wiederholt nur bei einem einzelnen Kanal auf, etwa nur bei Amazon und nicht bei eBay, lohnt sich zuerst die Prüfung genau dieser API-Anbindung, statt gleich den gesamten Worker zu verdächtigen — Marktplatz-APIs ändern Formate, laufen in Wartungsfenster oder sperren Zugänge unabhängig vom Rest der Synchronisation.

Wo läuft der Worker und was braucht er?

Der Worker läuft typischerweise auf demselben Server wie die JTL-Wawi oder einer separaten Maschine mit Zugriff auf die Datenbank. Er braucht eine stabile, dauerhafte Internetverbindung — fällt er aus, stapeln sich offene Jobs, bis er wieder anläuft. Bei Shop-Anbindung über NOVA-Template-basierte Shops läuft der Datenaustausch über die JTL-Shop-Schnittstelle, die der Worker regelmäßig abfragt.

Bei gehosteten Wawi-Lösungen übernimmt der Hosting-Anbieter meist auch den Betrieb des Worker-Dienstes inklusive Neustart-Automatik. Bei selbst betriebenen Servern lohnt sich ein einfaches externes Monitoring, das prüft, ob der Dienst noch aktiv ist und Jobs in angemessener Zeit abgearbeitet werden — Ausfälle über Nacht oder am Wochenende bleiben sonst leicht tagelang unbemerkt. Praktisch bewährt haben sich zwei Bausteine: ein Windows-Dienst mit automatischem Neustart bei Absturz sowie ein externer Uptime-Check, der in festen Abständen prüft, ob die Job-Warteschlange tatsächlich abgearbeitet wird und nicht nur „der Dienst läuft" meldet — ein technisch aktiver, aber blockierter Worker sieht auf den ersten Blick genauso gesund aus wie ein funktionierender.

Worker und Marktplatz-Synchronisation über eazyAuction

Bei Marktplatz-Anbindungen über eazyAuction übernimmt der Worker zusätzlich die Rolle, Angebotsdaten, Preise und Bestände aus der Wawi in das eazyAuction-Format zu übersetzen und regelmäßig zu übertragen. Fehler auf dieser Strecke wirken sich unmittelbar auf sichtbare Angebote bei Amazon, eBay oder Kaufland aus — etwa wenn eine fehlerhafte Preisregel über den Worker an alle Kanäle gleichzeitig ausgespielt wird. Deshalb lohnt sich bei Preisänderungen im großen Stil ein Blick in die Job-Protokolle, bevor man sich auf die automatische Verteilung verlässt. Ein einfacher Praxis-Kniff: größere Preis- oder Attributänderungen zuerst an einer kleinen Testgruppe von Artikeln durchlaufen lassen und die Job-Historie sowie die Kanal-Ansicht prüfen, bevor die Änderung auf das gesamte Sortiment ausgerollt wird.

Ein Worker oder mehrere Worker-Instanzen?

Für die meisten Händler reicht ein einzelner Worker-Dienst, der mehrere Mandanten und Kanäle gleichzeitig bedient — das ist die Standardkonfiguration der meisten JTL-Installationen. Eine Aufteilung auf mehrere Worker-Instanzen oder sogar mehrere Server lohnt sich erst, wenn mehrere dieser Signale zusammenkommen:

• Die Job-Warteschlange wächst dauerhaft, obwohl Intervalle bereits sinnvoll gestaffelt sind und die Datenbank-Performance grundsätzlich ausreicht.
• Mehrere Mandanten mit hohem Auftragsvolumen laufen über dieselbe Wawi-Instanz und konkurrieren spürbar um Rechenzeit.
• Sehr viele Marktplatz-Kanäle mit jeweils eigenen Rate-Limits sollen gleichzeitig zeitnah bedient werden.
• Zeitkritische Bestände, etwa bei knapper, schnell drehender Ware, vertragen keine Verzögerung durch eine überlastete gemeinsame Warteschlange.

Fehlen diese Treiber, bringt eine zweite Worker-Instanz vor allem zusätzliche Betriebskomplexität — zwei Dienste, die überwacht und bei Updates synchron gehalten werden müssen — ohne spürbaren Geschwindigkeitsgewinn. Die Aufteilung ist ein Skalierungswerkzeug für einen konkreten Engpass, kein Standard-Setup für den Start.

Typische Probleme mit dem JTL-Worker

1. Dienst läuft, aber Jobs stauen sich — meist ein Zeichen für überlastete Datenbank-Performance oder zu kurz getaktete Intervalle bei großem Sortiment. Abhilfe: Intervalle staffeln, Server-Ressourcen prüfen.
2. Bestandsdifferenzen zwischen Wawi und Shop — entstehen oft durch parallele manuelle Änderungen im Shop-Backend, die der Worker überschreibt oder ignoriert, weil die Wawi als führendes System gilt.
3. Worker-Dienst stoppt unbemerkt — ohne Monitoring bleibt das oft tagelang unentdeckt, bis Kunden nicht lieferbare Artikel bestellen. Ein einfacher Health-Check (z. B. per Cronjob oder Uptime-Monitoring auf einen Status-Endpunkt) verhindert das.
4. Marktplatz-Rate-Limits — bei zu vielen parallelen Anfragen sperren Amazon oder eBay temporär die API, was die Synchronisation für alle Kanäle verzögert.
5. Update-Sprünge — nach größeren JTL-Wawi-Updates verändert sich mitunter das Job-Verhalten; ein Blick in die Job-Historie nach jedem Update lohnt sich.

Worker-Einrichtung als Teil der Shop-Basis

Die korrekte Konfiguration der Worker-Intervalle entscheidet maßgeblich darüber, ob ein Shop verlässlich Bestände zeigt oder überverkauft. Bei der Einrichtung eines neuen JTL-Shop-Systems gehört die Worker-Konfiguration zu den Punkten, die wir als JTL Agentur standardmäßig mit einrichten und dokumentieren.