Aufgabenwarteschlangenposten automatisch auf Bereit setzen

Heyho,

ich habe über eine Codeunit vom Subtype Upgrade einen Aufgabenwarteschlangenposten erstellt. Ich schaffe es aber nicht, diesen Aufgabenwarteschlangenposten per Code auf "Bereit" zu setzen. Der Status steht grundsätzlich auf "Wartend" (ja, "Wartend" anstatt "Abwarten"). Ich habe bisher versucht, nah am Standard zu bleiben und einfach den Code hinter der Action "Status auf Bereit setzen" auszuführen (dort wird nur "Rec.SetStatus(Rec.Status::Ready);" aufgerufen).

Was mache ich verkehrt? Gibt es einen Trick, wie ich einen Aufgabenwarteschlangenposten per Upgrade-Code auf Bereit setzen kann?

FG
Thomas

Ohnen deinen Code gesehen zu haben glaube ich eher, dass ein Subscriber o.ä. deinen "bereiten" Posten wieder zurücksetzt.
Das liegt dann weniger daran, dass der Code in einer Upgrade-Codeunit ausgeführt wird. Lagere doch mal den Upgrade-Code in eine normale Codeunit aus und debugge mal den Prozess.
Alternativ kannst du den Upgrade-Code auch direkt debuggen: https://learn.microsoft.com/en-us/dynam ... stall-code

Hallo Natalie,

ich habe den Code in eine Page-Action ausgelagert und diese aus der Anwendung aufgerufen. Der Aufgabenwarteschlangenposten wird problemlos erstellt und auf "Bereit" gesetzt. Anbei einmal der relevante Code, der den Aufgabenwarteschlangenposten erzeugt und über die Upgrade-CU auch funktioniert. Nach dem INSERT soll der Status auf "Bereit" gesetzt werden, was über die Page-Action klaglos klappt, über die Upgrade-CU allerdings nicht. Evtl. ist es auch ein Problem mit dem User, da über die Upgrade-CU als User "SYSTEM" eingetragen ist.

Code:

JobQueueEntry.Init();
JobQueueEntry."Object Type to Run" := JobQueueEntry."Object Type to Run"::Report;
JobQueueEntry."Object ID to Run" := Report::"My Report";
JobQueueEntry."Report Output Type" := JobQueueEntry."Report Output Type"::"None (Processing only)";
JobQueueEntry."Recurring Job" := true;
JobQueueEntry."No. of Minutes between Runs" := 1440;
JobQueueEntry."Run on Mondays" := true;
JobQueueEntry."Run on Tuesdays" := true;
JobQueueEntry."Run on Wednesdays" := true;
JobQueueEntry."Run on Thursdays" := true;
JobQueueEntry."Run on Fridays" := true;
JobQueueEntry."Starting Time" := 170000T;
JobQueueEntry."Ending Time" := 190000T;
JobQueueEntry.Description := 'My Description';
JobQueueEntry.Status := JobQueueEntry.Status::Waiting;
JobQueueEntry."Earliest Start Date/Time" := CurrentDateTime;
JobQueueEntry.ID := CreateGuid();
JobQueueEntry.Insert(true);

JobQueueEntry.SetStatus(JobQueueEntry.Status::Ready);


FG
Thomas

Der Aufgabenwarteschlangenposten braucht einen gültigen Benutzer weil mit dem ja auch z. B. Buchungsvorgänge gemacht werden (oder was auch immer sonst der Job macht, aber man denke mal an die Lagerregulierung die gern über die Aufgabenwarteschlange läuft). Daran wird es vermutlich im Rahmen der Upgradecodeunit scheitern. Wenn du das als Page Action machst dann mit deinem aktuellen Benutzer. Bei der Upgradecodeunit müsstest du den Benutzer vermutlich explizit zuweisen. Ich bin mir nicht sicher ob es genügt einfach eine gültige User-ID zuzuweisen, aber das könntest du mal versuchen. Das müsste wohl nach dem Insert(True) passieren.

Nachtrag: Hast du nach dem SetStatus ein Modify? Oder erfolgt Modify in der SetStatus Funktion?

Hallo enh,

ich habe an dieser Stelle kein eigenes MODIFY mehr im Code, da ich davon ausgegangen bin, dass dieses in der SetStatus-Funktion enthalten ist (es ist der gleiche Code, der in der Übersicht der Aufgabenwarteschlangenposten an der Action "Status auf Bereit festlegen" ausgeführt wird - ich habe mir an dieser Stelle einfach abgeguckt, wie der Standard das denn mit der Statusänderung macht).

Was den anderen Punkt betrifft hast du ziemlich sicher recht, dass es am Benutzer liegt. Ich muss mal schauen, ob ich mir an dieser Stelle was Schlaues überlege, wie ich hier einen Benutzer mit ausreichenden Berechtigungen finde und den Posten mit dessen Kennung anlege.

FG
Thomas

also wenn wir solche Aufgabenwarteschlangen via Code ausliefern, dann muss eigentlich immer ein User die Warteschlangen auf bereit festlegen.
Einfach nur, damit die korrekten Berechtigungen auch gegeben sind.
Ich wäre kein Freund davon, wenn eine App mir Aufgabenwarteschlangenposten anlegt und rennen lässt, obwohl ich das gar nicht will - daher ist der manuelle User-Eingriff m.E. sinnvoll

