SAP Reporting vs. SAP Monitoring

For a lot of teams that manage SAP environments, the terms reporting and monitoring are often used interchangeably. This typically leads to a lot of confusion and misunderstanding, especially when speaking with other organizations, at conferences or speaking with vendors.  

Debunking SAP Reporting and SAP Monitoring Terms

The SAP world has a ton of acronyms, abbreviations, a single name for multiple solutions and multiple names for a single solution. So let's see if we can at least clear up the reporting/monitoring terms in this world of confusing naming conventions.

Before we dive into the bulk of the differences, it’s important to note how these two terms got so incredibly interchanged in this environment. Basically, as we all know, SAP is a beast with a mind of its own in an organization. It’s coded in its own language and requires a specific team of people to manage and support it. What that means is standard enterprise-wide monitoring or reporting tools don’t work, especially not 5, 10 or 15 years ago.  So what was primarily used was a solution built within the SAP system called CCMS. 

The primary purpose of CCMS was to give insights into the health of the environment because no third-party solutions could. Being the sole solution to collect this information, at the time meant it was used for any purpose under the cloud (pun NOT intended lol).   Engineers utilized this information for alerting and notification purposes. But soon the management requests started coming in for historical tracking of data health points, looking for trends, etc. 

With nowhere else to turn, the engineers utilized the one solution they had available to them, CCMS. Soon the industry was utilizing CCMS, the single solution data points, for alerting, trend analysis, database growth analysis, etc. It was a mess. Then the day of SAP Managed Service Providers came to be.  With SAP being the lifeblood of an organization, the SAP Managed Service Providers needed a way to show their customers that they were proactively maintaining the systems and keeping them in a healthy state. A daily/weekly/monthly report was typically the answer, utilizing CCMS monitoring information as its primary data points. So now we had management within organizations requesting reports from monitoring data and MSPs utilizing monitoring data for periodic reports, and thus the “SAP Monitoring Report” was born.

What Change Fueled SAP Automation?

It wasn’t until fairly recently that the industry started to look at the notification data they were receiving and the reports they were reviewing and saw that too much confusing data was being sent too often for alerting purposes, often bombarding inboxes with pointless emails, and reports that lacked the necessary information to have any value.   What transpired was splitting the data apart, making different ways to collect and use data for ‘monitoring’ and ‘reporting’ purposes. This ability gave organizations a way to pull large sets of data for reporting purposes, but also receive up-to-the-minute data for monitoring purposes, blazing the way for ‘SAP automation’, a term still not trusted by many in the SAP world. It’s funny to think how the historical improper use of monitoring and reporting data is probably the primary factor in why SAP technical automation is late to the world of IT automation. 

SAP System Monitoring Data

Modern-day monitoring data is collected periodically throughout the day. Depending on the type of data, the cycle it is collected is changed. For example, system up/down monitoring data is collected more frequently than information on certificate validity. Also, because the data is NOT being used for reporting purposes, not as much information needs to be collected.

For example, when monitoring for short dumps, there is no need to pull the full list of daily shortdumps every 5/10 minutes as that will be overload for the system. Doing so will crush the performance of the SAP system, cause network performance degradation and the monitoring system database will grow exponentially. Instead, the amount of short dumps over the last X amount of minutes (perhaps over the last hour) with a brief capture of those specific dumps, is what is valuable for monitoring purposes. 

The monitoring data can then be used for alerting and notification purposes, dashboarding and even to trigger automation. Imagine trying to use a 20-page report to spawn a set of orchestration steps to automate an immediate resolution of an issue, or ensuring the correct person is receiving the correct alert notification - it just wouldn’t work and is almost commercial to consider.

SAP Reporting Data

Reporting data comes in all different formats, but the key difference from monitoring data is it’s collated less frequently, but has more data. This is where lists of IDOC issues, spool errors, shortdumps, (the list goes on) comes into play. This is data is used for looking for long-term trends, analysis of problems, historical charting and a good solution will even provide predictive analysis on things such as growth trends. 

The most frequently that reports should be compiled and reviewed is daily. There have been a few scenarios where organizations have requested reports two times a day for production systems, but really those are organizations without a good SAP monitoring solution in place. If the desire is there to review reports more than once per day, a dashboarding solution should be looked into. The reason is that a report is a snapshot in time. A report is only as good as the data that is collected and what was valid yesterday, may not be valid today. So if more periodic or up-to-date information is required, consider dashboarding a better use of up-to-the-minute data.  

It’s also important to note that reporting data should be kept a lot longer than monitoring data. Let’s walk through using the shortdump example from before. It’s probably of no use to know that back on October 2nd of 2019 that there were three shortdumps that happened between 1:00 pm and 2:00 pm. However, it may be informative to know that a specific short dump occurred on that day in the Q3 quarter-end closing process. Being able to easily go back and retroactively find this information could align you with troubleshooting data points that you are currently experiencing and thus it’s good to have readily available. This doesn’t necessarily mean retaining pdf reports in your inbox indefinitely but you shoujld have a solution in place that can split off monitoring and reporting data and retain that reporting data for a longer period of time than the monitoring data.

Overall, the industry has seen a shift when it comes to reporting and monitoring data, specifically in the SAP ecosystem. Through the separation of monitoring and reporting data, what was once a confusing and often aggravating way to look at SAP system health, now provides organizations and Managed Service Providers alike, a clear-cut picture into those systems.  To hear more about how Avantra can assist your company with its SAP Monitoring and Reporting please reach out to us here.