Auf einen Blick
- ✓Als JTL Service Partner Gold setzen wir für Batch-Datenpflege bevorzugt den dateibasierten Weg über JTL-Ameise ein — er ist DSGVO-einfach, benötigt keinen offenen Datenbankport und funktioniert ohne Beta-Abhängigkeit.
- ✓Die JTL-Wawi REST-API (Open-Beta, aktuell kostenlos) ist der einzig offiziell unterstützte Weg für bidirektionale Automatisierungen — unsere Empfehlung für neue Projekte, sobald die Beta produktionsreif ist.
- ✓Direkter MSSQL-Zugriff auf die JTL-Datenbank ist für Lesezugriffe technisch möglich, aber unsupported: Schema-Brüche nach Wawi-Updates sind dokumentiert und entziehen dem System die JTL-Supportbasis.
Die Vlarom E-Commerce Agentur weiß aus der täglichen Partnerpraxis: Die entscheidende Frage beim Verbinden von JTL Wawi mit n8n ist nicht ob es geht, sondern welcher der vier Verbindungswege für welchen Anwendungsfall die richtige Risikobilanz hat. Diese Einschätzung gilt für JTL-Wawi-Umgebungen unter Windows mit Wawi ab Version 1.8 — die Verfügbarkeit der REST-API-Registrierung setzt die neue Wawi-Oberfläche voraus. Der Unterschied zwischen einem stabilen Workflow und einem der nach jedem Wawi-Update bricht, liegt genau in dieser Wegentscheidung. Wir haben alle vier Wege praktisch evaluiert: dateibasiert über JTL-Ameise, direkter MSSQL-Zugriff, JTL-Wawi REST-API (Open-Beta) und SQL2REST. Die Einschätzung unten basiert auf dieser Agenturerfahrung als JTL Service Partner Gold aus Ahrensfelde bei Berlin.
Was sich mit n8n und JTL automatisieren lässt
Drei typische Felder, in denen sich Aufwand spürbar senken lässt.
Schnittstellen
Datenflüsse zwischen JTL-Wawi und Drittsystemen — dort, wo der Standard-Connector aufhört.
Artikeldaten
Anreicherung großer Sortimente aus Hersteller- und Lieferantenquellen, importfertig für die Ameise.
Datenhoheit
Dateibasierte Brücken ohne offenen Datenbankport — die Daten bleiben auf der eigenen Infrastruktur.
Die 4 Wege JTL Wawi mit n8n zu verbinden
Die vier Wege unterscheiden sich erheblich in Schreibbarkeit, Risiko, Wartungsaufwand und DSGVO-Implikationen — hier der Gesamtüberblick:
| Verbindungsweg | Dateibasiert (Ameise CSV/Excel) | MSSQL direkt (n8n MS-SQL-Node) | JTL-Wawi REST-API (Open-Beta) | SQL2REST (lokaler Windows-Service) |
|---|---|---|---|---|
| Schreiben möglich? | Ja, über Ameise-Import-Vorlagen | Technisch ja — nicht empfohlen | Ja, Bearer-Token-gesichert | Nein — read-only |
| Offiziell unterstützt? | Ja (Ameise = offizielles JTL-Tool) | Nein — Schreibzugriff außerhalb Support | Ja (Beta-Programm, offiziell) | Drittanbieter-Produkt |
| Echtzeit? | Nein — dateibasiert, Schedule/on-demand | Ja (direkter DB-Zugriff) | Ja (Webhook + API-Call) | Ja (lesend) |
| Schema-Bruch-Risiko bei Wawi-Update? | Gering — Exportformat relativ stabil | Hoch — Tabellen/Spalten ändern sich | Gering — API-Versionierung vorgesehen | Mittel — abhängig von SQL2REST-Kompatibilität |
| DSGVO / Datenhoheit | Einfach — Dateien auf eigenem Server | Komplex — SA-Passwort-Risiko, Portöffnung | Gut — OAuth 2.0, Scope-Begrenzung | Gut — kein Cloud-Zugriff, lokal |
| Wann sinnvoll? | Batch-Prozesse: Artikelanreicherung, Bestandsimport, Preispflege | Nur lesend + Reporting, nie produktiv schreiben | Echtzeitautomatisierungen, bidirektionale Prozesse | Lesezugriff ohne DB-Port öffnen |
Vor dem Bauen entscheiden
Erst den Verbindungsweg festlegen (Echtzeit oder Batch?), dann das Werkzeug wählen. Diese Reihenfolge spart die meisten Nacharbeiten.
Die vier Wege in der Praxis — was du wirklich wissen musst
Jeder der vier Verbindungswege hat seine eigene Logik. Was in Marketing-Texten oft fehlt: die Bedingungen unter denen ein Weg bricht.
Von der Idee zur laufenden JTL-n8n-Automatisierung in 5 Schritten
Wer JTL mit n8n verbinden will, macht am häufigsten den Fehler, direkt mit dem Bauen anzufangen ohne den Verbindungsweg sauber zu entscheiden. Diese 5 Schritte verhindern das.
Anforderung klären: Echtzeit oder Batch? (vor dem Bauen)
Die wichtigste Frage zuerst: Muss der Prozess sofort reagieren (Bestelleingang, dann Lageranpassung) oder reicht ein stündlicher oder täglicher Batch? Für Echtzeit ist die REST-API der einzig tragfähige Weg. Für Batch-Prozesse ist der Ameise-Weg robuster und einfacher zu warten. Wer diese Frage nicht beantwortet, baut oft mit dem falschen Werkzeug. Häufigster Fehler: MSSQL direkt wählen weil es kurzfristig einfacher wirkt — und dann nach einem Wawi-Update feststellen, dass ein Tabellenname geändert wurde.
n8n-Infrastruktur einrichten: self-hosted auf VPS (Schritt 0.5 — nicht überspringen)
Für JTL-nahe Prozesse hat sich self-hosted n8n auf einem VPS bewährt (Docker Compose, Traefik als Reverse-Proxy, Volume-Mount für Daten und Credentials). Warum: Credentials für Wawi-DB-Zugriff, Ameise-SSH oder API-Tokens bleiben auf eurer Infrastruktur. Das offizielle Installationshandbuch unter docs.n8n.io/hosting/ zeigt den Setup mit Docker in unter 30 Minuten. Versions-Pinning im Docker-Compose-File schützt vor ungewollten Update-Breaks in produktiven Workflows.
Verbindungsweg implementieren und testen (trockener Lauf)
Je nach gewähltem Weg: (a) Dateibasiert: Ameise-CLI-Export per SSH-Node anstoßen, Datei via Read-Binary-File-Node einlesen, transformieren, als Import-Datei zurückschreiben. (b) REST-API: App-Registrierung in Wawi Admin, OAuth-Token im n8n Credentials-Store ablegen, HTTP-Request-Node für die Endpunkte konfigurieren. Der Token läuft nach 24 Stunden ab, daher Token-Refresh als eigenen Workflow vorbereiten. Beide Wege erst im Testsystem unter realen Bedingungen validieren, bevor sie produktiv laufen. Das JTL-Administratoren-Handbuch unter guide.jtl-software.com beschreibt die Ameise-CLI-Parameter (ame.exe) und die API-Registrierung detailliert.
Fehlerbehandlung und Monitoring aufbauen (unterschätzter Schritt)
n8n-Workflows die JTL berühren brauchen eine Fehlerbehandlung, die über eine rote Markierung im Canvas hinausgeht. Konkret: Error-Workflow mit Benachrichtigung (E-Mail oder Messaging-Tool) wenn ein Ameise-Import fehlschlägt, ein Token abläuft oder eine API-Antwort nicht dem erwarteten Schema entspricht. Wawi-Updates können dazu führen, dass Export-Spalten sich verschieben oder API-Antworten neue Felder bekommen. Ohne Monitoring bleibt das wochenlang unentdeckt. Bei dateibasierten Prozessen: die Ameise-Log-Datei auswerten, nicht nur auf Exit-Code prüfen.
Wartungsplan festlegen: Wawi-Updates beobachten
JTL-Wawi-Updates erscheinen mehrfach im Jahr. Jedes Update kann Ameise-Export-Templates oder API-Endpunkte beeinflussen. Wer n8n produktiv betreibt, braucht einen Prozess: (1) Wawi-Changelog vor jedem Update lesen auf Änderungen an Datenstruktur oder API, (2) nach dem Update einen Testlauf der Workflows vor dem Produktivgang, (3) für REST-API-basierte Prozesse die JTL-Releaseplanung beobachten (Beta-Ende und mögliche Kosten). Als JTL Service Partner Gold sehen wir bei Kunden am häufigsten Probleme, wenn Workflows nach einem Update nicht getestet werden und erst Wochen später auffällt, dass Daten fehlen oder falsch übertragen werden. In der Praxis vergehen häufig zwei bis vier Wochen, bis ungetestete Workflow-Brüche durch fehlende Daten im Tagesgeschäft auffallen. Ein 15-minütiger Testlauf direkt nach dem Update ist deutlich kürzer als die spätere Fehlersuche im laufenden Betrieb.
