Restarting Job Queue when it Hits an Error on Dynamics NAV 2013

Job Queue
In Dynamics NAV 2013, you can setup job queue to automate processing of tasks. Popular tasks that are automated are things such as Adjust Cost – Item Entries, EDI processing, Reporting, etc.

Setting up job queue in NAV2013 couldn’t be much easier can a step by step instruction can be found here.

The Problem
When the job queue runs into an error, it will never get picked up again. This means that while the Job Queue is an automated process, the IT manager will need to monitor this every day to make sure every process is running.

I know what you’re thinking, “This does not make sense!”. I fully agree.

There are some processes where the error is fatal. This is the reason why you would not want to have it run again. However, there are some situations where the error occurs when the table is locked by another process, in this case, you absolutely need to have it restart again.

This is especially true when you process EDI orders. You have to send back acknowledgment and/or confirmation within a certain timeframe or else you’ll get charge backs. Having the job queue error out because of table locks does not make too much sense.

The Solution
The problem lies in the Job Queue Dispatcher codeunit (448). If you go down and find the local function GetNextRequest, you’ll see that for some odd reason, the process is only looking at any statuses that are Ready.JobQueueReadySo we will need to modify the code to scan for the error entries as well.

JobQueueReady2

Depending on what you use the Job Queue for, I would include job queues that are In Process. The reason is if it’s running and someone stops the job queue, it’ll stay stuck in the In Process status.

By setting this, it’s important that you set the Max No. of Attempts. You don’t want the job queue to keep running if there really is a critical error.

A special thanks to Rafael Rezende for helping me with this!

  1. Hi Alex, hi Rafael,

    tanks for sharing this. The interesting part of this behaviour change is that GetNextRequest has always only looked at ready queue entries (just checked in mercurial). I concur that also filtering on “error” would be sensible. The HandleRequest() function of old has reset the status to ready after an unsuccesful attempt (and sufficient retries remaining). As HandleRequest() was timer-based, there was a delay of at least 2 seconds before the next retry. This is effectively the same checking for the error state, without allowing the “unwanted” errors to reoccur.
    The heart of the change appears to be in the completely changed handling of the jobs to run. They run in a concurrent session, and the retries run in the same session consecutively, without much delay, as it seems. And (worse) without logging the errors of the unsuccessful attempts – only the last unsuccessful attempt appears to be logged. Go figure.

    with best regards

    Jens

  2. I would say another approach is run schedule a separate job that checks the jobs and changes the status. This way you can control how ofter it runs and when to run and also not to reset the status if it’s the same error more than once or twice etc.

  3. Fantastic, thanks for sharing. Shows again how one line of code can make a big difference. I had modified the Job Queue Entry table so that it sends me a mail every time a queue status changes to error. Now with this change I don’t need to freak out every time I receive the email when on holiday!

  4. Hello Bruce
    Could you please share your code that mails upon error on the job queue. Many thanks!

Leave a Comment


NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>