Skip to Content

This post was originally published on integration://excellence, the blog of Whitepaper InterfaceDesign.


In case of interface errors we have to be notified by the system. This is called alerting and an e-mail is sent to us.

Errors can occur in the SAP middleware PI/PO Runtime Engine(s) or in SAP business systems. On PI/PO they can be either connected to a message (mapping, routing, receiver channel) or to a channel only (sender). In a business system messages can fail in the proxy runtime or application errors occur (e.g. when a function/BAPI is called).


Alerting exists in PI (Dualstack) using the (old) Alert Management where alert categories and e-mail receivers are defined in transaction ALRTCATDEF. We can define texts (Subject & Body) with dynamic message header and error information.

In addition CCMS (transaction RZ20) can be configured to monitor and send e.g. errors about queues (qRFC & tRFC). This is quite terrible to configure. If Java information should be monitored, an additional agent needs to be configured.

Since PO (Java Singlestack) we have an alternative approach for message-based alerting which is configured in NWA as a AlertConsumerJob (also V2 is available with a customizable e-mail template) and the scope can be defined comfortably in NWA/PIMON. An additional job also exists to send e-mails if messages are stuck in the processing: AlertStuckMessagesJob.

With Solution Manager 7.1 we also have a work center “System Monitoring” that covers SAP PI/PO errors as well. It uses the agents to retrieve system information about channels, messages and much more to visualize it in SolMan and send out alert e-mails. The setup is not difficult, but to make it work nicely only distributing what is needed and to filter the data with templates takes a lot of time and energy. And still things remain that work somehow as they do and nobody knows why…


However, all alerting solutions (PI & PO alerting) have some issues:

  1. We get far too many alerts (flooding) and oversee the one we need to react on it in time
  2. In case we have configured a confirmation mode (an alert is sent after the first is being confirmed manually), we might not do it in time and receive no information about the message in error
  3. We receive no information about messages stuck in queues (being scheduled for EOIO or simply in a strange error situation that we might did not foresee), especially in backend systems
  4. What also might be an issue if we expect to receive a message (e.g. weekly or daily) and the system does not send anything. This case is not covered by alerting, but we have solved this issue already using our MessageMissing Alert.

The alternative approach to standard alerting is to perform a snapshot of the interfacing landscape covering the central SAP middleware system(s) as well as the SAP business systems.

The idea is then to periodically extract the SAP interface landscape situation covering ALL channels, messages and queues with ERROR and SCHEDULED status in one go.

The data is read from the different sources using SAP’s standard APIs, grouped by receiver according to filter and threshold settings and distributed via e-mail.

This approach will lower the time to resolve interface errors and minimize a negative impact on business operations!

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply