[AX2012 R3] about alerts

AX2012 provides two types of alert,change-based alert and due-date-based alert, which are used to alert when a new record is created, a record is deleted, and a specified field of a record is changed. The latter is a field that is used to monitor the record date type, and a reminder is sent after the specified date. In the edit form of the record or in the right-click menu on the list page we can find the "create Alert rule" menu item, which opens the Alert Rule Creation window. Rule Creation Window We can choose which alert to send to, only a specific user, not a user group, if the notification needs to be sent to more than one user can create more than one alert rule. In addition, we can check "send email" to send the notification via email to the user, to use this feature must be set up the alert email template, first in organization administration>setup> Email-template Create an alert mail template (not a system mail template), you can add placeholder variables to the message template to point to real data when you generate a specific message. Examples of alert mail templates can be found in https://technet.microsoft.com/en-us/library/aa834376.aspx. After creating the mail template, we also need to organization Administration>setup>alerts>alert parameter Select this email template for our Alert mail template. All notification rules can be found in organization Administration>setup>alerts>alert, where you can manage the creation of a good notification rule, enable or delete rules, etc. The list of notification rules is a column called Organiztion-wide, which is not manually modified, and is automatically ticked if we add rules to a company-independent table (such as workers, products).

The notification rule is created so that you receive the alert message when the record changes, and we need to configure two batch jobs to process the notification message. One is the System administration>periodic>alerts> change based Alerts, which handles change-based notifications. The other is the System administration>periodic>alerts>due date Alerts, which comes out due-date-based notification.

Let's take a look at Change-based's batch task, which runs the class Eventjobcud, which is just a matter of determining whether or not the alert event is to be handled in the Eventcud table, and if so, referred to Eventjobcudtask. Eventjobcudtask reads the user ID of the record that Eventcud needs to process, switches through RunAs to the user running Eventjobcudtask.runcudeventsforuser (), Runcudeventsforuser reads the user-related Eventcud record in turn and is then referred to eventprocessorcud for processing. Eventprocessorcud does different processing for the type of event (update, delete, create, primary key change), such as update event, which strips out the field ID, new and old value of the monitored record field from the Eventcud data field (container type). Create the Eventtypecud object, save the new old value for the updated field, and then create the corresponding eventaction based on the notification type in the notification rule, and then save the corresponding event notification in the EventInbox table. If you specify to use mail notification, a Eventactionemail object is created, which is responsible for generating placeholder object data mappings. Send the actual message to sysemailtable or sysemailsystemtable to sysoutgoingemailtable waiting to be sent. The related record is deleted in Eventcud after processing is successful. Here is just a simple statement of the process, the actual process is much more complex, need to handle table inheritance has been notified that the rules specified in the Record filter query and so on.

It can be seen that the core of change-based notifications is the processing of Eventcud records, so where does the data in this table come from? Microsoft's explanation is to use the database log to detect record changes, the alert module in the Xapplication class Eventinsert, Eventupdate, Eventdelete register their own callback function, If the table that is involved in the notification rule changes, the change is recorded to the Eventcud table. What you can see is that if we add a notification rule, a record is added to the table databaselog that records which table does the eventxxx type of log. System Administration > Setup > Database > Database log Setup does not see these records, and this form does not display and eventxxx types of databaselog. Changes to the table records that are monitored by the notification rules are recorded in System Administration > Inquries > Database > Database log and are not visible, but related records are added in Eventcud. Xapplication is a system class that does not see how it is implemented.

Then look at Due-date-based's batch task, which runs Eventjobduedate, which reads the user ID of the notification rule for the Due-date type in the EventRule table, Also runas switches to the user execution Runduedateeventsforuser (), called Eventprocessorduedate.processrule () in Runduedateeventsforuser To process the current EventRule, read the records from the EventRule filter query, read the records in query, call Eventprocessorduedate.processrecord () to process the record, if the Date field is extended, The corresponding eventaction is also created according to the notification type in the notification rule, and the subsequent procedure is similar to the change-based. If the notification rule has been triggered and processed successfully, the notification rule is added to the table Eventruleignore and is no longer triggered (in Eventtypedue.canexecute () judgment).

