JTL Wawi Shopabgleich Fehlermeldung im Worker-Logbuch mit Fehler-Status rot markiert

JTL Wawi Shopabgleich mit Fehlern beendet: Ursachen finden und in vier Schritten beheben

Der JTL Worker meldet „Abgleich mit Fehlern beendet“ — und du weißt nicht, wo du anfangen sollst. Das Logbuch zeigt kryptische SQL-Meldungen oder ein HTTP-Fehlercode bricht den Sync mittendrin ab. Artikel kommen nicht im Shop an, Bestände stimmen nicht, und im schlimmsten Fall hängen Bestellungen. Der jtl wawi shopabgleich fehler gehört zu den häufigsten Support-Anfragen, die wir als JTL Service Partner Gold bearbeiten. Die Ursache ist fast immer eine von vier.

Dein Worker läuft, aber der Shopabgleich bricht immer wieder ab?

In diesem Beitrag zeigen wir dir, wie du die Ursache systematisch eingrenzt und den Abgleich wieder zum Laufen bringst. Ohne stundenlange Forum-Recherche.

Auf einen Blick

  • ✓Aus unseren JTL-Projekten zeigt sich: In über 60 Prozent der Fälle blockiert eine WAF oder ein Antivirusprogramm den dbeS-Sync-Prozess, auch wenn JTL Wawi selbst von der Firewall ausgenommen ist.
  • ✓Ein SQL-MERGE-Konflikt durch verwaiste Datensätze in der Shop-Datenbank ist die zweithäufigste Ursache: Das Worker-Logbuch zeigt dann die Meldung „MERGE-Anweisung schlägt fehl“ oder „Duplicate Entry“.
  • ✓Der erste Diagnoseschritt ist immer das Worker-Logbuch unter Wawi → Hilfe → Logbuch. Dort steht der genaue Fehlercode, der alles weitere bestimmt.

Wir wissen: Ein Shopabgleich-Fehler fühlt sich wie ein schwarzes Loch an. Der Worker dreht sich, das Logbuch spuckt Codes aus, und du weißt nicht, ob das Problem beim Server, beim Connector oder bei der Datenbank liegt. Als JTL Service Partner Gold in Ahrensfelde bei Berlin bearbeiten wir regelmäßig genau diese Fehlerbilder bei unseren Kunden. Was wir dabei gelernt haben: Die Diagnose-Reihenfolge entscheidet. Wer zuerst in die Datenbank greift, ohne die WAF geprüft zu haben, verliert Stunden. Laut dem offiziellen JTL-Worker-Guide (guide.jtl-software.com) sind Konfigurationsfehler auf Server-Ebene die häufigste Fehlerklasse beim Shopabgleich — vor Connector- und Datenbankproblemen. Ein Händler im JTL-Forum schrieb treffend: „Der Worker läuft praktisch durch, bis er mit einer Fehlermeldung den Dienst quittiert, und das Log verweist auf ein anderes Log, das ich gar nicht finde.“ Das ist typisch. Die Lösung liegt immer im richtigen Log an der richtigen Stelle.

Die vier häufigsten Ursachen für JTL Wawi Shopabgleich Fehler

Nicht jeder Abgleich-Fehler sieht gleich aus, aber die Ursachen wiederholen sich. Aus unseren Projekten und dem JTL-Forum kristallisieren sich vier Muster heraus, die zusammen über 90 Prozent der Fälle abdecken.

primary

WAF oder Antivirus blockiert den Worker

Das ist das häufigste Muster und gleichzeitig das schwierigste zu erkennen: Die Firewall oder der Antivirenscanner auf dem Server greift in den dbeS-Sync-Prozess ein — auch wenn JTL Wawi als Programm von der Firewall-Ausnahme erfasst ist. Der Worker-Prozess selbst oder der ausgehende HTTP-Request zur Shop-API wird gefiltert.

Das Symptom: Der Abgleich startet, überträgt einige Datensätze, bricht dann mit HTTP 403 oder einem Verbindungsfehler ab. Ein Testlauf ohne aktiven Virenschutz oder mit deaktivierter WAF löst das Problem sofort. Wir haben dieses Muster mehrfach bei Kunden gesehen, bei denen nachts ein automatischer Scan aktiv war. Genau dann, wenn der Worker seinen Abgleich-Zyklus gestartet hat.

warning

