Use SAP Cloud Application Lifecycle Management (CALM) System to Monitor Your SAP S/4HANA Cloud 3-System Landscape Systems – Part 2: Real User Monitoring
In my previous blog Use SAP Cloud Application Lifecycle Management (CALM) System to Monitor Your SAP S/4HANA Cloud 3-System Landscape Systems – Part 1: Setup, I detailed the steps to set up CALM for a 3-system landscape systems. It discussed the special handling of different errors which are usually not documented in SAP Help Portal documentations.
In this blog, I intend to discuss the usage of one of the CALM App Real User Monitoring, part of CALM for Operations.
What is Real User Monitoring
When discussing this topic, we should keep four key points in mind:
- The monitoring is from end user’s perspective, in terms of system performance. In other words, how the business user feels when they use the system.
- The being monitored systems only send technical performance data to the CALM (network performance, CPU, memory usage, response time, etc.). There is no business-related data (transactional and master data) sent to the CALM.
- Performance data collected are following types
- SAPUI5 or Fiori
- SAP Web Dynpro
- SAP GUI for HTML
- How real? How often the monitoring data is sent over is controlled by the Communication Arrangement I explained in Part 1 blog. It is usually set as 1 min.
Technology behind Real User and Performance Monitoring
The real user monitoring is from end user perspective, i.e., how the performance is measured on the end user browser. For example, the end user feels the system is slow today, and we can quantify that in Real User Monitoring. In addition, we can compare today’s performance with the past performance, or set up an alert if the performance trend goes to a wrong direction.
These being monitored systems can be individual ones, or a set of systems integrated together to perform one business scenario, such as Source to Pay when integrating SAP Ariba with SAP S/4HANA Cloud.
To achieve this, we deploy a so-called SAP Passport technology in this setup. SAP Passport is an end-to-end tracing technology. When an end user accesses SAP S/4HANA Cloud system via a desktop web browser, a Root Context ID is generated. This frontend action triggers a backend transaction which has its own Transaction ID. If the backend transaction triggers another transaction in its own system and/or a satellite system, there is another Transaction ID generated. Now we correlate all three ID’s (Root Context ID and Transaction ID’s) together to reflect an end user performance experience. Different end users run different transactions, there are different sets of IDs being correlated.
For the same action, such as a purchase order creation, the transaction types are fixed. We can keep a history of this type of transaction type set for the performance comparison purpose. Let’s say, if the average purchase order creation time is 0.5 sec, but one user experiences 2 sec; that indicates a poor performance, and an investigation is warranted.
Bells and Whistles of Real User Monitoring
Data Volume Limit and Data Retention Period
The CALM system provides 8 GB HANA DB memory to store all the data from the systems it monitors. The users can specify the duration of data retention. It is 7 days by default. Any data above the retention period will become part of aggregated data, used as benchmark to compare with the real time data.
If you use one single CALM system for many cloud-based and non-cloud-based systems, you can request more HANA DB memory with additional CALM subscriptions when you reach the 8 GB memory limit.
Real User Monitoring Scope Definition
Under the SAP Cloud ALM for Operations, launch Real User Monitoring Fiori App. First, let’s explain the initial screen after it has been setup.
As explained previously, we have a 3-System Landscape to monitor: Development Tenant (VOR-80), Configuration Tenant (VOR-100), Test Tenant (VP6-100) and Production Tenant (VP7-100). They are all included under my watchful eyes!
In the below figure, all four systems are included, registered as services. At the time of screenshot was taken, most of them are in green status.
Explanations of Top Menu Bar
There are many buttons/icons on the top menu bar. I am going to explain them one at a time.
Toggle Navigation Button
This button is located at the upper left corner (see above figure). By clicking this button, you can hide and unhide the texts of the left vertical view bar. After getting familiar with these views, hiding texts can save the valuable screen space.
By clicking this logo, it brings the screen back to Home View.
This button can change the frequency of refreshment, from 1 min to 10 min. By default, it refreshes at every 10 minutes or 600 seconds. The last refresh time marker is displayed on the right-hand side; for example, 1:27:09 PM in this screenshot. By selecting the Refresh option, it refreshes the data with the new time marker, but doesn’t reset the timer to start a new 600 sec cycle. Somehow the Refresh action and the Timer are not in sync.
Select A Scope
In the previous blog, I explained how to define a Service under Landscape Management Fiori App. This button lets you select which service(s) you will use to do Real User Monitoring.
In the figure below, I have six services defined and only four of them are selected to be monitored. If you have many services defined and they are more than one screen can display, the button Toggle Filter Bar can make selection work easier.
The Adapt Filters button is used to select what filter criteria you want to use.
Define a New Time Frame
This setting is very important. Why? Available data is displayed within a set time frame. If there is no data within the time frame, you will see “No Data” sign for that service. In the below figure, Except VP7-100, all other three services don’t have any monitoring data in Last 15 Minutes. It indicates no users are using the system in the past 15 minutes.
Another useful option is to define a time frame by yourself, for example, Last 5 Days and Last 2 Months. Clicking on Edit button will enable you to define a User-Defined time frame, and you can reuse it again and again.
Clicking on Custom Time Frame button, you can define a duration (time frame) of date only or date+time. For example, in the below figure, I define a new time frame from 15:00 of Dec. 1 to 21:00 of Dec. 2. This Custom Time Frame is applied immediately to your current viewing. The time frame itself is not saved like clicking on Edit button. It is an on-the-fly time frame.
This button controls two sections: Global Settings and Services/Systems. Both sections are in the right panel.
The Global Settings section
This section includes Data Volume (how much memory has been used to store the monitoring data), as well as data storage retention time. By default, the data retention time for single executions is 7 days, and for aggregated executions is 28 days. If you make changes to the data retention time, don’t forget to click on the Save button which is hard to see (grayed out) if you make no changes.
By clicking on the grid icon, a Memory Consumption per Service/System window pops up. It lists the memory consumption of each system being monitored. The first line item corresponds to tenant VOR-100. Since I have monitored this tenant for quite some time, it accumulates close to 3MB of monitoring data. In contrast, other three tenants have far less data.
If the system becomes idle during a long holiday, the old data will be aggregated and the total record number decreases. For example, on Nov. 10, VOR-100 has 3,616 records; On Nov. 15, it reduces to 2,729 records. Other systems show the same trend.
Note: The Percentage column reflects the percentage of record number of each tenant over the overall record number. It is not the Percentage of Memory Consumption.
The Services/Systems section
In my previous blog talking about Setup, we showed the status of each service. Let’s take VOR-80 as an example. Right after the service is defined in Fiori App Landscape Management, all capabilities show Not Configured status.
There are three possible statuses:
- Not Configured – The data feed has never been turned on (configured) from its initial setup in the Services/Systems
- Active – Data is constantly sent to enable this monitoring capability. This is achieved by clicking on the On button in the Services/Systems
- Inactive – Data is stopped sending to this monitoring capability, although it was turned on some time ago in the Services/Systems
Monitoring Data Views
Until now I explained all the bells and whistles to configure the Real User Monitoring App, located on the top menu bar. Now I am going to focus on reading the monitoring data through different views, located on the left menu bar. Please toggle the navigation icon on the left side of the SAP logo, so that all views are displayed with a text.
This is the first View to list all the systems in the monitoring scope. At present time, only VOR-100 has monitoring data. If you enlarge the time frame, you can get more data.
If you have many services on your list and want to make a few of them as your favorites, click on the star icon. For example, I want to make VOR-100 as my favorite. After clicking the star icon, I can approach it either by clicking on the Favorite Tab, or at the bottom of the Overview Tab.
I call Requests View the grandfather view of all other views in this Real User Monitoring App. As I explained previously, all the user monitoring is end user requests related. If there are no end user interactions through the web browser, there are no real user monitoring data.
You can also come to the Requests View by clicking on the Service (tenant) tile under the Home View.
The Requests View is composed of four layers of information:
- Request View – Performance overview of all selected services/systems. It lists all requests in the set time frame, and gives user an identification of single applications with poor performance or high usage.
- Request Details (selected action) – Focus on executed single requests
- Request Details (execution time) – Execution times of the focused request in a set time frame
- Request Flow – Analysis of the single request flow including all components involved in the execution
Now let me dig deeper into the Requests View.
In the below figure, there are two Fiori Apps show the red status at the top, F1492 and F4834. Let’s focus on F1492 – Maintain Business Roles.
The Request Overview tells us that in this time frame (9:12 – 10:12 am of 11/17/2022), there is only one execution, and it takes 26,287 milliseconds. By keeping drilldown three times to the Request Flow, we can see this Fiori App is associated with action F4834, which in turn launched four batch executions.
Let’s click on the request F1492 box, two icons show up. The top one is Expand/Collapse icon. The bottom one is the Node Details icon, and it lists all the information about this request. For example, it tells us
|Response Time [ms]||26,287|
|Net Time [ms]||1,177|
|OS Version||Windows 10|
|Browser Version||Chrome 106|
|Server Roundtrip Time [ms]||25,113|
|Root Context ID||C22C46A00BA7439AB09C613F5B722329|
The Response Time is the addition of Net Time and Server Roundtrip Time.
Now let’s click on one of the sub-actions with 43% sign. Its Node Details shows
The primary info listed are:
|Response Time [ms]||11,292|
|Net Time [ms]||11,292|
|Root Context ID||C22C46A00BA7439AB09C613F5B722329|
We talked about SAP Passport technology at the Introduction section. It links the frontend action ID with the backend transactions. Here the frontend ID is the Root Context ID, and each transaction has its own unique Transaction ID. By checking all four nodes on the right, you will notice they all share the same Connection ID, because they all belong to the node F1492 on the left.
After the first execution of F1492 – Maintain Business Roles, I executed a few more times of that App. Now you can see a different picture:
In the Request Overview, among six executions, four are red, one orange and one green. The average response time drops from previous 26,287 ms to 11,729 ms. Therefore, the trend is improving.
By drilldown one layer to the Request Details (selected actions), we can see all six actions and their status. The 2nd record/action is what we explored in detail previously.
The last record is associated with the action BusinessRolePageEditRole-button_press. Its subsequent actions are shown by further drilling down to the Request Flow layer.
In essence, the Requests View gives you the technical data of each frontend transaction and its related backend transactions. You have four layers of information to explore.
Note: Sometimes, if there is no action to the view for a long time, an error message Back-end request failed pops up when you click on any data or figure. Just close the error message, reload the page. It should solve the problem.
Similar as Requests View, the Analysis View focuses on requests as well, but in a different way. I especially like the Filter function to help narrowing down our search.
By adding Service Name (VOR-100), Request Types (SAPUI5), I can easily identify the F1492 – Maintain Business Roles action we analyzed previously. However, we cannot drilldown in this view unless going back to the Requests View.
You can also toggle to the graphical view instead of table view for easy comparison.
Frond End View
As the name suggests, this view shows the usage of the system by front end users. There are two sections:
- Front End – shows the number of executions and the time measurements
- OS & Browsers – shows the types of devices, operating systems and browsers used.
By default, data from all four tenants (VOR-80, VOR-100, VP6-100, VP7-100) are displayed. If we want to identify the usage of a particular tenant, or a user, we can filter the information using the filter function.
Another usage of the Front End View is to identify the executions in a set time frame. That helps to narrow down the executions we are interested in. By clicking the blue execution bar, it jumps to Requests View, with only executions we are interested being listed.
I accessed the system via my iPhone as well today. Now you can see the involvement of IOS16.1 and Sarafri 16.1 in the OS and Browsers section (below figure). It is an error to categorize my last-week updated Windows 11 laptop as Windows 15. We are more advanced than Microsoft 😊.
At the OS & Browsers section, when you click on any section in one of three pie charts, it jumps to Clients View which I will explain shortly.
Back End View
This View focuses on the backend response times. You should use the filter function to narrow your monitoring data exploration, like Services, users, etc.
Similar as the behavior in the Front End View, when you click on one of these blue execution related bars, it jumps back to Requests View. For example, I click on the tallest bar on the left, it jumps to the Requests View as shown in below figure. You can view this as a filter function to quickly narrow your exploration to the highest execution time, which might be all you are interested.
In the above figure, it lists many requests. That’s because we had a wide time frame containing close to 500 executions. If you reset the time frame to a smaller duration, you can see each individual execution. The below figure lists executions at one minute interval and you can easily identify which execution to focus on. For example, at 12:42, 12:43 and 13:00, only one execution each happened.
This View gives ratings on services/systems and request types. The below graph only shows SAPUI5, but if we have Web Dynro and Dialog, they will show up here as well.
If you click on any bar in the graph, it will jump back to Requests View, the grandfather of this entire monitoring tool.
This View tabulates unique users use the tenant(s) over the time frame you specify, in terms of operating system, browser, device type and last activity time stamp. Especially the Last Activity Time Stamp can be a good place to see who and when the user uses one of four systems. Unfortunately, you cannot see which system the user uses. You must set the filter with a specific system/service to check.
Execution Flow View
This view lists all the transactions a user executes. First thing first, you need to setup the filter:
- Time Frame – you can inherit the time frame specified for the entire Real User Monitoring App as I discussed previously, or you can specify a different set of time frame here from the pull-down list.
- User Name – it is tricky here. Although the example lists John Doe, I found it doesn’t work when I enter “George Yu”. I must enter my user ID CB9980000015 to get the results back.
- Root Context ID – the frontend user execution ID
- Services/Systems – specify which system(s) you are investigating
After applying the filter, I see the results. At that time, my primary transactions are in Fiori Launch Pad setup. When you click on any hyper link on the first column, it leads to Requests View.
Expensive Requests View
This is basically a heat map of all transactions, with red indicating long execution time, and green the short time.
By clicking one of the heatmap block, it leads you to Requests View, our grandfather view again.
HTTP Errors View
This view specializes in HTTP requests in terms of how many executions and its success rate.
When you click on the service hyper link, such as VOR-100, it drills down to all the requests within the service.
If you click on the request name hyper link, you guess where it leads you to: the Request View.
Add Custom Page View
Until now we used all standard views provided by SAP. If you want to create your own tailor-made views with a mix of SAP provided views, click on Add Custom Page. A new page is added.
At the beginning, you can see two areas in a newly created Custom Page. A third area called View Personalization will be added/displayed later after you drag a view into your custom page.
- Page Management
- View Management
- View Personalization (only appear after a view is pinned to the page)
First, ignore the Page Management but focus on the View Management. The reason is that until you create your own view, you cannot edit the Page Management, such as changing the Name. This should be improved in future CALM releases.
Using drag and drop function to pin the available views in the Custom Page, such as Status Overview, Services/Systems and Front End.
Then open the Page Management area. You can edit the Name of this Customer Page, add an icon and select the display option.
- Name: George’s Custom Page
- Icon: change sap-icon://user-edit to sap-icon://alert
- Display Option
- Default: stacking multiple views on top of each other
- Split: the window is split in left and right pieces. Left piece contains views you pined before selecting the Split option; Right piece contains views you pined after selecting the Split option.
- Use Grid Layout: you can arrange the views in 2×3 or 3×3 format.
After pining relevant views and changing the Page features, I can focus on View Personalization by clicking on the View Personalization icon next to the Filter icon.
The View Personalization area gives you the opportunities to move the icon to a different position, as well as setting the filters.
How to select an icon to represent your custom page?
By opening hyper link Icon Explorer, you arrive at SAP’s Icon Explorer. If you know the name of the icon, enter it into the search area. If you don’t, just click on the SAP Icons hyper link.
Here you can search the icon by categories or visuals. As soon as you select one of the icons, a new column appears on the right. In the case of icon Account, click the Copy button next to sap-icon://account. This is the text string you need to enter the Icon entry in the Page Management. As soon as you save the Custom Page, the icon appears next to the Custom Page.
In my example, I selected the icon “Alert”. My customized page is in the figure George’s Custom Page.
This blog is a little bit longer than what I planned to write, due to the rich features in this Real User Monitoring App. After initial setup using the top row menus, you will primarily focus on the views on the left vertical menus. Different views give you a different entry point to analyze the system performance. Ultimately, they will lead you back to the grandfather view, the Requests View.
In my next blog, I will discuss another CALM Fiori App Integration and Exception Monitoring.