Illustration of AIF Alert Mechanism

This blog describes the functionality of the AIF Interface Monitor’s Alert and shows some behind-the-scenes activity that can be helpful for when investigating the workings of AIF email notifications.

The alert indicator is found on the Interface Monitor, Transaction /AIF/IFMON, and is displayed as a lightbulb.   It is turned on automatically when an error is received for an interface. Once it is turned on, it is active. It will stay active until it is manually confirmed.  Any recipient of the interface can confirm the alert by toggling it to the off position. Alerts determine when email notifications are sent out.

Recipients of the Interface decide when they receive emails for an interface based on the alert.  There is a 3-way email icon toggle beside the alert that has the following values:

	Receive email for every error for this Interface, regardless of alert status
	Never receive an email for this interface
	Receive an email for the next alert.   This is the default setting.  If the alert lightbulb is turned on, it is in active alert and you will not receive emails for this interface.   You will only receive an email for this interface after it has been confirmed, which sets it to the off status.   If the alert is confirmed (turned off), then, if/when an error comes in for this interface, the alert will again be active, which will trigger an email. Subsequent errors for this interface will not trigger emails while the alert is active.

The alert may be at the interface level as mentioned above.  This is where you see the alert light bulb at the same level as the interface icon.  However, alerts may also be at the message category level or at the key field grouping level, depending on how your interface error handling is configured.

Please check out Michal Krawczyk’s blog for alert configuration instructions  https://blogs.sap.com/2016/08/19/michal-s-tips-aif-alert-recipient-based-on-error-message-class-and-message-id/

Example alert at the interface level:

Example alert at the message category level:

AIF alert processing with look at behind-the-scenes activity

In this demo I want to start off with a clean slate so in my development SAP system I have confirmed alerts for all my interfaces.

I can see that all the alerts have been confirmed by looking in table /AIF/ALERTS.   This table will hold a record for all active alerts.   Because the table is empty, I’m certain that there are no active alerts.

Using transaction WE19, I created three IDocs for my Interface, each generated an error.  The error generated is configured for message category VMITMS_BUSINESS and you can see the alert has been activated for this message category.   It was activated when the first IDoc with an error was created.

We can now see that the alert table has a single entry for the new alert.   If/when the alert is confirmed this table entry will be deleted.

Taking the Alert ID from table /AIF/ALERTS table, I can view its corresponding entries in table /AIF/ALERT_IDX.   This table shows all the IDocs that have been generated while alert 671 is active.  Here you can see an entry for each of the three IDocs I created.

Reading this same table by the Namespace and Interface name I can see multiple messages. Notice only the error messages are assigned alert IDs.

Application Log

AIF logs information in the application log, transaction SLG1.   From the SLG1 selection screen enter Object = ‘ALERT’ and Subobject = ‘PROCESSING’ and you can see that an entry was made when the email was sent out.   There is only one entry because only one email was sent out.  Alternatively you can see emails that are generated using transaction SOST.   Keep in mind that more than just email alerts are logged in SLG1 so check it out the next time you are debugging AIF.

One thing that SLG1 gives you that SOST does not is letting you know when email addresses are not found.   In SOST you can only see what did go out so you know which email addresses were found.   If an email address is not found for a UserID there will be no activity in SOST.   The log entry will list all the users assigned to the recipient for the alert.   If an email address is not found you will see, “Address of recipient XXXXXX (INT) could not be read”.

Email Preferences

As an admin, you may want to see others’ AIF email settings.   This is helpful when users are wondering why they have not received an email when they believe they should have.  Table /AIF/ALRT_USRNOT holds email settings by namespace, interface, version, recipient and user.  Below you can see each of the email icons from the Interface Monitor and corresponding value in the table.