Intro
Standard mechanism of alerts in SAP PI/PO Java-stack (CBMA) has a lot of problems:
- Large amount of manual work:
- Creates a lot of same emails. Support team need to read hundreds or thousands emails per day.
- For many alerts, the reaction is not required (automatic reshipping from extenal system or support team wait development team for fix problem).
- Poor result quality:
- Due to the amount, many identical errors make it difficult to pay attention to isolated cases of another problem.
- A significant part of the alerts require manual steps to be taken by the PI/PO support, and there is no knowledge base to describe them.
- No teamwork:
- A support employee sees errors that occurred during the productive launch of the project, where the flows are watched by development team employee.
- The person on duty today does not see how the analysis of the alert was ended yesterday.
As a solution to the problems, I suggest using the external Non-SAP (open source) system
PiAlert:
Purpose of the system
The vendor suggests using the SAP Solution Manager functionality. But the standard implementation of alert aggregation is inconvenient. Most of the important information for the support team is erased (e.g. message_id). Our experience has shown that using the SolMan standard is possible only after serious ABAP development (Fiori).
SAP PI/PO settings
Step 1. On the SAP PI side, we create an Alert Rule, in which we add all the Communication Components, and add a new Consumer.
Step 2. Create new ICO: JMS Sender (read queue for created Consumer) → Without mappings → REST Receiver (PiAlert service)
So, The standard implementation of error notifications in SAP PI/PO (CBMA) will create alerts that will read and send to PiAlert in the standard SAP PI scenario.
Processing in PiAlert
All incoming alerts are grouped according to the following algorithm:
- Checks if PiAlert already has an alert group with the same parameters (Sender, Receiver, Interface).
- If yes, then text errors are checked:
- If the text is identical (or same for 95% of the characters, or fit to the text error mask), then the new alert is added to the same group.
- If the text is similar to 50% - 95%, then system create a new group, but it is marked "for manual analysis" (maybe merge to exists group).
- If the text is different, then system create new alert group.
Dashboard
All alerts are grouped by error type. In most cases, this happens automatically. In other cases, the support person decides to merge the two groups or leave them different (manual aggregation).
Merging groups
Other features
- Isolated system of users and access rights.
- Possibility to control “whether the on-duty support officer is online”.
- Warrant canary to track the fact of network problems between PiAlert and SAP PI/PO (through an additional ICO in SAP PI or through an analysis of the average frequency of receiving alerts).
- Blocking system in the web interface (on input fields level) for teamwork of several people.
- Export the collected knowledge base to an Excel file.
- Support team actions (in PiAlert) statistic.
- Semi-automatic code update system for new versions of PiAlert.
- Calculation of statistics by types of errors or by SAP PI/PO systems.
Statistics of error type
Statistics by systems
Summary
You have read the manual for automating SAP PI/PO support using an open source tool.
PiAlert significantly reduces the load on the support team:
- 40% of alerts are categorized as "ignore".
- 40% of alerts are massive failures in external systems, so such errors are massively closed with the same comment.
- There are 18 times less types of errors than the alerts emails.
And how did you solve PI support team problems? I will be glad of your comments and questions.
Welcome to https://github.com/Evan1989/pialert