Nowadays everything is going to be centralizing, as many of you already testing the benefits of Centralization like CUA (Central User Administration), Central Monitoring..etc. PI uses ALM (Alert Management) to notify the process errors at different stages, by configuring Central ALM, alert notification configuration can be simplified and significantly reduce the maintenance. Solution Manager is one of the powerful SAP tool to manage solutions from implementation to support. Since SOLMAN use to monitor systems and solutions, it is recommended to use SOLMAN as central ALM system. Once you setup the central ALM, the runtime workbench Alert Configuration is connected to central ALM server (i.e SOLMAN) not the local PI system.
1. Central ALM (Alert Management) will be reduced maintenance to one central system instead of multiple systems in the landscape.
2. No need to maintain alert categories in each system, categories can be maintained in central system which can be accessed to the connected systems (DEV, QA, PROD …etc).
3. Alert rules can be created centrally and no need to transport or recreate them in each system in landscape.
4. Alert email notification (SCOT) configuration can be done centrally, no need to maintain in connected systems.
Alert notification process:
PI errors can be classified into two categories (Integration Engine, Adapter Engine). All adapters (in J2EE) related errors like communication channel is inactivate, user authentication, invalid parameters …etc are reporting from AE. Message process errors are (mapping, routing …etc) notifying from IE. These errors are reported to the PI application program to process the alert notifications. Alerts are created in the local system (i.e PI DEV). Notifications are delivered through the different channels, if Central ALM is configured then this process handles from central system (i.e SOLMAN) otherwise local system deliver the notifications.
Alert Process Flow Diagram
- Error Occurred in Integration Engine (i.e Mapping error)
- Notification program checks for CentralMonitoringSever-XIAlerts RFC Destination.
- If the RFC destination does not exist it will create the above RFC destination.
- Check the RFC connection.
- If the connection is failed then the program will be terminated (Alert won’t be generated), otherwise, check for matching rule.
- The above checks are not applicable to Adapter Engine errors, they processed from here.
- Get the RFC destination from SLART1 transaction.
- Send the alert to the RFC destination, if central ALM is configured then it will go to the central server (i.e SOLMAN), otherwise, alert will be delivered to the local PI server.
An RFC destination must be maintained in the SALRT1 transaction in order for alerts to work. PI will create the CentralMonitoringServer-XIAlerts as default RFC destination automatically on the triggering of the first alert, it uses the Exchange Profile -> Runtime Workbench configuration information to create the RFC destination. If you maintain NONE in the SLART1 configuration it will uses the default (CentralMonitoringServer-XIAlerts) RFC destination. Even though different RFC destination is maintained in the SLART configuration the default RFC destination must be in valid state, otherwise, alerts won’t be processed. Alert log can be viewed in the local system with the SXMSALERT_LOGREADER report.
As alerts notification usage is increasing by number of applications (CRM, SRM …etc), Central ALM process reduces significant maintenance. There are some cons if one central system maintains for entire landscape, separate alert categories need to be maintained for Production and Non-Production environment, otherwise, non-prod alerts may go to the production users. Once you cross these initial hurdles then it will be a smooth sailing.