emeadaxsupport: How batch processing works under the hood AX2009

[Blog bot]

Источник: http://blogs.msdn.com/b/emeadaxsuppo...od-ax2009.aspx
==============

In this article I am going to explain how batch processing in AX2009 works, I don't mean how to set up a batch group or any of that kind of thing that you find in the manual, what I mean is what each AOS is doing in the background to decide how and when to pick up batches and process and complete them. Understanding this background can help in advanced batch troubleshooting or development scenarios.

In AX2009 batch processing changed. Now we have AOSes which can run batch processes directly, if you want to see what's happening with a batch process, it can be more difficult than in AX3 or AX4 as there is no client sitting there running to look at.

What happens now is that each AOS has a dedicated thread which checks for batches, basically all this does is calls Classes\BatchRun.ServerGetTask() once every 60 seconds (timing is not configurable) and if there is any work for that AOS to do then the AOS will pick up a task from here.

I'll give an example of an end-to-end batch process to show what happens where and when:

- A report is sent to batch by a user, it goes into the batch queue in BATCHJOB (header) and BATCH (the batch tasks).

- Once every 60 seconds each AOS that has been configured for batch processing (in administration->setup->server configuration) will call the X++ method - Classes\BatchRun.serverGetTask()

- In serverGetTask() the logic is exposed in X++ so we can all see what happens, this is the main place that we decide what to pick up for batch processing. Basically it checks if there is any tasks in the BATCH table waiting for this AOS - based on the batch groups that this AOS is configured to process, and based on the time that the records in BATCH are due to be processed (i.e. something processes at 21:00 each day then it won't get picked up until 21:00 despite the fact that the AOS polls every 60 seconds). There are a few stages to this method:

1. First we check if there is a task (a task is a record in BATCH table) ready for us, the query for this is like this:

select firstonly pessimisticlock RecId, CreatedBy, ExecutedBy, StartDateTime, Status,
SessionIdx,SessionLoginDateTime, Company, ServerId, Info
from batch
where batch.Status == BatchStatus::Ready
&& batch.RunType == BatchRunType::Server
&& (Session::isServer() || batch.CreatedBy == user)
join Language from userInfo
where userInfo.Id == batch.CreatedBy
&& userInfo.Enable == true
exists join batchServerGroup
where batchServerGroup.ServerId == serverId
&& batch.GroupId == batchServerGroup.GroupId;


2. If a task is returned in step 1 then there's nothing more to do and we start processing that task. If no task is returned then we look to see if any batch jobs need to be started, the query for this is like this:

<div style="padding-bottom: 5px; background-color: lightgray; padding-left: 5px; padding-right: 5px; font-family: courier new; font-size: 8pt; padding-top: 5px">
update_recordset batchJob setting
Status = BatchStatus::Executing,
StartDateTime = thisDate
where batchJob.Status == BatchStatus::Waiting
&& batchJob.OrigStartDateTime