Also ich sehe das genau andersherum. Aus meiner Sicht möchte man, z.B. wenn es sich um bestimmte wiederkehrende Jobs handelt, dass das von einem Systembenutzer ausgeführt wird.

Jetzt ist aber die Krux an der Sache, dass mehr oder weniger jeder Benutzer Jobs einstellen kann. Dadurch, dass man Reports "planen" kann oder auch Hintergrundbuchungen erlauben kann, werden ja einmalige Jobs erstellt, die dann auch im Kontext des Benutzer ausgeführt werden müssen, damit ein Benutzer nicht auf einmal Dinge über die Hintergrundfunktion ausführt, zu denen er eigentlich gar nicht berechtigt ist. Und damit kann natürlich auch jeder Benutzer irgendeinen Job anpassen, z.B. auch wiederkehrende Jobs, die mit seinen eigenen Jobs gar nichts zu tun haben.

Deswegen wird beim auf "Bereit" Stellen nicht nur der Status des Jobs verändert, sondern auch eine Session in die Geplanten Aufgaben eingestellt, die dem ausführenden (sprich auf Bereit stellenden) Benutzer gehört. Man kann also nicht mehr einfach so wie früher, den Benutzer im Job auf den gewünschten Wert stellen, um sicherzustellen, dass man auch die Kontrolle darüber hat, wer den Job ausführt. Und eine "Session" für einen anderen Benutzer erstellen, kann man meines Wissens nach auch nicht einfach so.

Anke hat hier mal berichtet, dass sie es geschafft haben, aber die genauen Details stehen dort leider nicht.

Anke hat hier mal berichtet, dass sie es geschafft haben, aber die genauen Details stehen dort leider nicht.

Den Code kann ich leider nicht lieferen, da ich keine Entwicklerin bin und inzwischen auch woanders beschäftigt bin

Aber hier der Weg, den wir dort prgrammiert hatten - unter NAV 2018 :

---
In einem Feld in einer Einrichtungstabelle wird die User-ID hinterlegt, die final in den Aufgabenwartschlangeposten stehen soll wenn Status = BEREIT.
Bei uns hieß der User damals NAV-JOBUSER oder so ähnlich.

Wenn ein Job dann Neu gestartet etc. wurde, durchlief das System erst einmal den Standard ( der User, der das macht steht im Job ) und "superkurz" danach wurde dann der NAV-JOBUSER aus der Einrichtung in den Job eingetargen. Das ging technisch so schnell, dass der Mensch vor dem Bildschirm nur das Endergebnis sah.

Der User NAV-JOBUSER musste dort auch buchen dürfen, daher hat die Leitung Buchhaltung diesen USer auch immer in der Benutzer Einrichtung mit gepflegt. Das diser USer buchen musste lag aber daran, dass Buchungsdaten aus einer anderen Applikation über Nacht importiert und auch automatisiert gebucht wurden. Über den NAV-JOBUSER konnte man an den Posten erkennen, dass der Ursprung in einer anderen Applikation ist - und Korrekturbuchungen dann auch dort erledigt werden mussten (die dann über den Import in NAV ankamen)

Zusätzich hatte wir auch Jobs für Stammdaten Importe aus anderen Applikationen (Debitoren/Kreditoren) und so konnte man dann im Änderungsprotokollposten geanu erkennen, dass diese über den Job kamen und nicht oiriginär in NAV von einem Menschen durchgeführt waren. Ziemlich wichtig bei Neuanlge oder Änderungen von Bankverbindungen / Mandatsdaten zum Beispiel

Und das war echt klasse, denn so ich konnte jederzeit nachweisen, dass die Daten in den anderen Applikationen einem Audit Trail zu unterwerfen sind - und nicht in NAV.
Die interne Revision und auch die Wirtschaftsprüfer waren davon schwer beeindruckt damals.
---

HEUTE unter BC könnte man das eventeuell aber nicht mehr ganz so "einfach" programmieren,
da ja wie schon erwähnt, vieles nun im Hintergrund über Job Ques gesteuert wird.
Mir fallen da spontan z.B. die Dimensionskorrekturen ein, da muss natrülcih immer der korrekte echte Benutzer drin stehen (wer war's?).
Das ginge dann mit dem NAV-JOBUSER nicht.

VG Anke

In einem Feld in einer Einrichtungstabelle wird die User-ID hinterlegt, die final in den Aufgabenwartschlangeposten stehen soll wenn Status = BEREIT.

Ja, das ging früher noch, wie gesagt. Aber nach NAV2018 hat sich da die Logik geändert. Das geht jetzt leider nicht mehr so einfach.

Man kann also nicht mehr einfach so wie früher, den Benutzer im Job auf den gewünschten Wert stellen, um sicherzustellen, dass man auch die Kontrolle darüber hat, wer den Job ausführt.

Und das war echt klasse, denn so ich konnte jederzeit nachweisen, dass die Daten in den anderen Applikationen einem Audit Trail zu unterwerfen sind - und nicht in NAV.
Die interne Revision und auch die Wirtschaftsprüfer waren davon schwer beeindruckt damals.

Allerdings, ein nicht zu vernachlässigender Vorteil, wenn man die Kontrolle über die Ausführung behalten kann.