Gelöst Workflows unzuverlässiges Triggern und Reihenfolge bei gleichzeitigem Ausführungszeitpunkt

[G. Pilz]

Hallo zusammen,

je mehr ich einzelne Abläufe/ Prozesse bei uns automatisieren, bzw. sicherer machen möchte, umso mehr Probleme habe ich mit den Workflows.
Mich würde aktuell vor allem interessieren, ob ich etwas "falsch" mache, es andere (zuverlässigere) Ansätze gibt, oder ob es generelle Probleme seitens JTL sind?

Erstes allgemeines Problem: Workflows mit Ausführungszeitpunkt "Sofort" werden nicht zuverlässig getriggert (IMHO ein absolutes No-Go/ Unding!).
Wie u.a. auch hier im Forum nachlesbar wird einem allen Ernstes auch von JTL empfohlen, eine Zeitverzögerung einzustellen! Und wer im Worker für diverse Prozesse ein 60 Sekunden Intervall eingestellt hat, der muss/ sollte dann in seinen Workflows mind. 2 Minuten einstellen, da es ansonsten dennoch passieren kann, dass der Workflow nicht getriggert wird!

Die meisten Workflows verwende ich unter "Aufträge", etliche unter dem Ereignis "Erstellt". Da man innerhalb eines Workflows keine Einstellung bzgl. der Ausführungsreihenfolge eingeben kann, ist es ja interessant zu wissen, wie JTL das handhabt bei Workflows, die (theoretisch) gleichzeitig ausgeführt werden müssten?
Bei Google erscheint (bei Suchbegriff "jtl wawi workflows reihenfolge"): Workflows können alle auf "sofort" stehen. Die werden von oben nach unten abgearbeitet, sofern keine Verzögerung eingestellt ist. Die Reihenfolge der Workflows kannst du mit der Maus verschieben, falls bestimmte abhängig voneinander sind.

OK, gehen wir mal davon aus, dass das stimmt, dann stellt sich mir gleich die nächste Frage, nämlich die, wie es sich dann mit dem Ereignis "Geändert" verhält?
Also angenommen, ich habe unter "Aufträge" -> "Erstellt" 5 Workflows, die alle "zeitgleich", sprich von "oben nach unten" abgearbeitet werden und jeder von denen nimmt nun eine Änderung an dem Auftrag vor.
Wird dann nach jedem Workflow das Ereignis "Geändert" ausgelöst (und würden somit dann alle Workflows unter diesem Ereignis mit Ausführungszeitpunkt "Sofort" getriggert)?
Weil wenn dem so wäre, und diese Workflows u.U. auch wieder Änderungen an dem Auftrag vornehmen, auf welchen "Stand (des Auftrags)" beziehen sich dann die nachfolgenden Workflows unter "Aufträge" -> "Erstellt"?

Und dann würde mich auch noch interessieren, wie es sich mit der Reihenfolge bzgl. der Workflowgruppen verhält?
Also z.B. wenn jetzt über den (JTL) Shop eine neue Bestellung reinkommt, wird dann erst die Gruppe "Aufträge" (und darin dann das Ereignis "Erstellt") ausgelöst, und dann die Gruppe "Kunden" (und darin dann das Ereignis "Angelegt")?

Konkreter Hintergrund meiner Frage ist, dass ich ein Supportticket aufgemacht hatte, weil ich in der Tabelle unter "Verkauf" die Spalte "Debitorennummer" eingefügt hatte, mir aber bei etlichen Aufträgen keine Debitorennummer angezeigt wird, obwohl bei dem Kunden sehr wohl eine vorhanden ist (ungleich 0).
Hier ein Auszug aus der Antwort vom Support:
... wenn ich es richtig verstehe, wird die Debitorennummer dann erst im Kunden eingefügt. Ist der Auftrag bereits erstellt, wird diese nicht nachträglich in den Auftrag "geladen". Es sind immer nur die Daten vorhanden, die zum Zeitpunkt der Erstellung vorhanden waren (Adressänderungen im Kunden bewirken auch keine Änderung im Auftrag).
Bei bereits erstellten Aufträgen, müsste der Kunde erneut im Vorgang hinterlegt werden, damit die Debitorennummer mit übernommen wird.

