Since AX 2009, batch jobs have been processed by the AOS. You’ll know the batch jobs sit in a queue at Systems administration > Inquires > Batch job > Batch job:
Within a batch job you have one or more batch tasks. Many batch jobs only have one task, but if you have more than one task you can set dependencies so that the tasks are executed in sequence:
The batch job also has a recurrence – and we sometimes come across batch jobs that have been setup with a recurrence of 1 minute:
System administrators sometimes set a 1 minute recurrence on interface (AIF) or workflow batch jobs to minimise the delay experienced by users.
I’m hoping that by the end of this post I can persuade you that this is not a good idea.
We occasionally see batch jobs getting ‘stuck’ – their status is ‘Executing’ but they run for much longer than normal – in fact they just never end. The last time we had this issue reported we could see database deadlocks, and the deadlocks were processes trying to set the status on the Batch job table and on the individual tasks. There’s also an LSC issue 3272330 referring to users receiving a deadlock issue on project timesheets which happens when the workflow batch job has a recurrence of 1 minute. But even without these odd issues cropping up a look at the underlying architecture of the batch job processing system shows that a 1 minute recurrence isn’t a good idea. There’s a nice detailed blog post on this in the Microsoft Dynamics AX Technical Support Blog it was written on AX 2009 but as far as I know the description is still valid.
The highlights for me are: firstly there’s an AOS class running once every 60 seconds checking to see if there are batch jobs ready to start. That 60 seconds time interval is fixed and can’t be changed. Then the batch task is run and [eventually] updates its status to Ended. Then there is another AOS class, also running every 60 seconds that updates the batch job status – you may have noticed this yourself if you’re closely monitoring a batch job – the tasks show ‘Ended’ before the batch job itself is reset ready for the next recurrence. Finally there is a clean-up task running every 5 minutes – and also every 5 minutes the system checks the batch groups and server setup to see which batch groups (if any) should be being processed.
Don’t use a recurrence of 1 minute – it’s technically impossible inside of Dynamics AX anyway and to me it’s a gaffe like using the wrong fork at a dinner party.
So as a rule of thumb – do not use a batch job recurrence of less than 10 minutes. Give Dynamics AX a chance to reset the batch jobs and queues ready for the next recurrence.