SQL-MERGE-Konflikt durch verwaiste Datensätze

Die Fehlermeldung lautet dann: „Eine MERGE-Anweisung kann dieselbe Zeile der Zieltabelle nicht mehrfach aktualisieren oder löschen.“ Das passiert, wenn die Shop-Datenbank verwaiste oder doppelte Einträge enthält: nach einem fehlerhaften Artikel-Import, einem abgebrochenen Abgleich oder einem Datenbankupdate, das Inkonsistenzen hinterlassen hat.

Das Muster tritt häufig nach einem Wawi- oder Shop-Update auf. Ein Händler im JTL-Forum beschrieb es so: „Wir haben das Update gemacht und haben den gleichen Fehler, sei es beim Worker, manuell oder sonst was.“ Die Datenbank-Ebene ist betroffen, nicht der Worker selbst. Ein Worker-Neustart hilft hier eben nicht.

highlight

SHOP-9083: Wartungsmodus-Bug nach Shop-5.6-Update

Nach dem Update auf JTL-Shop 5.6.0 haben mehrere Händler festgestellt, dass der Abgleich mit der Fehlermeldung „Beim Testen der Verbindung ist ein Fehler aufgetreten: Maintenance“ abbricht, auch wenn der Wartungsmodus im Shop-Backend scheinbar deaktiviert ist. Das ist ein bekannter Bug (SHOP-9083 im JTL-Issuetracker).

Der direkte Workaround: Wartungsmodus im JTL-Shop-Backend einmal aktivieren und danach vollständig deaktivieren. Das setzt den Status zurück. Läuft der Abgleich danach wieder, war SHOP-9083 die Ursache. JTL hat an einer dauerhaften Lösung gearbeitet; prüfe den Issuetracker auf den aktuellen Patch-Stand.

muted

HTTP-Timeout durch Server-Überlastung oder falsche Konfiguration

Der Webserver gibt während des Abgleichs einen HTTP 500 oder 503 zurück, weil ein Skript zu lange läuft, der Speicher ausgereizt ist oder ein PHP-Timeout greift. Der Worker meldet dann: „Der Remoteserver hat einen Fehler zurückgegeben: (503) Server nicht verfügbar.“ Das sieht nach einem Connector-Problem aus, ist aber meist eine Server-Ressourcen-Frage.

Typische Auslöser: Zu niedrige PHP-Speicherlimits (unter 256 MB), ein max_execution_time von 30 Sekunden bei großen Abgleichen, oder ein Hoster, der Traffic vom Worker-Prozess als ungewöhnlich einstuft und drosselt. Nach einem Cloudflare-Zertifikatswechsel tritt dieser Fehler ebenfalls auf, weil Cloudflare ZIP-Dateien filtert, die der Shop für den dbeS-Sync braucht.

Shopabgleich-Fehler in fünf Schritten systematisch eingrenzen

Die Reihenfolge ist entscheidend. Wer zuerst die Datenbank anfasst, ohne Server und Firewall geprüft zu haben, verliert Zeit. Dieser Plan orientiert sich an dem, was wir in unseren Projekten als Diagnose-Reihenfolge etabliert haben: von außen nach innen. Für JTL-spezifische Hintergründe zum Worker findet sich die technische Grundlage im offiziellen JTL-Worker-Guide: guide.jtl-software.com/jtl-wawi/jtl-worker/.

Logbuch lesen — genauen Fehlercode notieren (Schritt 1)

Öffne in JTL Wawi den Menüpunkt Hilfe → Logbuch. Filtere nach „Abgleich“ und notiere den genauen Fehlertext. Nicht nur „mit Fehlern beendet“, sondern die Zeile darunter. Steht dort „MERGE“, „Duplicate Entry“ oder „SQL“? Dann ist Ursache B wahrscheinlich. Steht dort „HTTP 403″, „503″ oder „Verbindung abgebrochen“? Dann liegt die Ursache auf Server-Ebene. Der Fehlercode bestimmt, welchen der nächsten Schritte du überspringen kannst.

Server und Firewall temporär deaktivieren (Schritt 2)

