(For more resources related to this topic, see here.)

Setting Up and Managing E-mails and Batch Processing

The batch framework processes more than the recurring system tasks; users can submit jobs from many places within AX. This allows them to continue with their primary tasks without having to wait for the operation to finish. An alert can be set up to alert them about the success or failure of the task.

Using e-mails correctly makes the system look more professional and user friendly; instead of the basic text details in system-generated e-mails, they can be branded with your corporate identity and laid out in a more appealing manner.

There are two methods by which e-mails are sent in AX: SMTP and MAPI.

MAPI (Messaging Application Programming Interface) is a client-side method that opens a new message in your e-mail client (Microsoft Outlook, for example), potentially setting the recipients and subject from the data in AX. Attachments can also be added via MAPI (for example, while sending a report via an e-mail from AX). SMTP (Simple Mail Transfer Protocol) is a server-side method and is used for server-generated e-mails such as alerts and workflow notifications.

MAPI is not always desirable due to its client-side dependence on an e-mail client, which causes problems when running the client as a remote app. A common modification is to replace it with SMTP as the e-mail is then sent by the server without requiring a client-side e-mail client. There are add-ons that achieve this and some can even autoroute the documents based on the routing information.

The other advantage of SMTP server-side e-mails is that they can be richly formatted using HTML templates created through a built-in editor, and can use placeholders for information such as the details of a system alert.

SMTP requires the mail server to act as a relay for AX, as is the case of Microsoft Exchange. Your SMTP server should be configured to allow Dynamics AX to relay e-mails through it.

The batch framework allows many AX functions to be processed either as scheduled recurring jobs, or as once-only tasks to be processed asynchronously to the AX client by the AOS.

Typically, the tasks performed by the batch framework are scheduled jobs (for example, nightly sales invoice posting), or a process triggered by a user for which the user does not require an immediate response (for instance, processing an MRP calculation). In this case, the user may request an alert of its completion. Although users usually prefer the comfort of a progress bar and a message to state that it has been completed, submitting it as a batch job for many tasks is far more efficient as it allows them to perform other tasks while the server processes the task.

Developers also have the ability to use the batch framework to submit asynchronous requests from within a transaction, so as to improve the user response time. This may strike an element of fear in those who consider that the transactions should obey the ACID ( Atomic, Consistent, Isolation, and Durability) transaction principle; these will be for tasks where a compensation pattern can be implemented in order to handle an inconsistent state. A real-life example of this is the coffee shop queue, where you order and pay for your coffee, complete the transaction, and then wait for the coffee. If the coffee is not available, you would be compensated by the shop giving you your money back post transaction.

Not all transactions can ACID principle; for example, posting a supplier payment that sends remittances by e-mail. If the transaction fails after the e-mail has been sent, the database transaction will be rolled back, leaving the e-mail in the supplier’s inbox.

There are some important yet not so obvious points to consider when working with the batch framework: