Verwiesen an Support Workflow Queue wächst an und arbeitet nicht mehr ab

[Stephan K.]

Hi,

das Problem, dass Rechnungen und Gutschriften nicht erstellt werden, weil der Workflow irgendwo hängt, ist ja nicht neu. Ich habe eine Batch-Datei, die mir am Ende jeden Monats nach vorheriger Umbenennung die Nummerierung prüft und Lücken aufzeigt. Soweit nichts Neues. Das Problem führe ich auf mangelnde Sorgfalt bei der Programmierung zurück, denn das gab es vorher nicht. Es werden also nicht die notwendigen Rechnungen und Gutschriften ausgegeben zur GoBD-Archivierung.

Das ganze hängt wohl mit zeitversetzten workflows zusammen wie hier im Forum schonmal erwähnt, aber ohne Lösung noch offen als Thread (Monate her).
Daher die Frage: Wer hat hier eine Lösung oder das gleiche Problem?
Zeitversetzt sind Stornos und Zahlungserinnerungen für Shop-Bestellungen sowie Amazon-Rechnungen. Mehr als diese 3 Stück gibt es nicht, doch die Queue wächst ewig an mit sinnlosesn tasks (selbst Amazon-Bestellungen werden - obwohl keine Shop-Bestellung - ewig in dieser Liste geführt).

 

[elevennerds.de]

Ich habe hier ein ähnliches Problem, die Queue baut sich immer weiter auf, teilweise eine Stunde und mehr im Rückstand.

Eine Lösung ist es, gut mit zeitversetzten und Sofort-Workflows zu haushalten. Einen weiteren positiven Effekt hat die Umstellung auf die neuen Vorlagen gebracht.

 

[Stephan K.]

Ja. Ich habe die Queue gestern mal gelöscht und es wurden schon wieder ALLE Bestellungen zu den Shop-Stornos mit in die Liste genommen. Dabei ist die erste Bedingung: "Ist Shop?" und erst danach "Ist 7 Tage alt?" Aber selbst Amazon-Bestellungen werden nicht verworfen und on-hold gesetzt. Das ist irgendwie ineffizient.

Danke für den Tipp mit den neuen Vorlagen. Das sollte ich mal probieren. Ich kann mir vorstellen, dass er hier die Bausteine im Speicher hält und nicht jedes Mal die Vorlage neu aufbauen muss und man dabei Zeit spart.

Wenn ich per workflow die Rechnungen zur Archivierung ausgeben lasse, dauert das inzwischen mehrere Sekunden!
Mache ich es per Ausgabe>Rechnung>Erweitert>Vorlage manuell geht das wie gewohnt ratzfatz.

Ich werde das mit der Vorlage also mal probieren, denke aber nicht, dass es primär daran liegt. Ich denke das ist eine Langsamkeit in der workflow Abarbeitung, die irgendwas doppelt und dreifach prüft oder auch unlogische Dinge abarbeitet (Ist Shop? Nein. Ist bezahlt? Ja. Trotzdem mit in Liste der Shop-Stornos als Beispiel)

 

[hula1499]

Du musst halt schon berücksichtigen, dass JEDER Auftrag, ALLE Workflows zumind. im Bereich "Auftrag" 1x durchläuft.

Hast du also, zb. 30 Workflows unter Aufträge, läuft dein Auftrag, egal woher er kommt (ama, ebay, shop...) jeden dieser Workflows 1x durch.
Hast dann noch 10 Workflows in Auftrag geändert, selbiges nochmal (für die geänderten WF).

 

[Arne Janson]

Moin @Stephan K.
"Langsamkeit in der Workflow Abarbeitung," ich schätze nicht das hier das Problem liegt. Die Workflow Queue kann mit jedem Workerabgleich "viele" Aufträge abarbeiten. Ansonsten kannst du ja ein Ticket beim JTL Support aufmachen, dann können die es sich ansehen und finden evtl. eine Lösung.

 

[Stephan K.]

@Arne Janson
Ja, ich mache ein Ticket auf. Gerade heute wieder ist er nach 17 Speichervorgängen hängengeblieben und die Queue arbeitet nicht mehr weiter.

