Dad Bod vs STAD Bod… Splunking SAP Returns! (March 2021)

STAD data, AKA Business Transaction Analysis records, deliver granular performance statistics on essentially every unit of work processed by SAP. Exciting, huh? STAD is the “hipster” T-Code in SAP... generating “big data” way before it was cool. So, it’s no mystery why this has been one of the most difficult datasets to analyze and work with across SAP environments that were primarily designed to process business data in real-time, rather than crunching huge volumes of analytical performance data.

Most SAP Basis teams I meet only see STAD as a transaction to be used in moderation to troubleshoot performance. And you know what? I can’t fault them. Pulling these reports in a production environment creates heavy load, the investigation process is tedious, and to make things worse, STAD records are only stored for a few days at maximum. With no way of customizing the views or aggregating them, the notion of using them to do anything other than a narrow performance analysis in the past was simply impossible.

Bottom line: without capturing STAD data and moving it to an SAP-certified analytics platform, leveraging STAD was a non-starter.

BUT THAT WAS THEN.
Enter PowerConnect, and its ability to connect SAP to Splunk, fulfilling the Big Data promise in SAP.

Let me expand a bit on how the use cases are being transformed. In its non-Big Data world, STAD data would be resorted to whenever an SAP Basis admin got a call from the users saying that the performance of a specific program was slow. The Basis admin would load the SAP GUI, type in the STAD T-code, and after filling in a few filters to avoid being completely inundated by millions of events, they would see something like the following screen below: a limited view of overall response times.

From there, SAP Basis would traditionally drill-down into a suspect record to try to identify the possible culprit of the issue via an even narrower view of the data that shows component response times.

Then, the Basis admin might continue troubleshooting into the suspected infrastructure layers or pass the feedback to whichever team owned that subsystem and call it a day. Do you see how limiting that process is? Extremely frustrating! We are constrained into a path that takes us from the general to the granular in hopes of determining the specific issue – more on this in a bit.

Turning STAD on its head with Big Data

Now imagine this: what if we could enter the troubleshooting process from any point, not just the top? What if we were weren’t even interested in troubleshooting but needed to know what the aggregate user experience looked like? What if we wanted more? This is where the Big Data promise delivers. Using the STAD data made available in Splunk Enterprise via the PowerConnect add-on, this is all possible. I recently worked on a project where SAP Fiori was being used to make SAP apps accessible via web browsers on all types of devices, freeing it from the SAP GUI and VPN – so, basically accessing SAP via a web interface like you do with everything else these days. The challenge here was – this being a recent concept in SAP time – there was no practical way of doing any type of comprehensive Real User Monitoring… until you leverage STAD in Splunk Enterprise.

Leveraging STAD records in Splunk Enterprise allows you to bypass the constraints that limit STAD. For example, you can:

·      Analyze aggregated data going back years, not days.

·      Correlate & enrich with other data sources. Geolocation, anyone?

·      Ask any questions supported by the data and aggregate the results into visualizations.

·      Build custom analytics that allow you to drill up, down or side-to-side!

·      Plug the data into Machine Learning algorithms to gain new insights.

Leveraging some of these capabilities, I was able to deliver as a consultant with the Basis team actionable visualizations that provided the client with a view of how SAP apps are being consumed and aggregate it into trends. This customer solved an end user performance issue that had plagued them for three years. The Basis team had hero status at the quarterly team meeting as end-user performance issues were solved.

You can also split the performance metrics around geolocation, user types, applications and more to better understand how widespread a performance issue might be. This is also useful for the DevOps team as it allows them to compare performance and error rates across different versions of the apps.

That's it for now, but this is really just skimming the surface of what’s possible when splunking STAD.  Any use case around application response time, real user monitoring, or business processes where processing speed is a factor is ripe for capitalizing on the treasure trove of information that STAD contains.

What ideas or use cases do you have in mind for STAD data? Let us know!

About the author: Roman Lopez – rlopez@rhondos.com

“El Fuego” – as he insists on being called – has been helping customers innovate with Splunk since v4.3 but his focus these days are Splunk ITSI implementations for SAP.