As more of our clients are going live with NAV2017, we’re finding some inconsistencies on the features that were working as we thought it should, verses the way it’s working now.
One of such feature is the Job Queue function. Note that this only applies to NAV 2017, they’ve since rewrote how this process works in NAV 2018.
The purpose of a job queue is to run processes automatically at a preset time. For the process to run continuously, you would need to set the job to run as Recurring.
If you do not set the job queue entry as recurring, it would delete the Job Queue Entry because the process is only a one time deal. This feature was added because the users are now allowed to schedule their reports using job queue. Some reports/processes only needed to be ran once for the user.
After the clients went live, we started noticing the jobs that were set to recurring was being deleted as well. This confused the hell out of us because there were nothing on MSDN that talks about Job Queue Entries that are deleted when it’s set to Recurring.
Digging into this, the problem is on Codeunit 453 – Job Queue – Enqueue. More specifically, a function called RemoveFailedJobs.
Looking at this, the system will remove any Job Queue Entry records that it runs into an error. So this means that at any given point if your mission critical job fails, it’ll simply remove it from running ever again…
Yes, I could’ve setup notifications to warn you if something failed… I didn’t need to do this extra step before..
This is a steep contrast to how Dynamics NAV Job Queue ran before. In addition, this is not how NAV 2018 behaves now.
You can comment out the code completely or just add the following code:
Doing this, the process will leave the jobs that are set to Recurring alone.
I’m not sure if Microsoft has address this in the later CU releases for Dynamics NAV 2017, but if not, I would highly recommend you modify the code so your mission critical processes does not simply disappear!
10 thoughts on “Job Queue Being Deleted in Dynamics NAV 2017”
Which CU did you find this in?
In CU05 we noticed that recurring jobs were scheduled every second week.
It’s in Codeunit 453 – Job Queue – Enqueue.
As long as “Record ID to Process” is set, I think this can work. If I let the system call a certain codeunit to run on a record, I’d want it to remove earlier entries because then it’s a “retry”.
However, I don’t think that what happens when this field is not populated, was by design 🙂
I cannot test this now, but wouldn’t lines like the following in the top of the function solve the problem too?
RecordID := JobQueueEntry."Record ID To Process";
IF RecID.TABLENO = 0 THEN EXIT;
Not COD, CU (Cumalutive update) 😎
This issue has been fixed by one of the CU in NAV2017.
It seems to be fixed with NAV 2017 CU10 (build 18197) https://mbs.microsoft.com/partnersource/germany/deployment/downloads/hot-fixes/NAV2017AppHotfixOverview
This is good to know. Lord knows it’s still not easy to stay current with the CUs that are released… Still hopeful that it’ll get easier in the future with powershell and events.
😆 I ran into this same issue and it’s such a trivial fix once you find the cause. This is the most asinine decision I’ve ever seen in a ERP suite. Can you even imagine the problems this can cause?
I can’t imagine what kind of policy or pattern they were using as inspiration when they decided to delete jobs. Maybe because NAV deletes old sales order documents and so on? But a job is not a document…
I gave it a little extra retry logic instead, which helped a lot for our client who didn’t have the resources for new hardware and was having job fails due to that. If it fails 2 times it will stop the retry and flag/bold it in the que page.
Another bug somewhat related to job queues is codeunit 881, OCR – Receive From Service. After OCR data is received, the job goes on hold. The code checks IF IncomingDocument.ISEMPTY and ends up with setting the job queue entry “On Hold.” Removing this on hold bit fixes the issue, but it doesn’t make any sense in the first place.