After understanding how alert works, we can add custom event types (eventtype) and custom event handling actions (eventaction), which can be found in https://msdn.microsoft.com/en-us/library /aa673670.aspx.

The notification message is saved in table EventInbox, in the notification section of the user options we can set the time interval to accept notifications, the client reads the notification message at intervals, and if the notification is set up to display pop-up windows, the AX client pops up the popup. What you can imagine is the direct operation of EventInbox to create user notifications, there are many examples on the internet, here to intercept a (http://daxldsoft.blogspot.com/2012/10/ create-custom-alert-for-ax-with-go-to.html):

  Public Static voidCreatealert (str message, str subject, UserID userid=Curuserid (), NoYes showPopup=Noyes::yes, NoYes sendEmail=Noyes::no, Common record=NULL, str datasourcename="', Menufunction menufunction=NULL) {EventInbox inbox;     dicttable table;     Eventcontextinformation ECI;     Eventinboxdata Inboxdata; args args=NewArgs ();     List List; Eventinboxid Inboxid=Eventinbox::nexteventid ();     FormRun FormRun;     Workflowrecordcaptiongenerator Recordcaptiongenerator;     UserInfo UserInfo; Inboxid=Eventinbox::nexteventid ();     Inbox.initvalue (); Inbox. ShowPopup=ShowPopup; Inbox. Subject=subject; Inbox. Message=message; Inbox. SendEmail=SendEmail; Inbox. Emailrecipient=Sysuserinfo::find ().     Email; Inbox. UserId=userId; Inbox. Inboxid=Inboxid; Inbox. Alertcreateddatetime=Datetimeutil::getsystemdatetime (); if(record) {table=Newdicttable (record.       TABLEID); ECI=Neweventcontextinformation (); if(!menufunction) {menufunction=Newmenufunction (Table.formref (), Menuitemtype::D isplay); if(!menufunction)ThrowError (STRFMT ("@SYS104114", Table.formref ())); }       //Build the data to drill down to from the notificationArgs.menuitemname (Menufunction.name ());       Args.menuitemtype (menuitemtype::D isplay); Args.name (menufunction.Object());       Eci.parmpackedargs (args);       Eci.parmalertbuffer (record);       Eci.parmalertformdsname (DataSourceName); //Eci.parmdontuseformrunfrommenuitem (TRUE); Inboxdata.inboxid =Inboxid; Inboxdata.datatype=Eventinboxdatatype::context; Inboxdata.data=Eci.pack ();       Inboxdata.insert (); Inbox. Alerttableid=table.id (); Inbox. Parenttableid=table.id (); Recordcaptiongenerator=workflowrecordcaptiongenerator::construct (record); Inbox. Alertedfor=recordcaptiongenerator.caption (); List=Sysdicttable::getuniqueindexfields (Table.id ()); if(list) {inbox.keyfieldlist (List.pack ());       Inbox.keyfielddata (Sysdicttable::mapfieldids2values (List,record). Pack ()); } Inbox.companyid=Record.company ();   } inbox.insert (); } 

Use the above function to create alert:

 static  void       Job155 (Args _args) {InventTable inventtable;      select   firstonly InventTable; Devutils::createalert (  message  , "   Subject  , Curuserid (), true , Span style= "color: #0000ff;" >false , InventTable,  inventtable   , new     Menufunction (Menuitemdisplaystr (ecoresproductdetailsextended), Menuitemtype::D isplay)); }  

The above Createalert function has a sendemail parameter, corresponding to the EventInbox field SendEmail, set this parameter to true, we will not receive mail, because we just tagged this field, I did not find the system, such as batch Job to send EventInbox by mail.

[AX2012 R3] about alerts