Event Based Alerts

Background

M3 BE includes a large number of predefined application messages coded into the business logic but for some customers, these are inadequate and new messages have been added to the M3 product as modifications. In most cases, the event based alerts removes the need for coding new messages.

Follow these steps

1. Add a subscription to the M3 table to be used for the alert in 'Event Subscription. Open' (CMS045). The name of the M3 table is used as event name and M3 as a publisher.
2. Activate the subscription for event based alerts and set it as active.

   Define the alert

3. Define the alert in 'Event Based Alerts. Open' (CMS047).

   The description of the event based alert can be translated through F14 on (CMS047/E).

   Trigger alert

   Define when the alert should be triggered using filters where logical expressions like "Value changed", "Equal to" etc can be used for specific fields.

   Posted into Infor Ming.le or Infor OS Portal

   Select if the alert is also to be posted into Infor OS Portal or Infor Ming.le.

   Alert message to be generated

   Define the alert message to be generated.

   On (CMS047/F), you can translate the alert message into 5 additional languages. You can also define if message data such as name and descriptions should be translated. This works for item name or description (ITDS/FUDS), and name or descriptions translated through 'Language Handling. Open' (CRS830) (TX15/TX40). Additionally, select the Translate Message data check box if you require the message data to be translated.

   Note: Selecting the check box creates a negative impact on performance and is therefore not recommended if expecting high volumes of alert messages.

   Recipient of the message

   The recipient is always a defined M3 user but does not need to be a licensed user, and can either be a fixed user, retrieved from a field in the event or retrieved from a related table like item responsible from the item master for a sales order line event.

   The translation of the alert messages is based on the language of the recipient in 'User. Open' (MNS150).

   From both a performance and volume perspective, it is important that the filters are defined correctly and thoroughly tested in an environment with fewer transactions than a production environment. Since a normal M3 environment generates several hundred events per second, poorly defined filters can quickly generate massive amounts of alert messages.

   Post definition steps

4. Once the alert has been defined, the corresponding autojob must be restarted before the updated subscriptions become active in the Event Hub and the new definitions updated to cache.

   Restart the autojob in 'Subsystem. Open' (MNS050) and select related option 'Job in subsystem' (Option 11) for the autojob subsystem (normally named ASJ).

5. Find the autojob CMS911 (Event subscription - alerts) in the list.
6. End it and once stopped, start it again.

View alerts

The event based alerts can be viewed in various ways such as email, through the M3 application message widget in M3 H5 through Infor OS Portal Workspaces or Ming.le Homepages, directly in the M3 function 'Application Message. Open' (CRS420) or as alerts, tasks and workflows in Infor OS Portal or Infor Ming.le. The alert itself contains the message defined in the base program (CMS047) and usually a drillback link to the original M3 db record that triggered the event. Note that drillback links for events generated from customer defined fields (CDFs) that extend a standard M3 table, relate back to the main program for the extended table. Main program in this case is retrieved according to setup in function 'Table. Open' (MNS120).

Troubleshooting

The best way to troubleshoot the generation of the alerts is to turn on the concept log for the required autojob in the server view, or admin pages in a cloud environment. Once activated, generate a new event and then view the concept log written to the autojob log. Every validation performed within the autojob is written to the log as a readable text.