[gelöst] Job Queue - serielle statt parallele Abarbeitung

Hallo,

ich möchte gerne mehrere Codeunits in die Aufgabenwarteschlange einstellen, die jede Nacht nacheinander (seriell) abgearbeitet werden sollen.
Dazu habe ich bereits eine Aufgabenwarteschlange (Kategorie "NACHT") erstellt und die CU's als Aufgabenwarteschlangenposten (Kategorie "NACHT") eingestellt.

Folgende Voraussetzungen für die Ausführung der Jobs sollen gelten:
- Jobs sind in einer genau festgelegten Reihenfolge abzuarbeiten
- Nachfolge-Job darf nur ausgeführt werden, wenn der vorherige Job ohne Fehler durchgelaufen ist.

Mit der vorhandenen Möglichkeiten der Aufgabenwarteschlange bekomme ich das nicht hin.
Ich könnte zwar z.B. die Priorität nutzen, um die Ausführungsreihenfolge zu beeinflussen - wenn aber z.B. durch Änderung des Eintrag ein neue Startzeit generiert wird, geht diese vor und die Priorität greift nicht mehr (das ist mir zu unsicher). Ein Abbruch von Folge-Jobs bei Fehler im Vorgänger scheint auch nicht einstellbar zu sein. Man könnte die Jobs zwar theoretisch auch in einer CU zusammenfassen, aber das möchte ich auf Grund der Komplexität und einer evtl. späteren Fehlersuche vermeiden.

Ich hätte jetzt folgenden Lösungsansatz und würde gerne Eure Meinung dazu hören:
Die Jobs (Kategorie "NACHT") werden alle mit Status "Warten" eingestellt. Vorweg wird nur eine Art "Startjob" mit dem Status "Bereit" hinzugefügt.
Diese CU "Startjob" ändert den ersten auszuführenden Job von Status "Warten" auf Status "Bereit". Das selbe wird bei allen weiteren CU's am Ende für den Folgejob durchgeführt (hierzu würde es dann also nur kommen, wenn der Job fehlerfrei durchlaufen wurde) und gleichzeitig wird der durchgelaufene Job von "Bereit" wieder auf "Waren" gesetzt.

Was haltet Ihr davon - oder habe Ihr eine bessere Lösung?

Und noch eine Frage: Könnte ich Probleme bekommen, wenn ich die Status-Änderungen ohne Neustart der Posten oder der Warteschlange durchführe?

Vielen Dank für Eure Hilfe!

Gruß
Ralf

Zuletzt geändert von neckit am 8. Juli 2014 12:09, insgesamt 1-mal geändert.

Hallo Ralf,

ich stand selber mal vor einer solchen Kundenanforderung (allerdings unter 5.0 SP1) und habe es wie folgt gelöst:

In der Tabelle habe ich zwei neue Felder "Letzte erfolgreiche Ausführung" (DateTime) und "Vorgänger" (Integer) angelegt.
Das Feld "Vorgänger" darf logischerweise nicht auf sich selbst zeigen.
Wurde der Job erfolgreich durchgeführt, so wird die CURRENTDATETIME in das Feld "Letzte erfolgreiche Ausführung" geschrieben.
Wird ein Job mit einer Vorgängernummer gestartet, so muss die letzte erfolgreiche Ausführung des Vorgängers größer der eigenen letzten erfolgreichen Ausführung sein, ansonsten wird der Eintrag einfach ignoriert.

Hallo Timo,

Deine Lösung hört sich vielversprechend an! Ich werde das mal testen.
Kannst du mir evtl. noch kurz verraten, an welcher Stelle du die Prüfung eingebunden hast?
Den Code werde ich dann sicher schnell umgesetzt kriegen.

Vielen Dank für deinen Tipp!

Gruß
Ralf

Kannst du mir evtl. noch kurz verraten, an welcher Stelle du die Prüfung eingebunden hast?

Die Prüfung musst du in der CU 448 - Funktion "GetNextRequest" einbauen.
Sollte der Vorgänger nicht erfolgreich ausgeführt worden sein, so berechnest du einfach die nächste planmäßige Ausführungszeit und schiebst diesen Job somit weiter nach hinten.
Anschließend versuchst du erneut mit GetNextRequest den nächsten fälligen Job zu suchen.

Das Setzen der letzten erfolgreichen Ausführung gehört in die Funktion "HandleRequest" in den Teil nach IF WasSuccess.

P. S.: In meinem Fall habe ich es nicht wirklich in der Original JobQueue umgesetzt, sondern in einer Individual-Entwicklung, welche ungefähr das Gleiche macht, wie die JobQueue.
Aus dem Grund kann ich dir nicht versprechen, dass die o. g. Stellen korrekt sind.

Danke Dir!

Den Rest kriege ich schon hin.
Du hast mir damit einige Sucharbeit erspart

Gruß
Ralf