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 Process Orchestration Runtime Engine(s) or in SAP business systems. On Process Orchestration 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 Process Orchestration (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 Process Orchestration 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 (SAP Process Orchestration alerting) have some issues:
- We get far too many alerts (flooding) and oversee the one we need to react on it in time
- 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
- 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
- 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 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 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. It is called WHINT Interface Monitoring and is provided as PI Integration Content (ESR) as well as an ABAP transport to read from the SAP backend systems.
This approach will lower the time to resolve interface errors and minimize a negative impact on business operations!
Comments are closed.