Mal abgesehen davon, dass ich das nicht glaube, da ja bei einigen Aufträgen die Debitorennummer angezeigt wird (bei denen es sich auch jeweils um Neukunden handelt), wäre das ja totaler Quatsch/ Unsinn.
Hat jemand von euch ggf. dasselbe oder ein ähnliches Problem?

Der nächste Punkt, der mir lange Kopfzerbrechen und (unnötige) Arbeit verursacht hat ist, dass ich in einem Workflow eine (von mehreren) Bedingung habe, die da lautet: Zahlungen.Zahlungen.enthält.Zahlungsart.Name.beginnt nicht mit Otto
Dieser Workflow wurde anscheinend bei einigen Aufträgen nicht (korrekt) ausgeführt. Im Workflow Log (nachdem ich davon erfahren und es gefunden hatte) dann des Rätsels Lösung: Die Bedingung "Zahlungen.Zahlungen.enthält.Zahlungsart.Name" enthält keine Einträge.

Auch das ist IMHO eher ein "Fehler", denn wenn das Feld "leer" ist, dann sollte die Bedingung ja erfüllt sein (und nicht der Workflow wegen eines Fehlers abgebrochen werden)!
Zumal es ja in der Auswahlliste der Vergleichsoperatoren auch "Ist leer" und "Ist nicht leer" gibt.
An der Stelle die Frage: Muss ich jetzt den Workflow kopieren, um in der Kopie auch den Fall "Ist leer" abzufragen, oder kann ich (bspw. per RegEx) die beiden Dinge "beginnt nicht mit Otto)" und "Ist leer" kombinieren (einfach eine zusätzliche Bedingung in den Workflow einbauen scheidet aus, da er wie gesagt mehrere Bedingungen beinhaltet, die alle erfüllt sein müssen)?

Ich würde es auch sehr begrüßen, wenn sich mal jemand von JTL hier mit erhellenden Informationen melden würde. Denn die Workflows sind schon ein enorm wichtiger Bestandteil, nutzen nur nicht viel (oder eher im Gegenteil), wenn man nicht nachvollziehen kann, wie diese "intern arbeiten", bzw. welche "Fallstricke & Bugs" es zu beachten gilt!

Problem ist halt auch, dass sich viele dieser Sachen nicht wirklich "simuliert" testen lassen, sondern nur dann wirklich "getestet" werden können, wenn tatsächlich Aufträge ins System einlaufen (und davon haben wir derzeit noch nicht so viele).
Von daher hoffe ich auf eure freundliche Mithilfe/ Unterstützung.

PS: Was mir auch gerade noch eingefallen ist - In dem Windows Meldungsfenster, welches angezeigt wird, wäre es hilfreicher, wenn da nicht nur "Starte Workflow mit ..." stehen würde, sondern auch noch welchen Workflow!

VG
Gunther

 

[Björn Ponsen]

Ich möchte gerne auf deine Anliegen eingehen. Zuallererst möchte ich dir sagen das ein Beispiel, wo Sofortige Workflows nicht zuverlässig getriggert werden, sehr sehr hilfreich wäre, um die Situation genauer zu analysieren und einen evtl. Bug zu finden.

Zu der Thematik mit einem Zeitverzögerten Workflow: Es kann vorkommen das wir eine Empfehlung dahingehend geben, dass ein Sofortiger Workflow umgestellt werden sollte, und zwar auf einen zeitversetzten. Das betrifft in der Regel Shopabgleiche aber, je nach Situation auch Abgleiche von Plattformen oder Externen Importen. Der Hintergrund, nur nochmal zur Erläuterung, ist folgender.

Wird ein Auftrag über z.B. den Shopabgleich importiert und der Kunde zahlt, in diesem Beispiel, den Auftrag mit Kreditkarte oder PayPal. Dann kann es vorkommen das die Zahlung im ersten Abgleich nicht direkt mit Importiert wird, da die Freigabe über die Schnittstelle noch nicht erfolgt ist. Der Workflow, der aber jetzt sofort ausgeführt wird, prüft auf z.B. Ist bezahlt = true. Somit würde die Bedingung, in unserem Beispielszenario, versagen und der Workflow nicht mehr ausgeführt werden. Mit einem Zeitversatz würden wir das aber abdecken und der Workflow würde dennoch seine Aktionen ausüben, nur halt 1-2 Minuten später je nach Konfiguration.

