Introducing Real User Monitoring

As the person responsible for technical support at Dreams without Limits, Scott knows from experience that it can be difficult to identify the root cause or bottleneck of performance issues. This is particularly true when running cross-system business processes: At Dreams without Limits, the Hire to Retire process involves systems and cloud services, such as SAP SuccessFactors, SAP S/4HANA Cloud and SAP Master Data Integration. Scott also knows that users often experience a different runtime for their requests compared to what IT support can measure inside single components, as network times or front end times are often hard to measure.

In one of his next regular meetings with Carl, Scott asks Carl how SAP Cloud ALM for operations can help him to tackle this issue.

Carl states that SAP Cloud ALM offers Real User Monitoring. He continues that the purpose of Real User Monitoring is to provide transparency about the usage (that is: executions) and the performance (that is: response times) of user interactions. This is achieved by performing measurements at both the front end and the server side to identify the actual root cause of performance issues. Using SAP Passport technology then allows for the correlation of monitoring data measured at the front end, in the cloud service, and/or at the system side, to analyze end-to-end user request flows.

Scott is excited and wants to learn more about this. He therefore asks Carl to go into more detail.

Carl states that with SAP Cloud ALM there's no need to install any agents on the SAP systems or on the front end.

Then he starts explaining the process flow in detail:

• Whenever a user is triggering a request, the (for example: http) data stream is enriched with an SAP Passport. This SAP Passport is then part of every communication between the different SAP systems involved and the user.

  Note

  SAP Passport in this context is a correlation mechanism that uniquely correlates performance data from several technical components to one end-to-end request.

• When the request is processed by an SAP system (for example, an SAP Gateway system), the system can read the information from SAP Passport and can locally store information and can add additional information during the execution of the request.

  Hint

  Examples for locally stored information are the time stamp, or the unique ID from SAP Passport. Examples for additional information are statistical records, or which system is called next.

  Note

  In the case of SAP S/4HANA Cloud Public Edition, the SAP Passport is used as well and information from the execution of the request can be retrieved via APIs and Web Services.

• Both the passport information and the performance relevant information are frequently collected from the SAP systems and from the cloud services. The information is sent to SAP Cloud ALM using either software component ST-A/PI (for on-premise systems) or Web Services and API (for cloud systems).
• With the help of SAP Passport technology, within SAP Cloud ALM the data can be correlated from the single request to the complete request execution flow. SAP Cloud ALM can also aggregate the data, which allows to make them available for a longer period and to show historical data in the Real User Management User Interface (UI). This UI data can be useful for Scott as an IT Analyst to find the root cause of a specific performance issue the user has experienced. From the data, Scott and Anna (acting as system administrator after the go-live) can also analyze which steps of the requests are executed on which technical component.

Scott is excited and makes a note that he needs to talk to Anna soon. But he wants to get some examples of how Real User Monitoring can be used at Dreams without Limits.

Carl explains a usage scenario for Real User Monitoring:

1. Scott can use the Overview page to identify services or request types with poor performance. For this, this page offers an overview of the performance metrics for the services that are in scope by using the Apdex (Application Performance Index).
2. Then Scott may switch to the Requests view to identify the single applications with poor performance or high usage.
3. From there, he may switch to the request details to identify the time frame where the single requests have been executed with poor performance.

4. Finally, Scott can enter the request flow to perform an analysis of the single request flow including all components that are involved in the execution.

   

Carl continues that, in addition, the Frontend Overview and the Backend Overview contain the most important front end (or back end) usage and performance metrics:

He ends with the remark that Scott can also use the Services/Systems view to view the status of different request types grouped by services and systems to identify entities that show poor performance.