Alerts are processed with the batch processing functionality in Microsoft Dynamics AX. Batch processing must be set up for alerts to be delivered.
Microsoft Dynamics AX supports two different event types.
-
Triggered by change-based events, the so-called Create/Delete and the Update events
-
Triggered by due dates.
You can set up batch processes for each of these types of events.
Process
batches for change-based events
Microsoft Dynamics AX reads all change-based events (field updates, records deleted, or records created) that have occurred since batch processing was executed the last time, and these events are matched with the conditions set up in alert rules. The batch process generates an alert when an event matches the rule conditions.
Set up a batch frequency for change-based events
For change-based events, you can set up a batch job that triggers the processing of an event soon after the event is logged by the system. The higher you set the frequency of batch job execution, the sooner after a change has happened users receive their alerts. However, a high-frequency number might have a negative impact on the performance of the system.
If, on the other hand, the frequency is low and is scheduled for times when the system load is low, it would benefit the performance, but a low batch-processing frequency might not fulfill users' demands for timelines of their alerts.
So when setting the frequency of change-based event batches, consider the balance between timeliness of alerts and the performance of the whole system.
The greater the number of users who create alert rules, the more relevant these considerations are. That is, the number of events to be processed does not change with the frequency, but the more users that create rules, the more checks need to be performed. This kind of data exchange could impact system performance.
Note
|
|---|
|
The time that passes before users receive their alerts is also controlled by the time interval by which Microsoft Dynamics AX polls for new alerts. The time interval must be set in minutes. The minimum value is 1 and the maximum value is 1440 minutes (1 day). |
Set the time interval to poll for new alerts
-
Click Microsoft Dynamics AXmenu > Tools> Optionsto open the form.
-
Select the field in the group.
-
Enter the time interval.
Examine the risks of low batch frequency
If you set the change-based batch processing to a low frequency you could end up loosing alerts, because data which are relevant for alert rule conditions change before the batch is processed.
For example, you might have an alert rule that should trigger an alert when the event is "customer contact changes" and the condition is customer = BB. Now, the customer contact changes for the customer BB and the event is logged, but the batch processing system is set up with a low frequency relative to the frequency of data entry so before the event is processed, the customer name changes from BB to AA. When the event is processed, the data in the database no longer matches the rule condition (customer = BB), and no alert is generated.
Process
batches for due date events
Microsoft Dynamics AX detects all events caused by due dates, and these events are matched with the conditions set up in alert rules. The batch process generates an alert when an event matches the rule conditions.
Set up batch frequency for due-date events
For due-date events, you might want to set up batch jobs that execute during the night or at specific times of the day to balance the system load. You should at least set up the batch to execute once a day. If you want alerts to be sent as early as possible, the batch processing should happen immediately after the system date changes. If you want to generate alerts from due-date events that happen after a due-date batch has processed alerts, you can run the batch once more on the same day.
If a purchase order is created with a due date that would trigger an alert on that same day, you would have to execute the batch after the purchase order is created to get the alert on that day. However, if you do not run the batch again on that day, the next day's batch job picks up any non-processed due-date events from the previous days.
|
Note
|
|---|
|
Even though the batch process is run more than once a day, alerts are not generated twice for the same due date event and conditions. Alerts are only generated for any dates that have become due because of changes in the system that happened after the last batch was executed. |
Set flexible due dates
Alert-rule processing could be halted in a company for reasons like vacation, system break down, or other issues that could cause batches not to be run for a designated period of time.
To avoid situations where due-date alerts become obsolete because the batch has not been running for a few days, you can use the batch-processing window interval to allow the batch to not run for a specified number of days.
With the batch-processing window set to a number of days, an alert is sent when the alert rule is processed, even though the alert exceeds the time limit defined in the due-date criteria, so long as the due-date criteria plus the additional batch processing window interval is not exceeded.
However, if the time limit defined with the due-date criteria plus the additional batch processing window interval is exceeded, an alert is not sent.
Example
You create an alert rule by which you are alerted when an employee birthday was two days ago.
The batch processing window interval is set to 10 days.
|
Batch runs on day 1 |
You are alerted about employees whose birthdays were 2 days ago |
||
|
Batch does not run on day 1 but on day 2 |
You are alerted about employees whose birthdays were 2 days and 3 days ago. |
||
|
Batch does not run on day 1 or 2 but only on day 3 |
You are alerted about employees whose birthdays were 2, 3, and 4 days ago. |
||
|
Batch does not run on day 1,2, 3, 4, 5, 6, 7, 8, 9 but only on day 10 (within the 10 days) |
You are alerted about employees whose birthdays were 2, 3, 4, 5, 6, 7, 8, 9, 10 and 11 days ago.
|
||
|
First time the batch runs is the 11th day (that is, not on day 1-10) |
You are alerted about employees whose birthdays were 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 and 12 days ago.
|
||
|
First time the batch runs is the 12th day (that is, not on day 1-11) |
You are alerted about employees whose birthdays were 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 and 12 days ago.
|
From this example, it appears that if the batch-processing window interval is set to 10, there can be a period of at the most 10 days when the batch does not execute. The batch has to run at the latest the 10th day to ensure that the alert is generated.
If the batch processing window is set to 0, you are alerted only if the batch runs two days after the birthday. In this case, the batch has to run every day to not lose any alerts.
Set the batch processing window interval
-
Click > > > .
-
In the field, enter the number of days you want for due-date flexibility.
Delete the
event queue
When you activate a batch that processes change-based events for a company, you should check the event queue and decide if all the events in the queue should be sent out as alerts. If the old, non-processed, and obsolete events are not deleted, the batch generates alerts and potentially sends user many useless pieces of mail, or "spam."
Users might have set up alert rules long before the batch process is started, and the events that have been generated might create many obsolete alerts. Users might have had access to create rules months before the batch is activated, and the events that are triggered by the users' rules are logged by the system no matter whether the batch is activated or not.
If you decide that the events in the event queue should be regarded as obsolete and not be sent out as alerts, the event queue can be deleted.
-
In the Application Object Table (AOT), select Data Dictionary> Tables.
-
Select the EventCUDtable, locate the events to be deleted, and delete as appropriate.
Turn off
alert generation during data import
When new company data is imported it would be a good idea to turn off the generation of alerts. The new data might trigger a large number of alerts for users and to avoid users who have created alert rules being spammed with alerts, the feature can be turned off.
-
Click > > > .
-
In the dialog box, select the tab.
-
Clear the check box and click OK.