Bei euch werden die meisten Workflow unter Aufträge erstellt ausgelöst. Das ist grundsätzlich schön zu sehen das hier im Erstellungsprozess vieles bei euch automatisiert ist. Und wie ihr bereits schreibt, die Workflows werden der Reihe nach abgearbeitet (so wie ihr diese per Drag & Drop oder Anlage sortiert habt), insofern kein Zeitversetzter Workflow dazwischen ist, dieser wird dann erst zum Startzeitpunkt, je nach Konfiguration, ausgeführt. Ein gleichzeitiges Ausführen von Workflows ist, wie ihr selbe festgestellt habt, nicht möglich.

Zu eurer Rückfrage bei dem Ereignis Workflow geändert. Wenn ihr einen Workflow unter Auftrag erstellt nutzt, dieser aber zeitversetzt ist, wird bei einer Änderung dieser Workflow eben diese Änderung mitbekommen. Das Liegt daran das der Zeitversetzte Workflow erst einmal in die Warteschlagen, die sogenannte Queue, eingetragen wird. Sobald jetzt das Startdatum eintritt, wird der Worker die Queue entsprechend dem Startdatum abarbeiten. Hier wird dann aber auch erst auf die Bedingungen geprüft, ob diese zum Ausführungszeitpunkt auch zutreffen.

Beispiel:
Ein Workflow unter Auftrag erstellt ist zeitversetzt um 5 Minuten.
Er Prüft auf die Anmerkung, ob diese etwas beinhaltet. z.B. „Kunde war nett“.
Ein Auftrag wird erstellt durch den Mitarbeiter und gespeichert. Somit wird Auftrag erstellt ausgelöst und der Workflow in die Queue geschrieben.
Jetzt fällt dem Mitarbeiter 3 Minuten später auf, misst ich habe keinen Kommentar in die Anmerkung geschrieben und trägt diesen in der Anmerkung mit “Kunde war nett“ nach.
Eine Minute später wird geprüft ob die Bedingungen zutreffen und das ist jetzt der Fall.
Workflow wird ausgeführt.

Bei Sofortigen Workflows würden Änderungen im Auftrag NICHT das Ereignis Auftrag geändert Auslösen.

An dieser Stelle, falls euch unser Guide noch nicht bekannt ist, würde ich euch gerne unseren Guide an die Hand geben.
Ich hoffe ich konnte euch in diesem Beispiel verdeutlichen, wie das Ereignis Geändert Einfluss auf Zeitversetzte Workflow hat.

Die Aussage aus dem Supportticket würde ich jetzt nicht als verkehrt einstufen.
Der Kollege ist hier lediglich darauf eingegangen, dass der Auftrag mit den Kundendaten erstellt wird, der Kunde angelegt wird und dann, so liest es sich, der Workflow für die Debitorennummer ausgeführt wurde eben durch die Anlage des Kunden.
In diesem Fall ist der Auftrag schon geschrieben gewesen und weitere Änderungen im Auftrag werden aktuell nicht beachtet. So würde ich es ebenfalls in diesem Fall beschreiben. Aber damit die die Daten im Auftrag aktualisiert werden, gibt es bereits diverse Tickets.
Hier mal zwei Beispiele die ich gefunden habe.
WAWI-63286
WAWI-67848

Noch eine Kleinigkeit zum vorherigen Thema. Wenn Ihr, wie beschrieben, es nachstellen könnt, dass hier bei Neukunden die Kundendaten im Auftrag aktualisiert werden, würde ich mir das gerne anschauen, um genauer beurteilen zu können, ob es sich hier sich nicht um ein einfacheres Problem handelt. Allerdings habe ich auch die Befürchtung, dass es nur sporadisch und nicht nachstellbar ist und wir in dem Termin evtl. nicht auf eine gemeinsame Lösung kommen.

Zu euren Kopfschmerzen mit Otto Aufträgen der Bedingung Zahlungen.Zahlungen.enthält.Zahlungsart.Name.beginnt nicht mit Otto.
Hier habt Ihr im Workflowlog die korrekte Fehlerbeschreibung. „Die Bedingung "Zahlungen.Zahlungen.enthält.Zahlungsart.Name" enthält keine Einträge.“