Es wurde nichts geändert außer das Update auf 1.5.34 gemacht

@hula1499
Ja, dass er jeden Workflow angeht, ist ja okay. Aber dass er trotz verweigerter Bedingungen nicht den Auftrag verwirft, sondern ihn in der Warteschleife hält, ist nicht erklärbar.

 

[Gökhan Basoglu]

Hallo Stephan,

ja genau. Mach mal ein Ticket dann schauen wir uns das gerne mal an.

 

[elevennerds.de]

Gerade heute wieder ist er nach 17 Speichervorgängen hängengeblieben und die Queue arbeitet nicht mehr weiter.

Ich habe mir im Monitoring jetzt folgende Queries eingerichtet, um zumindest eine Meldung zu erhalten, wenn die Queue wieder hängt:

Nur geeignet für JTL-WAWI Version 1.5.x

SELECT TOP 1
tWorkflowLog.dDatum,
tWorkflow.cName,
tWorkflowLog.cLog
FROM tWorkflowLog
JOIN tbenutzer ON tbenutzer.kBenutzer = tWorkflowLog.kBenutzer
JOIN tWorkflow ON tWorkflow.kWorkflow = tWorkflowLog.kWorkflow
WHERE tWorkflowLog.kWorkflowAktion != -1
AND tbenutzer.cLogin = :cLogin
AND (tWorkflow.nSchedulerHour + tWorkflow.nSchedulerMinute + tworkflow.nSchedulerDayValue + tWorkflow.nSchedulerMonthValue) > 0
ORDER BY tWorkflowLog.dDatum DESC

:cLogin muss durch den Benutzer, unter dem der Worker läuft ersetzt werden. Dieser Query gibt mir den Zeitpunkt der letzten erfolgreichen zeitversetzten Workflowausführung zurück.

Nur geeignet für JTL-WAWI Version 1.5.x

SELECT COUNT(tWorkflowQueue.kWorkflowQueue) AS [nQueue]
FROM tWorkflowQueue
WHERE tWorkflowQueue.dStartDate < GETDATE() 
AND tWorkflowQueue.nStatus != 3

Dieser Query gibt dir die Anzahl der wartenden Workflows zurück.

Nun prüft das Monitoring ob es in der Queue Workflows zum ausführen gibt (Query 2), falls ja, prüft er, wann der letzte Workflow ausgeführt wurde. Ist dieser Zeitpunkt länger als X Minuten her > Alarm.

Nach ein wenig testen fahre ich nun folgendes Setup: die Queue muss mehr als 3500 Workflows enthalten und Query 1 muss mindestens einen Zeitpunkt zurück liefern, der nicht älter als 10 Minuten ist. Diese Zahlen sind natürlich von der Anzahl der Workflows und Aufträge abhängig.

Im nächsten Schritt werden ich mir die Tabellen WorkflowQueue und WorkflowLog im Fehlerfall dumpen, um eventuelle fehlerhafte Workflows aufzuspüren.

Wie immer in der Datenbank: ALLES AUF EIGENE GEFAHR! Datenbankbackup machen!

Wer Verbesserungen an den Queries findet, immer her damit.

 

[garifulin]

@Stephan K. Hallo Stphan,
Hast du schon eine Lösung?
Ich hatte mal einen Zeitverzögerten WF, der 7 Tage nach Auftragserstellung laufen sollte und dieser hat Queue nach 3 oder 4 Wochen komlett überfluttet und damit auch den WF der nach 1sec laufen sollte um die Rechnungen zu archivieren wurde dann auch nicht mehr ausgeführt + + +
Nun habe ich die Aufgabe bekomme wieder einen Zeitverzögerten WF zu erstellen der auf nicht bezahlte Vorkasse Aufträge abzielt und ich möchte das wiederhollte voll laufen der Queue verhindern.


Edit: meine Idee wäre evtl. 2 WF´s zu erstellen. Einen Sofort WF der Aufträge prüft auf Vorkasse und einen Zweiten WF der in x Tagen anläuft und Erinnerungs Mails generiert. Nur wie?

 

[Stephan K.]

