Hallo zusammen,
ich hoffe, ihr seid gut ins neue Jahr 2026 gestartet und wünsche euch ein gesundes und erfolgreiches neues Jahr.
Ich beschäftige mich aktuell intensiv mit der technischen Frage, wie sich in JTL-Wawi ein strikt sequenzieller Export umsetzen lässt, und stoße dabei an konzeptionelle Grenzen des Workflow-Systems.
Zielsetzung
Bekannte Rahmenbedingungen
Aktueller technischer Ansatz
Ich nutze einen zeitgesteuerten Workflow (alle 2 Minuten), der seinen Zustand vollständig aus der Datenbank liest.
Der Verarbeitungszustand wird in einer kundenspezifischen Tabelle gespeichert, konkret in:
[Kunde].[tKundeEigenesFeld]
Beispiel zum Lesen des Zustands:
Der Wert enthält einen Cursor in folgendem Format:
CURSOR=2025-01-01 12:34:56.789|K=123456
Dabei dient dErstellt als primärer Cursor und kKunde als Tie-Breaker bei identischem Zeitstempel.
Der Workflow führt dann folgende Schritte aus:
Damit erreiche ich aktuell:
Technisch funktioniert das zuverlässig, fühlt sich aber eher wie ein Workaround als wie ein „offizieller“ Lösungsweg an.
Zentrale Frage
Gibt es in JTL-Wawi eine saubere, empfohlene Möglichkeit, Workflows datenbank- oder statusgetrieben auszulösen, oder ist ein zeitgesteuerter Workflow mit SQL-gesteuertem Zustand tatsächlich der vorgesehene Weg?
Konkret interessieren mich folgende Punkte:
Alternative Überlegung
Statt eines Cursors wäre auch eine explizite Queue denkbar, zum Beispiel:
Workflow-seitig dann:
Wird ein solches Muster in JTL-Umgebungen produktiv eingesetzt?
Zusammenfassung
Mir ist bewusst, dass JTL-Workflows nicht datenbank-event-getrieben sind. Ich suche daher keine Umgehung, sondern eine architektonisch saubere, langfristig wartbare Lösung für eine strikt sequenzielle Verarbeitung.
Erfahrungen, Hinweise oder offizielle Empfehlungen wären sehr hilfreich.
ich hoffe, ihr seid gut ins neue Jahr 2026 gestartet und wünsche euch ein gesundes und erfolgreiches neues Jahr.
Ich beschäftige mich aktuell intensiv mit der technischen Frage, wie sich in JTL-Wawi ein strikt sequenzieller Export umsetzen lässt, und stoße dabei an konzeptionelle Grenzen des Workflow-Systems.
Zielsetzung
- Alle 2 Minuten soll genau ein Kunde verarbeitet bzw. exportiert werden.
- Die Verarbeitung muss strikt aufsteigend erfolgen, z. B. nach tKunde.dErstellt.
- Es dürfen keine Doppel-Exporte auftreten, auch nicht bei Fehlern oder Wiederholungen.
- Der Ablauf soll deterministisch, wartbar und supportfähig sein.
Bekannte Rahmenbedingungen
- JTL-Workflows lassen sich nicht direkt per SQL triggern.
Änderungen per INSERT oder UPDATE in der Datenbank lösen keinen Workflow aus. - Direkte Updates auf dbo.tKunde sind bei uns per Trigger blockiert.
Änderungen sind nur über Kunde.spKundeInsert, Kunde.spKundeUpdate und Kunde.spKundeDelete erlaubt. - Lesen per DirectQuery innerhalb von Workflows funktioniert zuverlässig.
Schreiben in andere Tabellen außerhalb von tKunde ist möglich.
Aktueller technischer Ansatz
Ich nutze einen zeitgesteuerten Workflow (alle 2 Minuten), der seinen Zustand vollständig aus der Datenbank liest.
Der Verarbeitungszustand wird in einer kundenspezifischen Tabelle gespeichert, konkret in:
[Kunde].[tKundeEigenesFeld]
Beispiel zum Lesen des Zustands:
SQL:
SELECT cWertVarchar
FROM [Kunde].[tKundeEigenesFeld]
WHERE kKunde = 1936
AND kAttribut = 315;Der Wert enthält einen Cursor in folgendem Format:
CURSOR=2025-01-01 12:34:56.789|K=123456
Dabei dient dErstellt als primärer Cursor und kKunde als Tie-Breaker bei identischem Zeitstempel.
Der Workflow führt dann folgende Schritte aus:
- Cursor aus der Tabelle lesen
- Nächsten Kunden bestimmen
SQL:
SELECT TOP 1 kKunde, dErstellt
FROM dbo.tKunde
WHERE
dErstellt > @lastDate
OR (dErstellt = @lastDate AND kKunde > @lastK)
ORDER BY dErstellt ASC, kKunde ASC;- Genau diesen Kunden exportieren
- Cursor nach erfolgreichem Export fortschreiben
SQL:
UPDATE [Kunde].[tKundeEigenesFeld]
SET cWertVarchar = 'CURSOR=2025-01-01 12:36:00.000|K=123789'
WHERE kKunde = 1936
AND kAttribut = 315;Damit erreiche ich aktuell:
- Exakt einen Kunden pro Workflow-Lauf
- Eine stabile, deterministische Reihenfolge
- Keine direkten Änderungen an dbo.tKunde
Technisch funktioniert das zuverlässig, fühlt sich aber eher wie ein Workaround als wie ein „offizieller“ Lösungsweg an.
Zentrale Frage
Gibt es in JTL-Wawi eine saubere, empfohlene Möglichkeit, Workflows datenbank- oder statusgetrieben auszulösen, oder ist ein zeitgesteuerter Workflow mit SQL-gesteuertem Zustand tatsächlich der vorgesehene Weg?
Konkret interessieren mich folgende Punkte:
- Gibt es eine Möglichkeit, Workflows indirekt per SQL oder DB-Zustand zu triggern.
- Gibt es offizielle oder etablierte Best Practices für streng sequenzielle Exporte.
- Setzt jemand produktiv eine Queue-Tabelle ein, die von einem Workflow abgearbeitet wird.
- Gibt es bekannte Fallstricke bei Cursor- oder Queue-basierten Ansätzen in JTL.
Alternative Überlegung
Statt eines Cursors wäre auch eine explizite Queue denkbar, zum Beispiel:
SQL:
CREATE TABLE tExportQueue (
kID INT IDENTITY PRIMARY KEY,
kKunde INT,
Status TINYINT,
dCreated DATETIME
);Workflow-seitig dann:
SQL:
SELECT TOP 1 kKunde
FROM tExportQueue
WHERE Status = 0
ORDER BY dCreated;Wird ein solches Muster in JTL-Umgebungen produktiv eingesetzt?
Zusammenfassung
Mir ist bewusst, dass JTL-Workflows nicht datenbank-event-getrieben sind. Ich suche daher keine Umgehung, sondern eine architektonisch saubere, langfristig wartbare Lösung für eine strikt sequenzielle Verarbeitung.
Erfahrungen, Hinweise oder offizielle Empfehlungen wären sehr hilfreich.
). Du bewegst Dich mit dem UPDATE doch eh in einem CustomWorkflow, also rein auf Datenbankebene. Das widerspricht irgendwie der Wartbarkeit innerhalb der Wawi. Oder lässt Du ein externes SQL-Skript sowohl durch den Workflow schreiben als auch starten?