Event Detection and Processing for Alerts

Applies To: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

Microsoft Dynamics AX supports two different event types, change-based events and due-date events.

• Change-based events are Create/Delete/Update events (also known as CUD events).

• Due-date events are events generated by due dates.

Change-based Events (CUD Events)

The Alerts module uses the database log to detect changes to records, but has its own set of callback methods on the application class: the EventInsert method, the EventUpdate method, and the EventDelete method. Four Alerts-specific values, EventInsert, EventUpdate, EventDelete, and EventRenameKey, have been added to the DatabaseLogType Enumeration enumeration. The values cover types of events that can generate alerts.

The Alerts module logs changes to all tables where users have set up rules in the EventCUD table. This is similar to the database log module, which logs changes to monitored tables in the SysDatabaseLog table when callback methods are invoked.

When the CUD event processor is invoked (and implemented in the EventJobCUD Class), it processes any new CUD records found in the EventCUD table by matching them to users’ rules in the EventRule table.

Note

Anything in the Application Object Tree (AOT) that starts with "Event*" belongs to the Alerts functionality, which is a notification system that helps users track critical events in Microsoft Dynamics AX.

How Matching is Implemented

First, the event processor unpacks the EventType* object, which is packed when a rule is created. Then the event processor adds the object instance variables that are required to determine whether the event (that is, the information stored in the EventCUD record) matches the criteria specified by the EventType* object. This piece of information varies by event type, and it is extracted from the EventCUD record. The placeholder variables for storing it in EventType* objects are all members of the top level EventType object.

Note

EventType* classes are organized into a hierarchy. The lower the level that an EventType* class in the hierarchy is, the more specific is the event that the class represents. For example, the EventTypeCUDIncreased class represents (the event of) any increases to a numeric data field, while the EventTypeCUDIncreasedAbove class, inheriting from EventTypeCUDIncreased, represents only increases exceeding a certain value. The top level class (called EventType) is an abstract class, and it represents any event.

In the default implementation, the value of the TypeTrigger member of each EventType* class (this is set when a rule is created) determines what type of information the event processor adds to the EventType* object at event processing time. If, for example, TypeTrigger is set to TypeTrigger::FieldUpdate, it adds both the old value and the new value of the monitored field in the placeholder variables, because these values are required when the isMatchingRule() method is, later on, called on the EventType* object.

Next, the event processor invokes the isMatchingRule method on the EventType* object to determine whether there is a match. If the method returns true, the event processor unpacks the list of action class IDs that are stored in the EventRule table for each rule, instantiates each action class, and then calls the execute method on each of the instantiated action classes.

Matching example

Consider the EventTypeCUDIncreasedAbove class. When a user selects the has increased option in the Event option box on the Create alert rule form, an instance of the EventTypeCUDIncreased class is created. The TypeTrigger of this instance is set to FieldUpdate, and the xValue placeholder variable is set to the event parameter entered in the form. If, for example, the user wants to monitor only increases above 100 and thus enters 100 in the text box next to the Event option box on the Create alert rule form, the xValue is set to 100.

When the user closes the form, the object is packed up and stored in the EventRuleData table.

The information about the table field in which the increases are monitored is not part of the state of the EventTypeCUDIncreasedAbove object. This information is stored separately in the EventRule table.

When the event processor is matching an EventCUD record against the rule, it unpacks the EventTypeCUDIncreasedAbove object. Because the TypeTrigger of the EventTypeCUDIncreasedAbove class is set to FieldChanged, both the old value and the new value are set on the object. The processor then calls the isMatchinRule method on the EventTypeCUDIncreasedAbove class, which is shown in the following example.

    public boolean isMatchingRule()
    {
        return (currentValue > originalValue || eventRule.IsAggregated) &&
                   (currentValue > xValue);
    }

Due Date Events

The processor of due date events (EventJobDueDate Class) works the same way as the event processor does for CUD events. Due date events are detected at event processing time when the rules are examined one by one to determine whether the values of the monitored date fields match the criteria specified by the EventTypeDue* objects that are packed up in the rules.

To prevent the same due date event from being processed multiple times (for example, if a deadline is due in X days, and the event processor is run multiple times before the deadline is due), the due date event processor maintains a list of time-based events that have already been detected in the EventRuleIgnore table.

Objects related to event processing:

• EventCUD and EventRuleIgnore tables

• EventJobCUD, EventProcessorCUD, EventJobDueDate, EventProcessorDueDate classes

• All EventType* and EventAction* classes

Announcements: New book: "Inside Microsoft Dynamics AX 2012 R3" now available. Get your copy at the MS Press Store.