@Stephan K. Hallo Stphan,
Hast du schon eine Lösung?
Ich hatte mal einen Zeitverzögerten WF, der 7 Tage nach Auftragserstellung laufen sollte und dieser hat Queue nach 3 oder 4 Wochen komlett überfluttet und damit auch den WF der nach 1sec laufen sollte um die Rechnungen zu archivieren wurde dann auch nicht mehr ausgeführt + + +
Nun habe ich die Aufgabe bekomme wieder einen Zeitverzögerten WF zu erstellen der auf nicht bezahlte Vorkasse Aufträge abzielt und ich möchte das wiederhollte voll laufen der Queue verhindern.


Edit: meine Idee wäre evtl. 2 WF´s zu erstellen. Einen Sofort WF der Aufträge prüft auf Vorkasse und einen Zweiten WF der in x Tagen anläuft und Erinnerungs Mails generiert. Nur wie?

Moin,

eine der Lösungen für zeitversetzte Workflows war, dass z.B. Rechnungserstellung und Rechnungsausgabe (Archiv) nicht beide zeitversetzt laufen. Wenn Workflows auf ein und das gleiche zugreifen, gibt es scheinbar kein Prioritätensystem und das schafft die Wawi einfach nicht.
Ein weiteres "Logikproblem" ist, dass man Workflows ohne Bedingungen mit "Alle Bedingungen" einschalten muss und nicht wie es nahe liegend ist mit "Keine Bedingung."

Ich habe auch einen zeitversetzten Workflow für unbezahlte Vorkasse-Aufträge im Webshop. Hier werden trotz Vorbedingungen auch immer alle Aufträge abgelegt und in der Schlange vorrätig gehalten.

 

[garifulin]

@Stephan K. ich hoffe ich darf deinen Thread ein wenig als erinnerungsstütze missbrauchen.
Folgende idee ist mir heute Morgen gekommen.
Ich erstelle 3 Workflows.
1WF sofort bei Auftragserstellung prüft die Bezahlart auf "Vorkasse" und lösst damit den zweiten WF auf
2WF ist ein Manueller WF der zeitverzögert in 7 Tagen starten soll und bei fehlendem Zahlungeingag die Kunden an die Ausstehende Zahlung erinnert + den dritten WF aktiviert
3WF ist ein Manueller WF der zeitverzögert in 7 Tagen starten soll, wenn Auftrag weiterhin unbezahlt ist soll der Auftrag storniert werden.

Ich denke so könnte man die Queue erheblich entlasten

 

[forumjtlolshopag]

Habens aktuell auch gerade beobachtet. Kam bei eurem Ticket was raus, woran es gelegen hat? Wir sind bei 1.5.53.2. Laut Abfrage von @elevennerds.de haben wir >10.000 Workflows im Queue die nicht abgearbeitet sind. Schon heftig, da scheint auch einiges von früher hängen geblieben zu sein. Wir prüfen das noch weiter nach und machen da nochmal ein Ticket für auf.

 

[Scubarpro]

hi,

gleiches hier. Gibt es eine Lösung ?

VG

 

[Arne Janson]

Worker schon mal neu gestartet?
Ab der 1.6 kann der Worker 2.0 ja als Dienst eingerichtet werden und die Workflows können dann alle 1 Min getriggert werden.
Die wenigsten Kunden von uns sind noch auf der 1.5 unterwegs => meisten 1.6/1.7

MfG

Arne Janson

 

[Scubarpro]

Hi Arne,

den Worker Neuzustarten hat Abhilfe geschaffen. Danke Dafür !

VG

 

[HellwegDruckerei]

Wir müssen inzwischen 2-3 täglich den Worker neustarten weil sich die "Workflows" aufhängen. Merken es zwischendurch dann wenn Versandarten nicht mehr richtig zugewiesen werden.
Wir haben ein Ticket eröffnet und haben nur mal wieder eine unzufriedene Antwort erhalten "Ist bekannt, wir arbeiten dran" d.h. bei JTL ja inzwischen so viel wie "Wenn du Glück hast beheben wir das irgendwann einmal, bitte denk aber dran das du deine Rechnungen pünktlich bezahlst und leb mit dem Bug"

 

