How Alerts can Degrade Your Dynamics AX System Performance
The use of alerts in Microsoft Dynamics AX is a very helpful feature. Alerts allow end users to get an email or a Dynamics AX notification when a condition has been met. The purpose is typically to let the end user know they need to take action on something. For example, a common alert I see people set up is to notify an individual in the warehouse if the requested ship date on a sales order has changed. This way the warehouse worker can determine if they need to take action to be able to meet the new requested ship date.
What most people don’t realize is the impact alerts can have on the overall performance of their system. To understand why it makes an impact, it is helpful to realize what happens behind the scenes. Let’s take a look at what happens from the creation of an alert to the sending of an alert.
Creating an Alert and Sending Alerts in Dynamics AX
1. A system administrator sets up batch jobs for change based alerts, due date alerts, and email processing. These should be run on a recurring basis based on how quickly alerts are needed. The most often they can be set to run are every minute but most people find that this is too frequent and somewhere between 10 to 30 minutes works best in their system.
2. An end user creates an alert. When this happens a record gets written to the eventrule table and some associated tables (such as the eventruledata table). A record also gets written to the databaselog table. This is because the alerts functionality utilizes database logging to be able to track inserts, updates, and deletes to the table.
3. When a record is inserted, updated, or deleted for the table that the alert was set on database logging will write a record to the eventcud table.
4. When the alert batch job runs it will check the eventcud table to see if any of the alert conditions that are specified in the eventrule table have been met. If they have been met and an alert needs to be sent out that data gets written to the sysoutgoingemailtable and removed from the eventcud table. For records that didn’t meet the condition, they get removed from the eventcud table.
5. When the email distributor batch job runs this is what actually sends an email or a popup in Dynamics AX to the end user.
Example of Problematic Alerts in Dynamics AX
This process may not seem like it would be problematic, but it can be when alerts are set on high volume tables. Let’s say your company typically adds 1,000 sales orders an hour which would be considered a high volume. An account representative in your organization has a very important client that demands attention to any order they submit. So this account representative creates an alert to get notified anytime a sales order for this client is entered. This seems harmless but let’s look at what that does to the system. What happens is that for every sales order not only do you have these 1000 sales orders an hour added to the salestable but they are also added to the eventcud table. Meaning you have doubled the write activity on the database for these sales orders. The next part comes when the alert batch job runs. If it runs hourly then this batch job has to go through all 1000 sales orders to check to see if the sales order is for the client specified in the alert rule.
What can happen with these alerts on high volume tables is that the alert cannot finish processing the records because as it gets through checking records more records are added. What a number of people have run into is that the alert batch job will run for hours and not finish. This can prevent other batch jobs from starting if they utilize the same AOS Batch server.
Use Dynamics AX Alerts with Caution
While alerts are a feature in Microsoft Dynamics AX that can provide great benefits to an end user they must be used with caution. What I have started recommending is that my clients put into place a process for managing alerts. This process removes the ability for any individual to create alerts. An end user can request an alert to be setup but a subject matter expert/supervisor/system administrator has to review the alert and determine that it would not be detrimental to the system. If the subject matter expert/supervisor/system administrator determines that this alert provides business value and doesn’t pose a performance risk they can setup the alert on the user’s behalf.
In addition to alerts, my experience performing numerous health checks has allowed me to identify 10 other common issues affecting Dynamics AX system performance. A Stoneridge Software AX Health Check reviews several areas of your system and clients are provided with a scorecard and executive summary, presenting top issues and recommendations. Learn more about our Health Check service and download a sample AX Health Check Report here.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.