Axaptapedia is now maintained by AgileCadence For more information please click here.

Batch processing

From Axaptapedia
Revision as of 08:02, 8 June 2012 by Aj (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


When a program (job) is used interactively, it performs the requested commands immediately without any noticeable delay. For example, if the post button is clicked in a journal, the posting process immediately starts to post the lines in the journal. If a job has to process large amounts of data, the time consumed for the operation to complete becomes unacceptable for the user to wait. The solution is to delegate the process to another computer, this allows the user to continue working while the process is being executed on another computer.

Batch processing[edit]

Batch processing is when jobs are executed in sequence without any user interaction. The jobs are submitted to a central batch list by users where they are queued and processed in chronological order. The "batch server" is actually a Dynamics AX client performing the task of processing the jobs in the batch queue. This process can run on any computer with a client installed on it, but it is common practice to have a dedicated server with a client on it permanently processing the jobs in the queue. It is possible to have multiple clients or "batch servers" performing simultaneous batch processing. This allows jobs to be processed simultaneously, reducing the overall time it would take to complete.

Batch jobs can be scheduled to run on a specific date and at a specific time, or they can simply be added to the batch list where they will be queued to be processed as soon as the batch server is able to. Periodic processing is when a job is scheduled to run on a regular interval, e.g. once a day or once a week. An example of a periodic batch job is to e-mail a sales performance report to users on a weekly basis. Another example is to have the master schedule job run daily to determine how much inventory is needed to maintain sufficient inventory levels for production and sales.

Input data[edit]

The RunBaseBatch framework extends the RunBase framework. When a job is run interactively ("online"), the RunBase framework prompts the user for input data. This enables the user to modify the query, if present, and to make final adjustments to any options that are presented by the dialog. When the job is submitted to batch queue, the input data is stored by the SysLastValue framework. Before the job is executed by the batch server, the input is retrieved by the SysLastValue framework.

Batch options[edit]

On the "Batch" tab page the following options can be set: Batch processing, Batch group, Recurrence and Notification[1]. If the Batch processing option is selected, the job will be submitted to the batch queue. If the option is not set, it will run immediately when the "OK" button is clicked.

Batch groups[edit]

If there are multiple batch servers, it is possible to setup multiple batch groups and to dedicate a batch server to each batch group. When a batch job is submitted to the batch list, a batch group can be specified. The batch server assigned to the specified batch group will process the job. By separating batch jobs in different groups e.g. by department or another attribute, improves the overall performance and availability of the batch processing "service".


Recurrence determines the recurring pattern of the job, i.e. when the job will be executed for the first time, how many times it will be executed and when it should stop. There are three options to specify how the job should end: "No end date", "End after count" and "End by". These options allow the job the run without a end date, to execute a fixed number of times or the end by a certain date. The default is "End after count" and is set to run the job once only. If the current time and date is entered, which is the default, the job will be executed as soon as the batch server is able to.

Batch journals[edit]

A batch journal makes it possible to group individual batch jobs together as a single unit allowing it to be executed as a single batch job. By default, classes that extend from RunbaseBatch cannot run in a batch journal. To enable a class to run in a batch journal, the canGoBatchJournal method must be overridden.


When a job has been processed by the batch server, the user who added the job to the batch queue can be notified about the status of the job.


  • The user can continue his work while the processing of the job occurs on the batch server.
  • Jobs can be scheduled to run periodically e.g. once a day or once a week.
  • To distribute the load on the entire system, jobs can be scheduled to run when there are few or no users using the system.
  • Administrators can manage the batch queue e.g. by allowing more "important" jobs to run first.
  • Statistics can be generated by analysing the data of the completed batch jobs.


  • The status and progress of a job cannot be monitored from a client as closely as when not running in batch.


[1]The term "Notification" is used generically because of the differences in terminology and implementation between the current version and previous versions of the client.