[HellwegDruckerei]

Ich habe mir im Monitoring jetzt folgende Queries eingerichtet, um zumindest eine Meldung zu erhalten, wenn die Queue wieder hängt:

Nur geeignet für JTL-WAWI Version 1.5.x

SELECT TOP 1
tWorkflowLog.dDatum,
tWorkflow.cName,
tWorkflowLog.cLog
FROM tWorkflowLog
JOIN tbenutzer ON tbenutzer.kBenutzer = tWorkflowLog.kBenutzer
JOIN tWorkflow ON tWorkflow.kWorkflow = tWorkflowLog.kWorkflow
WHERE tWorkflowLog.kWorkflowAktion != -1
AND tbenutzer.cLogin = :cLogin
AND (tWorkflow.nSchedulerHour + tWorkflow.nSchedulerMinute + tworkflow.nSchedulerDayValue + tWorkflow.nSchedulerMonthValue) > 0
ORDER BY tWorkflowLog.dDatum DESC

:cLogin muss durch den Benutzer, unter dem der Worker läuft ersetzt werden. Dieser Query gibt mir den Zeitpunkt der letzten erfolgreichen zeitversetzten Workflowausführung zurück.

Nur geeignet für JTL-WAWI Version 1.5.x

SELECT COUNT(tWorkflowQueue.kWorkflowQueue) AS [nQueue]
FROM tWorkflowQueue
WHERE tWorkflowQueue.dStartDate < GETDATE()
AND tWorkflowQueue.nStatus != 3

Dieser Query gibt dir die Anzahl der wartenden Workflows zurück.

Nun prüft das Monitoring ob es in der Queue Workflows zum ausführen gibt (Query 2), falls ja, prüft er, wann der letzte Workflow ausgeführt wurde. Ist dieser Zeitpunkt länger als X Minuten her > Alarm.

Nach ein wenig testen fahre ich nun folgendes Setup: die Queue muss mehr als 3500 Workflows enthalten und Query 1 muss mindestens einen Zeitpunkt zurück liefern, der nicht älter als 10 Minuten ist. Diese Zahlen sind natürlich von der Anzahl der Workflows und Aufträge abhängig.

Im nächsten Schritt werden ich mir die Tabellen WorkflowQueue und WorkflowLog im Fehlerfall dumpen, um eventuelle fehlerhafte Workflows aufzuspüren.

Wie immer in der Datenbank: ALLES AUF EIGENE GEFAHR! Datenbankbackup machen!

Wer Verbesserungen an den Queries findet, immer her damit.

wie müsste das ganze denn in der 1.7 aussehen? Dann könnten wir das auf unser Grafana legen und würden es zumindest direkt mitbekommen wenn es wieder hängt

 

[elevennerds.de]

Sollte auch mit der 1.7 laufen, zumindest gibt es dort alle Tabellen und Spalten. Einfach mal ausführen, sind nur SELECTs ...

 

[HellwegDruckerei]

Sollte auch mit der 1.7 laufen, zumindest gibt es dort alle Tabellen und Spalten. Einfach mal ausführen, sind nur SELECTs ...

Dankeschön! Hilft auf jeden Fall ein bisschen!
Schöner wäre natürlich JTL bekommt sowas einfach auch mal kurzfristig behoben

 

[Nocoma]

Wir müssen inzwischen 2-3 täglich den Worker neustarten weil sich die "Workflows" aufhängen. Merken es zwischendurch dann wenn Versandarten nicht mehr richtig zugewiesen werden.
Wir haben ein Ticket eröffnet und haben nur mal wieder eine unzufriedene Antwort erhalten "Ist bekannt, wir arbeiten dran" d.h. bei JTL ja inzwischen so viel wie "Wenn du Glück hast beheben wir das irgendwann einmal, bitte denk aber dran das du deine Rechnungen pünktlich bezahlst und leb mit dem Bug"

Moin, wir sind ebenfalls betroffen. Dienstleister und JTL sind da gerade dran. Hoffe, das wird schnell behoben. Version: 1.7.11.1.

Grüße Dolli