ST-A/PI 01M & 01M SP01: IDoc Monitoring Corrections

1556983

Symptom

You have set up IDoc Monitoring for Business Process Monitoring in SAP Solution Manager. The version of the ST-A/PI add-on on the managed system is 01M or ST-A/PI 01M SP01. At least one of the following symptoms is dectected:
1) You want to monitor interfaces where many IDocs are created in a short time frame. The alerts created in Business Process Monitoring for these interfaces return wrong measured values.
2) You want to display the details of an alert with measured value larger than zero, but the detail info screen does not show the correct number of IDocs, or the screen is not called at all.

Other terms

IMIDOC01, Business Process Monitoring, BPMon, SAP Solution Manager, IFMon, Data Consistency Management

Reason and Prerequisites

1) Per monitoring object, the IDocs relevant for alerting are periodically collected and stored in alerting tables on the managed system. Currently, there is a restriction for the number of IDocs stored per monitoring object, which is 10.000 (in order to avoid excessive data growth). Data within these tables is re-organised. If you have set up a monitoring scenario where you pick up the alert with a low frequency only (for example once per day), it might be that not all IDocs which were created for the monitored interface are stored in the relevant alerting table, resulting in wrong alerts.
2) This issue only occurs if the monitored IDocs are subject to reprocessing. For example, if an inbound IDoc runs into status 51, it is alerted if you have set up a corresponding 'Delta Number Monitor' key figure. If the IDoc, after reprocessing, takes the same status 51 again, it is alerted with the next run of the 'Delta Number Monitor' key figure again. However, in this case the IDoc number that is stored on the managed system for being displayed in the detail info screen is kept only for the current alert, but is deleted for the previous alert.

Solution

1) In order to avoid that the IDoc alerting tables exceed the limit of 10.000 entries two measures can be taken:
- Per monitoring object, restrict the filter criteria defining which IDocs are to be alerted as much as possible. Rather create monitoring objects that are quite restrictive than monitoring all IDoc traffic on the managed system with one single monitoring object only.
- Adjust the monitoring schedule in a way that it matches the amount of IDocs created in the same time frame. This means, if you expect a number of 100.000 IDocs created per monitored interface per day, you should schedule to run the monitoring object at least every two hours.

If your business needs, however, require to have only non-restrictive alerts for the IDocs on the managed system, and you can't set the monitoring schedule to a low frequency, it is recommended to implement attached source code instructions on the managed systems using transaction SNOTE. These corrections remove the limitation to 10.000 entries per monitoring object for the IDoc alerting tables on the managed system. Be aware that this might result in longer run times of the IDoc data collection on the managed system, possibly causing the IDoc data collection to dump (for example, due to time out limitations or memory overflow).

2) Implement attached source code corrections on the managed system using transaction SNOTE. The detail info screen will then show you all IDocs even for older alerts where the same IDoc has been reprocessed and failed again.

All corrections are contained in standard as of ST-A/PI 01N SP01.

Header Data