Deaktiviere Antivirenprogramm und WAF auf dem System, das den Worker ausführt, für einen kurzen Testlauf. Starte danach manuell einen Abgleich über Plattformen → Abgleich starten. Läuft der Abgleich jetzt durch? Dann ist Ursache A bestätigt. Die Lösung ist eine Ausnahmeregel für den Worker-Prozess und die dbeS-Kommunikation zur Shop-URL, kein dauerhaftes Deaktivieren des Schutzes. Wir konfigurieren diese Ausnahmen in unseren Projekten immer als Prozessausnahme, nicht als Portregel.

Wartungsmodus prüfen — SHOP-9083-Check (Schritt 3)

Melde dich im JTL-Shop-Backend an und prüfe unter Einstellungen → Shop-Einstellungen den Wartungsmodus-Status. Auch wenn er als deaktiviert angezeigt wird: Aktiviere ihn einmal und deaktiviere ihn danach wieder vollständig. Das setzt den internen Status zurück. Starte dann einen Verbindungstest über Wawi → Plattformen → Verkaufskanalverwaltung → Verbindung testen. Erscheint nicht mehr die Meldung „Maintenance“? Dann war SHOP-9083 der Auslöser.

PHP-Limits und Server-Ressourcen prüfen (Schritt 4)

Bei HTTP-500- oder HTTP-503-Fehlern prüfe im Hoster-Backend oder per SSH die PHP-Konfiguration: memory_limit sollte mindestens 256 MB betragen, max_execution_time mindestens 120 Sekunden für große Abgleiche. Cloudflare-Nutzer prüfen zusätzlich, ob der Proxy-Modus ZIP-Transfers filtert. Das ist ein bekannter Abgleich-Killer nach Zertifikatswechseln. Ein kurzer Test mit direkter IP statt Cloudflare-Proxy bestätigt oder schließt das aus.

Datenbank-Inkonsistenzen bereinigen (Schritt 5)

Nur wenn die Schritte 1-4 keine Lösung gebracht haben und das Logbuch SQL-MERGE-Fehler zeigt: Lass die Shop-Datenbank auf verwaiste Einträge prüfen. Das ist Datenbankarbeit. Ein falscher SQL-Befehl kann mehr Schaden anrichten als der ursprüngliche Fehler. Backup zuerst, dann einen JTL-Datenbankspezialisten oder uns direkt einschalten. Ein Komplettabgleich über Plattformen, Komplettabgleich kann danach helfen, den Sync-Zustand zwischen Wawi und Shop wieder herzustellen. Mehr zum Connector-Setup findest du auf unserer Seite zur JTL-Connector-Einrichtung.

Häufige Fragen zum JTL Wawi Shopabgleich Fehler

Wo finde ich das Worker-Logbuch in JTL Wawi?

Das Worker-Logbuch findest du in JTL Wawi unter Hilfe → Logbuch. Filtere die Ansicht nach dem betroffenen Abgleich-Zeitpunkt und suche nach Einträgen mit dem Status „Fehler“. Dort steht der genaue Fehlercode: zum Beispiel eine SQL-Meldung, ein HTTP-Statuscode oder der Hinweis „Maintenance“. Dieser Code ist der wichtigste Ausgangspunkt für jede Fehlerdiagnose. Ohne den genauen Fehlertext tappst du bei der Suche nach der Ursache im Dunkeln. Wichtig: Falls der Worker keinen neuen Eintrag schreibt, liegt ein anderes Problem vor — der Dienst selbst ist dann nicht aktiv. Nur ein vorhandener Fehlercode im Logbuch bestätigt, dass der Abgleich durchgelaufen und dabei gescheitert ist. Der JTL-Worker-Guide auf guide.jtl-software.com erklärt, wie du den Worker korrekt einrichtest und Logs interpretierst.

Die MERGE-Anweisung schlägt fehl, wenn die Shop-Datenbank verwaiste oder doppelte Datensätze enthält, die der Abgleich nicht eindeutig zuordnen kann. Das passiert häufig nach einem fehlerhaft abgebrochenen Abgleich, einem Datenbankupdate oder einem manuellen Eingriff in die Shop-Datenbank. Der Worker-Logbucheintrag zeigt dann: „Eine MERGE-Anweisung kann dieselbe Zeile der Zieltabelle nicht mehrfach aktualisieren oder löschen.“ Die Lösung liegt in der Bereinigung der Datenbankinkonsistenzen. Immer mit Backup, idealerweise von einem Spezialisten, weil ein falscher SQL-Befehl zusätzliche Schäden verursachen kann. Diskussionen zu diesem Fehlerbild findest du auch im JTL-Forum Thread 241736.

