It is important to understand the Microsoft Dynamics AX 4.0 batch framework to fully understand the Microsoft Dynamics AX 2009 batch framework enhancements.

The Microsoft Dynamics AX 4.0 batch framework functionality is as follows:

1. The batch framework requires an active Microsoft Dynamics AX Windows client for processing batch jobs. You cannot simply submit a batch job with the assumption it will be executed, as the job will not run if a client is not open.

2. The batch framework does not support parallelism. As a result, the batch framework runs batch jobs only in a single thread, regardless of the number of Application Object Servers (AOS) available in the cluster.

3. The batch framework does not allow you to create a dependency tree for the different tasks that comprise the batch job.

4. The batch framework does not allow outputs to be generated on the server. This means that reports need to run in an interactive client mode since the output of the report cannot be stored or printed on the server.

5. There is no administrative console to view or manage all the batch jobs that are executing in an environment.

The batch framework in Microsoft Dynamics AX 2009 has been significantly enhanced to provide a truly asynchronous (non-interactive) server-based batch processing environment that is also capable of processing multiple tasks within a job across multiple Application Object Servers (AOS) instances. The Microsoft Dynamics AX 2009 batch framework provides the capability of server-bound batches without the need for an interactive client. All new batch jobs in Microsoft Dynamics AX 2009 use the new batch framework. Most existing batch jobs from the previous releases are being automatically migrated to the new batch framework. Client side batches are supported in Microsoft Dynamics AX 2009 but are not recommended. A job can contain both client-side and server-side batch tasks. A job with client-side tasks requires a client to be open in order to process the client-side tasks.

The following section defines various terms used in the Microsoft Dynamics AX 4.0 and 2009 batch framework:

• Batch job: An entire process that is used to achieve a certain goal. A batch job is made up of one or more batch tasks. A batch job can be considered the equivalent of the Microsoft Dynamics AX 4.0 batch Journal.

• Batch journal: A set of processes that make up a batch job. Each task achieves a portion of a batch job. The tasks within a batch job may have complex dependencies among themselves. For example, a batch job to create invoices from sales orders might contain the following multiple tasks:

  • Update vendor data received from an external system.

  • Get updated sales data from an external system.

  • Create invoices.

Note
The concept of a batch journal is applicable only to Microsoft Dynamics AX 4.0. The Microsoft Dynamics AX 2009 application replaces the batch journal with the batch job.

• Batch tasks: A batch task in Microsoft Dynamics AX 2009 can be considered the equivalent of the batch jobs in Microsoft Dynamics AX 4.0. In Microsoft Dynamics AX 4.0, you add batch jobs sequentially to batch groups. In Microsoft Dynamics AX 2009, you can add batch tasks with multiple types of dependencies to a batch job. You also can configure AOS servers to run multiple threads, with each thread executing a task. All batch tasks that are waiting for execution can be executed by any available AOS server that is configured as a batch server. The ability to break down a batch job into many sub-jobs and executing these subtasks against all available AOS instances can improve throughput and reduce overall execution time.

• Batch group: An attribute of a batch job that allows the administrator to determine which AOS runs the job. When you create a new job, it is placed in the default batch group. All batch servers are configured to process the default batch group and to process waiting tasks from any job. You can create a named batch group and an affinity between the batch group and specific AOS servers. Once you create this affinity, only the configured AOS servers will only process tasks from the named batch group. You can also add the default batch group to the configured servers if required. The following examples provides a walkthrough with three AOS servers:

  1. You have configured three batch servers, AOS1, AOS2, and AOS3.

  2. By default, all of the batch servers configured in the above step will process tasks from all batch jobs depending upon the number of available threads.

  3. You now create a named batch group, BG1, and configure it to run on AOS2 and AOS3. Tasks from jobs in BG1 will run only on AOS2 and AOS3, depending upon available threads. AOS1 will not process tasks from jobs in BG1. Similarly, AOS2 and AOS3 will process tasks from only BG1.

  4. You can configure AOS2 and AOS3 to process tasks from other batch groups, including the default batch group.

Consider the following when planning a batch server in your environment:

• You can now manage all batch servers from a single location. For more information on server configuration, see the Server and Database Administration Guide.

• You can configure any active AOS server as a batch server. You cannot configure a dedicated load balancer as a batch server. You need to place the batch server in a separate cluster from the active AOS server if you require a dedicated batch server that does not act as an active AOS server. You also need to make sure that users are not connecting to this dedicated batch server.

• You can define the time period for the AOS to act as a batch server. You can also set the number of threads the batch server will process during the time period. For example, the batch server might process only two threads during one time period but can process twenty threads during another time period. The applicable time is based on the user's time zone and not based on the time zone of the location of the AOS server. The time period is configured based on a schedule of start time and end time. Note that the batch server is also an active AOS server servicing requests from Microsoft Dynamics AX clients and other Microsoft Dynamics AX components. Therefore, determining the time period for batch servers is very important.

• The capacity is configured based on maximum number of threads that can run on this AOS server concurrently. Each thread executes one batch task. You can add complex dependencies between or among tasks. You can run these tasks in a serial steps or parallel steps, depending upon the business logic and requirements. All tasks without any dependencies are considered parallel tasks. AOS servers configured as batch severs periodically check for tasks that are waiting for processing. The batch server assigns each parallel task to a thread and starts processing the thread. This is discussed in more detail in a walkthrough later in this section.

• You can create batch groups and determine which batch group runs on which AOS server.

• New batch administration forms provide an easy way to create or manage jobs and tasks. For more information on managing batch jobs, see the Server and Database Administration Guide.

• You can run multiple threads across multiple AOS servers. Each AOS automatically runs multiple threads depending upon capacity defined in the configuration settings. Therefore, it is possible for parallel tasks from a job to execute on multiple threads across multiple AOS servers.

Note
The batch server checks for available threads once a minute. You may therefore have to wait for a minute before you can see a waiting task being picked up for processing by an available thread.

Consider that you have created a job called JOB1 with seven tasks TASK1, TASK2, TASK3, TASK4, TASK5, TASK6 & TASK7 as shown in the following diagram.

The dependencies of your tasks are as follows:

• TASK1 is the first task

• TASK2 runs ON COMPLETION of TASK1 (regardless of success/failure of TASK1)

• TASK3 runs ON SUCCESS of TASK2

• TASK4 runs ON SUCCESS of TASK2

• TASK5 runs ON FAILURE of TASK2

• TASK6 runs ON FAILURE of TASK3

• TASK7 runs ON SUCCESS of both TASK3 AND TASK4

Let us assume that two batch servers, Batch1 and Batch2, are configured with a capacity of one thread each. Batch1 checks for waiting tasks, assigns Task1 to its thread and starts execution. Although Batch2 is also available with one thread, Task2 will keep waiting until Task1 is completed successfully.

As soon as Task1 is completed successfully, Task2 is ready for execution. Let us assume that this time Batch2 checks for waiting tasks, assigns Task2 to its thread and starts execution of Task2. If Task2 is successful, Task3 and Task4 are awaiting execution. Let us assume that Batch2 checks for waiting tasks, assigns Task3 to its thread and starts execution. Batch1 also checks for waiting tasks, assigns Task4 to its thread and starts execution. If Task3 and Task4 are completed successfully, one of the batch servers will execute Task7.

If Task2 fails, one of the batch servers will execute Task5. If Task3 fails, one of the available batch servers will execute Task6.

Note
Note that we are using Batch1 and Batch2 to explain the concept. Any batch server with available threads will start executing a waiting task. You must create a batch group to determine or specify which batch job runs on which server.