Real User Monitoring
Real User Monitoring (RUM) provides permanent measurement of all real user requests within a system landscape covering performance as well as utilization aspects.
Real User Monitoring (RUM) provides permanent measurement of all real user requests within a system landscape covering performance as well as utilization aspects.
Real User Monitoring (RUM) is an application in SAP Focused Run. It provides permanent measurement of all real user requests within a system landscape covering performance as well as utilization aspects. For details of the User Interface, please check the RUM User Interface description.
Raise Alert per System – If multiple systems have been entered or LMDB Attributes for each system, a separate alert is raised.
Raise Alert per Request – If multiple requests have been entered or wild cards, a separate alert is raised for each matching request name.
SAPUI5 version in SAP Focused Run is developed and tested based on the underlying software components. It might happen when a higher version of the underlying component is applied (e.g. SAP_BASIS or SAP_UI) that some additional patches need to be applied.
Managed System Preparation
Starting with SAP Focused Run 1.00 SP03 the Administration of the Real User Monitoring application is now included in Monitoring UI itself. To reach the Administration area, please click the Configuration Icon in the upper right corner of the Real User Monitoring application and you can find the following categories:
In this area you can change the Global Threshold for Yellow and Red ratings in the application in relation to the request types like HTTPS, SAPUI5, RFC, HTTP, Dialog.
In this area you can check if the housekeeping job scheduled and when it has been executed the last time.
When Native Storage Extension(NSE) for Real User Monitoring is enabled you can set additionally the number of days how long data is kept in memory.
Systems
In this area it is possible to activate and deactivate certain systems from your scope.
Via the edit button you can manage the individual threshold settings for the different request types of the system. Via an Excel download/upload in the upper right corner it is also possible to simplify the maintenance of the threshold values.
With the groups it is possible to define new request types based on the basis types. The group can be based on data for specific systems, User Types, Requests, and Action. The groups can also be assigned an alert type. In order to display the groups you have to change the filter settings for the different views.
It is possible to create for technical request name a more meaningful user-friendly description which is then displayed in the monitoring. However, configuration and filtering must be done for the technical names.
The mapping can be downloaded, locally modified and uploaded again or also uploaded in another SAP Focused Run system e.g. production.
A default mapping for Fiori Application Ids can be uploaded from Request_Descriptions_Default_Fiori_S4_2024_09.xlsx
There are some settings possible which might be changed only after recommendation by SAP and which is not possible in the UI.
All settings are globally and are only effective after sending the configuration to the agents (either by a change in the RUM Ui e.g. changing a threshold or by executing SSI for a system).
Note: Do not delete or change any entries in the table that are not mentioned here!
Changing Collection Frequency
The default frequency how often the collectors are running on the agents is in FP00 5 minutes and with FP01 2 minutes.
If you want to change the collection frequency enter/change in SE16 in table /RUM/GLOBALCFG the entry
TYPE = COLLECTOR
PARAM = COLLECTION
VALUE = 120
The unit of the value is seconds.
Changing User Aggregation
Up to SAP Focused Run 2.0 FP01 by default the user name is also contained in the aggregated records. This is helpful if you want to check or search in the monitoring UI which actions one dedicated user has been executed. If you want to reduce the table size and you are not interested in the user names of the aggregated records you can switch it of. You can then add in SE16 the following entry in table /RUM/GLOBALCFG:
TYPE = COLLECTOR
PARAM = USER
VALUE =
Initial value removes the user from aggregated values, X keeps the user in the aggregated values.
Since SAP Focused Run 2.0 FP02 the default behavior is to remove the user names in aggregates. If you want to keep them set the value to X.
Changing Look Back Time
By default the agent tries to cover the last 24 hours of data from managed system. In case you want to change this value add in SE16 the following entry in table /RUM/GLOBALCFG. The unit of the value is hours.
TYPE = COLLECTOR
PARAM = LOOKBACK
VALUE = 48
Changing Default Thresholds
Each request type has default thresholds (in ms):
System Type | Request Typ | Green->Yellow | Yellow->Red | Aggregation | ||
---|---|---|---|---|---|---|
ABAP | 001 (Dialog) | 1500 | 3000 | 1000 | ||
ABAP | 101 (http) | 1500 | 3000 | 600 | ||
ABAP | 102 (https) | 1500 | 3000 | 600 | ||
ABAP | 251 (WS) | 1500 | 3000 | 600 | ||
ABAP | 254 (RFC) | 1000 | 3000 | 300 |
||
ABAP | 256 (SAPUI5) | 2000 | 4000 | 1000 | ||
JAVA | 101 (http) | 2000 | 6000 | 1000 | ||
JAVA | 102 (https) | 2000 | 6000 | 1000 | ||
JAVA | 251 (WS) | 1500 | 3000 | 600 | ||
HANADB | 101 (http) | 2000 | 6000 | 600 | ||
HANADB | 256 (SAPUI5) | 2000 | 6000 | 1000 |
||
EXT_SRV | 101 (http) | 2000 | 6000 | 300 |
||
EXT_SRV | 102 (https) | 2000 | 6000 | 300 | ||
EXT_SRV | 256 (SAPUI5) | 2000 | 6000 | 1000 |
Default Thresholds:
Default thresholds can be changed by entering the values with SE16 into table /RUM/FILTERCFG.
The values are in ms and should not be set too low.
The value for Aggregation defines if a request is put into an aggregation bucket or kept as single request. This value must be lower than the value for Green→Yellow.
The Default values are only taken into account when a new system is added in RUM configuration. Existing configured system are not touched.
Since SAP Focused Run 1.0 FP02 it is possible to create alerts and automatic notifications for RUM. There are two types of alerts available which can be displayed in the Alert Inbox by selecting Monitoring Use Case = Real User Monitoring in Scope Selector:
To be notified when a collector is stopped or not working anymore (e.g. user is locked, password changed, connection issue,..) you can schedule the report /RUM/SELFMON_ALERTS_TRIGGER as a background job.
It should be scheduled for user FRN_BTC_RUM and it is sufficient to run every 60 minutes.
In the variant you can specify if the report should be executed only for one (customer) network and a notification variant if you want to get notified by e-mail for example when the collector do not send anymore data.
You can specify for each self defined group if you want to get notified for unusual behavior. These Alert types are available
The calculation is triggered by the job /RUM/ALERT_CALCULATION which is scheduled when executing the report /RUM/SETUP.
No, it has no impact on the end user performance.
No, RUM does not need any additional software to be installed on the end users device.
Prerequisites for managing and Managed Systems are listed in the Prerequisites Section.
Several RFC server requests can be processed in one dialog step and are therefore written into one statistical record. If this is the case the CPU and DB time cannot be assigned to a single RFC call.
Real User Monitoring is able to monitor and correlate synchronous requests triggered by end users. As soon as there is an asynchronous step the request flow cannot be correlated completely.
Some components which do not forward the SAP Passport (like ABAP Proxy, XI runtime) also break the request flow and outgoing requests might not be mapped to the incoming request.
Requests of type SAPUI5/Frontend have some measured values that are different from other request types.
These are:
Response time is the elapsed end-user time measured in the browser.
Net Time is the time spend by the application in the browser. It is approximately the difference between the Response Time and the Round Trip Time influenced by the accuracy of the measurement. See also in the picture below.
In the deepest level of the Request Overview the correlated requests are displayed with some details. Most of the fields should be self explaining. The others are described below.
Response Time: Elapsed time or gross time for that request in that component
Net Time: Net time spent in that component = Gross time minus time for outgoing requests
Wait Time: Time in the component for example to get a resource (Lock, work process,..)
Memory: Consumption of this request in this component
Net Time Percentage: Percentage of the net time spent in the component compared to the response time of the root node of the graph
Transaction ID: SAP Passport field; Identifier of request
Connection ID: SAP Passport field;Identifier of a connection between two components
Connection Counter: SAP Passport field; Counter of used connection
Pre Component ID: SAP Passport field; Previous Component ID
The application needs a scope selection to display any data. You can manage several combinations of system IDs, types, live cycle or network names. These settings can be persisted as queries, made public (to be used by other users) and set as default.
The following steps describe this in detail.
The application needs a scope selection to display any data but there several direct jump-ins possible when the scope is provided by url parameters.
Overview Page:
Use the path ?jumpto=overview to start the application with required parameter &lmdbid=<LMDB ID of system>
Example: /sap/bc/ui5_ui5/rum/e2erum/index.html?jumpto=overview&lmdbid=FA163E4CC4F01EE68CC7030173AFFB7D
As an alternative this url path is also working ?extsid=<Extended SID>&type=ABAP&lmdbid=<LMDB ID of system>
Request overview:
Use the path ?jumpto=requests to start the application with required parameter &lmdbid=<LMDB ID of system>
Optional parameters for filtering are:
users= User Names(comma separated)
requesttypes= (numerical) Request Types (comma separated)
requestnames= Request Names (comma separated)
Example: /sap/bc/ui5_ui5/rum/e2erum/index.html?jumpto=requests&lmdbid=<LMDBID1>,<LMDBID2>,<LMDBID3>&users=i*,c12345&requesttypes=101,102&requestnames=/sap/bc/*,*Component
Execution Flow:
Use the path ?jumpto=requests to start the application with required parameters &lmdbid=<LMDB ID of system> and &user=
Optional parameters are:
STARTTIMESTAMP= Start time stamp in format <YYYYMMDDhhmmss>
ENDTIMESTAMP=
Example: /sap/bc/ui5_ui5/rum/e2erum/index.html?jumpto=execFlow&STARTTIMESTAMP=20230710093144&ENDTIMESTAMP=20230710103144&lmdbid=<LMDBID1>,<LMDBID2>,<LMDBID3>&user=FRN_ASM_ADM
Custom Page:
For a custom page that is shared by the ID which contains a fixed scope selection a dummy lmdbid can be added to avoid opening the standard scope selector.
Example: ?pageId=<page ID>&pageName=<page name>&lmdbid=dummy