In diesem Fall gibt es für die Bedingungsprüfung keine Abrufbaren Daten. Die Zahlungsart hat also noch keinen Namen. So würde ich es erstmal beurteilen OHNE es gesehen zu haben. Für weitere Klärungen dazu, muss man sich den Fall genauer anschauen. Einen Workaround hierzu können wir dann in einem gemeinsamen Termin erarbeiten. Ich vermute aber, es liegt an der Zahlung. Die Bedingung schaut hier auf Zahlungen, die evtl. noch nicht da sind. Versucht bitte auch einmal die Bedingung auf Auftrag\Zahlungen\Zahlungsart\Name zu ändern und probiert dann mal die Simulation durchzuführen.

 

[G. Pilz]

Hallo Björn und alle anderen!

Generell besteht bei (Automatisierungs)Prozessen, die nur nacheinander ausgeführt werden können immer das "Henne-Ei-Problem".
Diese Problematik "bestmöglich", also logisch zu lösen, ist eure Sache/ Aufgabe!

In der vorangegangenen beschriebenen Situation mit neuen Aufträgen, müsst ihr (intern) dafür sorgen, dass bevor der Auftrag als "erstellt" eingestuft wird, die Workflows unter "Kunden" -> "Angelegt" ausgeführt werden und die Kundendaten dann entsprechend auch Eingang in den neu erstellten Auftrag finden!

Von der Logik her sehe ich das so: Kein Auftrag ohne Kunde. Also ist der erste Schritt, dass der Kunde angelegt wird (wenn Neukunde). Daraus folgt wiederum, dass die entsprechenden Workflows getriggert werden. Und erst dann mit dem Auftrag fortgefahren wird (und dessen Workflows).

Interessanterweise kriegt ihr es ja bei Amazon Bestellungen scheinbar hin - keine Ahnung, was ihr bei Otto anders macht?

Aber Aussagen wie: "... steht bei Anlage des Auftrags noch nicht zur Verfügung" sind für mich als Anwender nicht hilfreich/ zielführend. Dann müsst ihr eben genau sicherstellen, dass bestimmte Aktionen/ Ereignisse erst dann ausgeführt werden, wenn alle benötigten/ relevanten Daten/ Informationen auch tatsächlich vorhanden sind!

Noch ein Beispiel aus dem WMS:
Es ist "toll", dass ich in der WMS-Ausgabe u.a. den Lieferschein drucken lassen kann. Es ist aber leider völlig unbrauchbar, weil ihr es versäumt habt, die Ausgabe erst dann zu starten, wenn auch die Paketnummer (die auf den Lieferschein gedruckt werden soll) "verfügbar" ist.
Das sind lauter so "Kleinigkeiten", die dazu führen, dass an sich sehr nützliche Optionen/ Möglichkeiten absolut nicht zu gebrauchen sind. Und das nervt ...!

Und last but not least lässt eure Dokumentation seit der 1.6 schwer zu wünschen übrig!
Vieles im Guide (und den YT Videos sowieso) ist inzwischen dermaßen veraltet/ überholt, dass es keinerlei Hilfe mehr bietet. Auch hier wäre es wünschenswert, wenn ihr auch eure Dokumentation deutlich mehr up-to-date halten würdet!

VG
Gunther

 

[Björn Ponsen]

Für alle im Forum hier nochmal das Ticket bzgl. des nicht Triggerns bei Kundenanlage bei z.B. Otto Kunden.
WAWI-72236
Zu den anderen Themen, wie z.B. die WMS Ausgabe, haben wir bereits telefonisch besprochen, dass Ihr hier ein Ticket für die Kollegen aufmacht, damit die Thematik durch das entsprechende Team gelöst werden kann.
Wenn Ihr hier eine Lösung durch die Teams habt, postet diese bitte ebenfalls hier mit, damit auch andere User davon profitieren.

 

[G. Pilz]

Zu den anderen Themen, wie z.B. die WMS Ausgabe, haben wir bereits telefonisch besprochen, dass Ihr hier ein Ticket für die Kollegen aufmacht, damit die Thematik durch das entsprechende Team gelöst werden kann.

[ Ticket#2023091110002079] Packtisch+/ WMS-Ausgabe

Wenn Ihr hier eine Lösung durch die Teams habt, postet diese bitte ebenfalls hier mit, damit auch andere User davon profitieren.

Aber natürlich - mache ich immer, da ich persönlich nichts mehr hasse, als wenn jemand eine Lösung gefunden hat, und diese dann für sich behält.

VG
Gunther