Ein HTTP-503-Fehler bedeutet, dass der Webserver die Anfrage des Workers nicht verarbeiten konnte: meist Überlastung, PHP-Timeout oder eine WAF-Regel. Prüfe die PHP-Konfiguration deines Servers: memory_limit mindestens 256 MB, max_execution_time mindestens 120 Sekunden. Wenn du Cloudflare nutzt und kürzlich das SSL-Zertifikat gewechselt hast, kann Cloudflare die ZIP-Dateien blockieren, die der Shop für den dbeS-Sync braucht. Ein Testlauf mit deaktiviertem Cloudflare-Proxy klärt das in Minuten.

SHOP-9083 ist ein bekannter Bug in JTL-Shop 5.6.0, bei dem der Abgleich abbricht, selbst wenn der Wartungsmodus im Shop-Backend deaktiviert scheint. Die Fehlermeldung in der Wawi lautet: ‚Beim Testen der Verbindung ist ein Fehler aufgetreten: Maintenance‘. Der direkte Workaround: Wartungsmodus im Shop-Backend einmal aktivieren und danach vollständig deaktivieren. Das setzt den internen Status zurück. Danach sollte der Verbindungstest in der Wawi unter Plattformen → Verkaufskanalverwaltung erfolgreich sein.

Antivirensoftware blockiert den Shopabgleich öfter als erwartet — auch wenn JTL Wawi als Programm von der Schutz-Software ausgenommen ist. Der Worker-Prozess selbst oder der ausgehende HTTP-Request zur Shop-API kann trotzdem gefiltert werden. Das Symptom: Der Abgleich startet, überträgt einige Datensätze und bricht dann mit einem Verbindungsfehler ab. Ein Testlauf mit deaktivierter Antivirensoftware oder WAF bestätigt oder schließt die Ursache schnell aus. Die dauerhafte Lösung ist eine Prozessausnahme für den Worker, kein dauerhaftes Deaktivieren des Schutzes.

Wenn der Worker hängt, läuft der Prozess, aber es passiert nichts: kein neuer Logbuch-Eintrag, kein Fortschritt. Das deutet auf einen abgestürzten oder blockierten Worker-Dienst hin; ein Neustart des Worker-Dienstes löst das oft. Wenn der Abgleich mit Fehlern beendet wird, hat der Worker einen vollständigen Durchlauf gemacht und dabei Fehler gemeldet. Das Logbuch enthält dann konkrete Fehlercodes. Das sind zwei verschiedene Diagnose-Pfade. Wir sehen in unserer täglichen Arbeit beide Muster, und der häufigste Fehler ist, beide gleich zu behandeln.

Nicht zwingend, aber bei SQL-MERGE-Fehlern gilt: keinen direkten Datenbankeingriff ohne Backup und Fachkenntnisse. JTL-Support hilft bei Shop-seitigen Bugs wie SHOP-9083. Für Datenbankbereinigungen, WAF-Konfigurationen und komplexe Connector-Probleme arbeiten Händler häufig mit einem JTL Service Partner Gold zusammen, der das Fehlerbild schnell einordnen kann. Wir als Vlarom E-Commerce Agentur übernehmen solche Diagnosen regelmäßig. Das Fehlerbild lässt sich nach einem Erstgespräch einordnen.

Shopabgleich-Fehler kosten täglich Bestellungen und Überblick. Wir finden die Ursache.

Vlarom löst deinen JTL Shopabgleich Fehler.

Als JTL Service Partner Gold in Ahrensfelde bei Berlin bearbeiten wir regelmäßig genau diese Fehlerbilder: WAF-Blockaden, SQL-Inkonsistenzen, Update-Bugs. Wir kennen das Logbuch, den Connector und die Shop-Datenbank. Ruf uns direkt an unter +49 30 91473862, schreibe an info@vlarom.de oder nutze unser Kontaktformular. Wir klären das Fehlerbild schnell. Für die technische Grundlage lohnt sich ein Blick auf unsere Seite JTL Wawi Einrichtung, dort zeigen wir, wie ein stabiler Connector-Aufbau von Anfang an Fehler vermeidet.

Autor

Alexander Luft

JTL Service Partner Gold · Vlarom E-Commerce Agentur · Ahrensfelde bei Berlin