Setting Up and Managing E-mails and Batch Processing

4 min read

(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:

  • The batch framework runs on the server tier, and therefore, on a Windows Server that hosts the AOS service. This means that the server should be able to access any file paths, printers, and so on. The tasks will run as the security context of the user who submitted the task, but any external access (for example, files) is performed using the AOS service account.
  • This note is mainly for developers. The tasks will run in CIL; this means you may find that the old code is executed even when a change has been made to your X++ code. This includes reports that run interactively, all code that runs on the server tier, and certain code that is client-side and pushed to the server tier for performance. The only way to ensure that the new code is being run is to restart the AOS service.

    Please enter your comment!
    Please enter your name here