Tag: SAP Focused RUn

SAP Focused Run real user monitoring (RUM) overview

This blog will explain the technical activation and usage of RUM (real user monitoring) in SAP Focused Run.

Basic activation of RUM

First go to the Fiori settings tile:

If the RUM function is not active yet, activate it and Save:

Now go to the FRUN backend ABAP system and start transaction STC01 and select task list SAP_FRUN_SETUP_USECASE and variant SAP&FRUN_AUM (advanced user monitoring):

In the task list setup also select the batch jobs:

Now run the task list. This should not take longer than 1 minute. Result green is ok:

Technical activation of RUM per managed system

Per system for which you want to activate the RUM function proceed as follows:

Go to the SSI Fiori tile:

Select the system:

Now press the Configure manually button and new screen opens:

On top first select Step 2 for Execute configuration. And select the Configure Real user monitoring step. Press the Execute Selected button and wait for the log to show success:

Alternatively you can also do the SSI completely new on the first screen by selecting the Configure Automatically button.

Background: RUM is an intense function. If it is not active, the agent does not have to do anything. The re-do of the SSI is needed to tell the agent on the system to start sending RUM data once it is activated in FRUN configuration.

With this step the managed system is prepared.

Functionality activation of RUM per managed system

Now we can go to the RUM Fiori tile:

After scope selection nothing is active yet:

On top right choose the Configuration button and start with the housekeeping settings:

WARNING: RUM can use a lot of data in your database. It can also consume a lot of your Focused Run licensing. If you use too much; reduce amount of systems for which you activate RUM and reduce the retention periods in the screen above. See blog on Focused Run license measurement.

Go to the Systems section and toggle the Activation for the system to On:

Wait for the configuration and data collection to happen. Take 5 to 10 minutes patience for this step.

After the step, refresh the screen and it should look like this:

Data should appear on the left. On top, select the icon Data Quality. This shows the data collection status per host. The icon will be red at start and turn green after 30 minutes.

Using Real User Monitoring: request tool

Now the setup is done, we can start to use the tool. The main screen is the requests tool:

From the start screen you can zoom into the task type you are interested in. As example we zoom in to the task type Dialog:

Drill down all the way:

Here you can see for which user and when the action was done. Unfortunately the action description is pretty technical: action 2000 in transaction CJ8G still might leave you a bit puzzled.

Using Real User Monitoring: cards tool

The second tool is the cards tool:

Here the entry point is the task type or trend in card format.

Using Real User Monitoring: front end tool

The front end tool gives an overview of front end response times and on clients used on your system:

Using Real User Monitoring: back end tool

The back end tool gives an overview of the back end performance and distribution of the response times:

Using Real User Monitoring: hot request tool

The hot request tool gives a cross section for high usage and performance.

If a part is used more, the block size is larger. In this caser, zooming in on the less used red part might be useful. But is it also interesting to analyze the large used orange blocks, since a lot of users are impacted.

Using Real User Monitoring: 24 hour profile

The 24 hour profile tool can be used to see if there are hours of the day where performance is worse than others. Some might be expected. But also: you might want to put in extra capacity to deal with peak loads. Or schedule some intense batch jobs at different times.

Using Real User Monitoring: topology

The topology tool can help you to analyze where data flow to and from your system are running and with which performance quality:

Using Real User Monitoring: execution flow

In some cases a specific user is complaining about poor performance. You can use the execution flow tool to filter on a specific user ID. After opening the tool, press the filter button to detail the user ID:

More tools

RUM has many more tools. Just explore the menu on the left side if another tool is useful for your situation.

Creating a Custom Metric to Check SAPRouter SNC Certificate Expiry

This metric and script checks the SAPRouter SNC certificate expiry and gives an alert depending on how many days left until expiry.

Define SAProuter in Focused Run LMDB

Prerequisite: Make sure you have installed the SAP Host Agent and performed Outside Discovery on the SAPRouter host.

Go to the LMDB of you Focused Run system, then go to Single Customer Network:

Switch Namespace and go to “Technical Systems” and choose “Unspecific Standalone Application System” from the drop-down, then hit Create.

Enter:

Enter the Extended SID:

Add Software Component Version:

Search on the software, and then select the correct release, then Add. E.g.:

Save

Add Installation Path and Required LMDB Attributes. NOTE: Find out the relevant software installation path of the SAPRouter on the server.

Perform Simple System Integration.

Configure Script and Custom SAPHostCtrl Operation

Prerequisite: The script requires the SAPRouter SNC Certificate to be properly installed, and the PSE credentials in the cred_v2 file for the account that runs the SAPRouter service.

A script is scheduled to run daily as the same user that runs the SAPRouter service. The script reads the expiry date of the from the PSE and writes it to a file in JSON format so that the FRUN metric can read and interpret it. The script by default has SAPRouter home directory as /usr/sap/saprouter or <drive>:\usr\sap\saprouter, and it can be changed. This will be denoted as <SAPROUTER_HOME>. The PSE file variable can also be changed.

Linux/Unix

Create a new executable file in the SAPRouter home directory and copy the code in Appendix A. Ensure it is owned and executable by the user that runs the SAPRouter service and belongs to group sapsys. E.g.,

chown <saprouter user>:sapsys saprouter_expiry_days.sh
chmod 744 saprouter_expiry_days.sh

In the script, adjust the following variables:

  • SAPROUTER_HOME
  • SECUDIR (The SECUDIR folder is where the PSE file resides)
  • SAPROUTER_USER
  • PSE

Test the Script. Switch to the user that runs the SAPRouter service, then execute the script:

/usr/sap/saprouter/saprouter_expiry_days.sh

Look for file NUMDAYS.json. It should contain e.g.:

{type:integer, name:NumDays, value:136}

Schedule script in the root crontab as follows:

# Run SAProuter SNC Certificate expiry check
00 09 * * * su - <saprouter user> -c /usr/sap/saprouter/saprouter_expiry_days.sh

Windows

Create a batch file (*.bat) in the SAPRouter home directory. In the script, adjust the following variables:

  • SAPROUTER_HOME
  • SECUDIR (The SECUDIR folder is where the PSE file resides)
  • PSE

Test the Script. Logon as the user that runs the SAPRouter service. Right-click on the bat script and “run as Administrator”. Alternatively, if you are not logged as the SAPRouter service account, you can “run-as” the user that runs the SAPRouter service and execute the script that way.

runas /user:<domain or hostname>\<SAPRouter service user> <SAPROUTER_HOME>\saprouter_expiry_days.bat

NOTE: The SAPRouter service user requires “Allow log on locally” user rights.

Look for file NUMDAYS.json. It should contain e.g.:

{type:integer, name:NumDays, value:136}

Schedule the Script. Open a command prompt as administrator. Execute the command:

SCHTASKS /CREATE /RU <DOMAIN>\<saprouter user> /RP <password> /SC DAILY /TN "Run SAPRouter SNC Certificate expiry check" /TR "C:\Windows\System32\cmd.exe /C \"<SAPROUTER_HOME>\saprouter_expiry_days.bat\"" /ST 09:00 /RL HIGHEST

Note: The start time e.g., 09:00 is in 24 hour format. You should see:

Run the new task to test it:

SCHTASKS /RUN /TN "Run SAPRouter SNC Certificate expiry check"

You should see:

Check the timestamp of the file NUMDAYS.json.

Create Custom Operation for saphostctrl

To load these values into Focused Run, a custom operation for saphostctrl needs to be created.

Linux/Unix

As Root: Create the following custom operations conf file:

/usr/sap/hostctrl/exe/operations.d/checksnccert.conf

Enter the following into the conf file:

Command: cat /usr/sap/saprouter/NUMDAYS.json
Description: Check number of days to SNC certificate expiry
ResultConverter: flat
Platform: Unix

Test the custom operation as follows:

/usr/sap/hostctrl/exe/saphostctrl -function ExecuteOperation -name checksnccert

Result should be:

Webmethod returned successfully
Operation ID: 06C635D6863A1EEDB6BC5C819EE199D7

----- Response data ----
description=Check number of days to SNC certificate expiry
{type:integer, name:NumDays, value:169}
exitcode=0

Windows

Create the following custom operations conf file:

C:\Program Files\SAP\hostctrl\exe\operations.d\checksnccert.conf

Enter the following into the conf file:

Command: FOR /F "tokens=* delims=" %x in (<SAPROUTER_HOME>\NUMDAYS.json) DO @echo %x
Description: Check number of days to SNC certificate expiry
ResultConverter: flat
Platform: Windows

In a Command Prompt as Administrator, test the custom operation as follows:

"C:\Program Files\SAP\hostctrl\exe\saphostctrl" -function ExecuteOperation -name checksnccert

Result should be:

Webmethod returned successfully
Operation ID: 00155D657F901EEDBCF9E32BC564F964

----- Response data ----
description=Check number of days to SNC certificate expiry
{type:integer, name:NumDays, value:360}
exitcode=0

Create Custom Alert in Focused Run

Create a new monitoring template for SAPRouter here:

Enter into Expert Mode. Create a new Alert with the following settings:

NOTE: If the tick box “Do not Group Individual Occurrences” is ticked, it will alert at each data collection regardless of its previous rating, and not only at a change of rating.

Create Custom Metric In Focused Run

Create a new Metric with the following settings:

Data Collection

All parameters of the Data Collector which are fixed should have the “Configure” box unticked, and the common parameters pre-filled with the correct values.

The “Custom Operation” parameter is the saphostctrl operation “checksnccert” created earlier. The “Metric Name” parameter is the name of the metric in the JSON output file produced by the script, which is “NumDays”.

Threshold

The threshold picks up the integer as returned by the script; if it falls to below or equals 10 days, then raise a yellow alert, if below or equals 5 days, then raise a red alert. Choose whatever threshold values suit you.

Assignment

Assign the Metric to the Alert:

Activate the Alert

Apply SAPRouter Template and Check Monitoring

TIP: Initially set the collection interval to 5 minutes and apply template to see whether it is collecting data. Then you can set the collection interval back to daily.

You should see this in the Monitoring Application:

Appendix A: saprouter_expiry_days.sh

#!/bin/bash
# Outputs the expiry date of the SNC Certificate and calculates the number of days
# If the number of days falls below threshold, it sends an alert
# Written by Tony Swietochowski

SAPROUTER_USER=saprouter
SAPROUTER_HOME=/usr/sap/saprouter
SECUDIR=$SAPROUTER_HOME/sec
PSE=local.pse
HOSTNAME=$(hostname -f)

# Check  for saprouter user
[[ ! "$USER"=="$SAPROUTER_USER" ]] && echo "This script must be run using the $SAPROUTER_USER user. Exiting." && exit 1

EXPIRYDATE=$(${SAPROUTER_HOME}/sapgenpse get_my_name -p $PSE -n validity 2>&1 | grep NotAfter | awk -F\( '{print$2}' | cut -c -6)
NUMDAYS=$(echo $(( ($(echo $(date --date="$EXPIRYDATE" +%s) - $(date -d $(date +%y%m%d) +%s)) )/86400 )))
# Above method based on https://stackoverflow.com/questions/4946785/how-to-find-the-difference-in-days-between-two-dates

echo $NUMDAYS > $SAPROUTER_HOME/NUMDAYS
echo \{type:integer, name:NumDays, value:$NUMDAYS\} > $SAPROUTER_HOME/NUMDAYS.json

Appendix B: saprouter_expiry_days.bat

@echo off

REM Outputs the expiry date of the SNC Certificate and calculates the number of days
REM If the number of days falls below threshold, it sends an alert
REM Written by Tony Swietochowski

set SAPROUTER_HOME=D:\usr\sap\saprouter
set SECUDIR=%SAPROUTER_HOME%\sec
set SNC_LIB=%SECUDIR%\sapcrypto.dll
set PSE=local.pse

for /f "tokens=2 delims=\" %%i in ('whoami') do set THISUSER=%%i
FOR /F "tokens=* USEBACKQ" %%F IN (`hostname`) DO (SET HOSTNAME=%%F)

chdir /d %SAPROUTER_HOME%

for /f "tokens=2 delims=(" %%a in ('%SAPROUTER_HOME%\sapgenpse.exe get_my_name -p %PSE% -n validity ^2^>^&^1 ^| findstr /l "NotAfter"') do set DATESTRING=(%%a

set expiry_year=20%DATESTRING:~1,2%
set expiry_month=%DATESTRING:~3,2%
set expiry_day=%DATESTRING:~5,2%

set current_year=%date:~-4%
set current_month=%date:~4,2%
set current_day=%date:~7,2%

set "from=%current_month%-%current_day%-%current_year%"
set "to=%expiry_month%-%expiry_day%-%expiry_year%"
echo Wscript.Echo DateDiff("d", "%from%", "%to%") > %TEMP%\tmp.vbs

for /f %%a in ('cscript /nologo %TEMP%\tmp.vbs') do set /a "numdays=%%a"

del %TEMP%\tmp.vbs

echo Number of days to SAPRouter certificate expiry: %numdays% > %SAPROUTER_HOME%\NUMDAYS.log
echo {type:integer, name:NumDays, value:%numdays%} > %SAPROUTER_HOME%\NUMDAYS.json

<< This blog was originally posted on SAP Focused Run Guru by Tony Swietochowski (DXC). Repost done with permission. >>

Statistical records in SAP Focused Run

Focused Run has functions to fetch ST03N data from ABAP backend systems and use the data for analysis in SAP Focused Run System Analysis functions.

System analysis SSI activation

First step is to switch on the general functions for system analysis during SSI activation. Full help link from SAP can be found here.

In Focused Run start SM30 for table RCA_SSI_CONF and add entry for activation:

Repeat SSI

For the system that you want to have ST03N data collected, you need to repeat the SSI.

Check the detailed step in the SSI for the Statistical records aggregation:

Activate per system in System Analysis

Next step is to activate it per system in System Analysis:

Go to the settings per system and make sure Performance (aggregated statistical records) is activated:

Overview of all systems

In System Analysis, go to the bottom left tool section to open the Aggregation Configuration tool:

The overview page opens:

Now you can see both configuration and data collection is ok.

Using statistical records

Go to the System Analysis tile and select the scope:

On the left side menu switch to the ABAP performance view:

In the new view in the ABAP frontend workload, push expand the screen button:

Now you get a list of all transactions. To make it simple we filter on EntryID (in this case we filter on ME to search for the procurement transactions):

Top right, there is the download to xls button. This is a very useful tool! In XLS you can post process the data.

You can also filter and sort on other elements like amount of executions.

To get a trend, click on the trend graph, in this example the trend for ME23N transaction:

Raw table data

If you have a specific query that is not met with the out-of-the-box reports, you can use SE16 on the Focused Run backend for table STATDBUSERTCODE. In this table the raw data is stored.

<< This blog was originally posted on SAP Focused Run Guru by Frank Umans. Repost done with permission. >>

SAP Focused Run OCC dashboard

OCC dashboards are the most flexible form of dashboarding in SAP Focused Run. It is completely up to you to define any dashboard based on the available data.

The explanation below will give a quick introduction on how to setup a dashboard with as example a line graph with CPU for one system and amount of short dumps per hour for that system in a bar chart.

Set up new dashboard

Start the OCC dashboard Fiori tile:

Click the add a new dashboard icon on the left:

Now open on the right hand side icon the personalization. Here you can change the default 2 by 1 layout if want as well:

Now per gadget, select the personalization. First choose the type of graph, then select the query details:

Add the query by clicking the Plus sign:

Give the legend a name and press the Change query button:

First select the data source. In this example we choose system monitoring. Select next your system, and select the metric (in this case CPU). Don’t forget to save on top of the personalization!

We repeat for the other gadget, but now select short dumps per last hour as example:

Test your dashboard to see if the results are according to your expectation.

Make dashboard public

If you are happy with your dashboard, you can make it public. To do so, go to the personalization options:

Set the selected page to public, select a proper icon, and rename the default user-edit to a proper name and don’t forget to Save.

Other users can now add you dashboard from their UI personalization menu by clicking the Add Public Page and add your dashboard:

ABAP short dump trend analysis

We can use SAP Focused Run OCC Dashboards to build a ABAP Dump Trend Analysis dashboard.

Using OCC Dashboard we can use the data provider for System Monitoring to pull the data of Short Dumps per day metric in to a trend chart.

In the OCC Dashboard app you can create a new dashboard page by clicking on Add Custom Page in the navigation panel.

By default your new page will be named as custom_page, you can rename your page by clicking on Rename in the settings section and then providing a new name.

In the View Management section of the settings area you can modify the grid layout. By default you have 2 columns in 1 row. In this example we will change to 1 X 1 to keep just the ABAP Dump Trend Analysis dashboard. (Note: we can add a dashboard to each grid in the layout).

Now for adding the dashboard to the pane we just created, we click on the settings button for that pane.

Then in settings area, under View Personalization –> Render we select the graph type. In this case we want to perform a trend chart so we select Line Chart.

Now we need to create a query for the chart that would provide the data for our graph. For this in the Query section we click on the + sign to add a query.

Now in the Query Section, for the newly added row you provide a name under Legend and then click on the change button to start editing the query.

In the Query Editor screen select the data provider System Monitoring.

Now we navigate to the Scope Selection tab to select the managed systems for which the dashboard should display data. In this example we selected System Type as Application Server ABAP and IT Admin role as Production to select all ABAP production systems.

Now in the Default tab , under Extended SID select any ABAP system and then under Metrics tab select the metric Number of Short Dumps (Today). Click on Apply button to activate the selection.

Now you can see the ABAP Dumps trend lines for the selected scope of managed systems in the graph.

Note: By default a graph for System Monitoring data provider will select Auto resolution of data which will show the data for today with hourly frequency.

You can change the resolution in the Time Range Section in the Settings area. For example here we set Period for last 30 days as “l30d” and Granularity for every day or daily as “d”.

Note: OCC Dashboard graphs will always average out the data as per the granularity set for the graph w.r.t actual collection frequency of the selected metric. For instance if the metric Number of Short dumps (Today) has a hourly frequency and we show the daily data in the graph, then the value shown in the graph will be average of all hourly data collected by the metric for that day, which will of course be different from the actual final daily count. Hence to ensure data shown on graph is accurate, ensure that the Number of Short Dumps (Today) metric has a daily frequency. Then the granularity of the graph and the metric data collection frequency being exactly same, both will have the exact same and accurate data.

To know more abut OCC Dashboards and all possibilities with it you can refer to SAP Documentation here.

<< This blog was originally posted on SAP Focused Run Guru by Frank Umans and Manas Tripathy (Simac). Repost done with permission. >>

SAP Focused Run certificate expiry monitoring

SAP Focused Run can be used to monitor expiry of a lot of different type of certificates:

  • ABAP PSE certificates (read below)
  • Host agent PSE certificates (read below)
  • SSL certificates (see this blog)
  • Cloud Connector BTP certificate expiry (read below)
  • SNC certificate expiry (read below)
  • SNC expiry in SAP router

ABAP PSE certificate monitoring

In system monitoring you can monitor if ABAP system certificates are expiring or are already expired. SAP provides a standard metric for this based on configuration validation rule SAP ABAP PSE CERTIFICATES CHECK. This rule is taking all certificates that are to be expired in the next 7 days and all expired certificates.

This rule has two setbacks:

  • 7 days upfront warning might be too short
  • It reports all expired certificates that are already years expired and don’t harm the system

New rule for ABAP PSE certificate monitoring

For the improved setup we will defined 2 new rules:

  • To be expired certificates, with date selection -30 till tomorrow
  • Expired certificates, with date selection today till next 30 days.

Start with creating the policy in configuration validation (more on configuration validation in this blog):

Add a new policy Z_ABAP_PSE_TO_BE_EXP for the to be expired, and give it this syntax:

Add a new policy Z_ABAP_PSE_EXP for the expired ones:

Both are basically a copy of the standard SAP one with the changed dates.

Please note you need to change both the dates in the Compliant and Non-Compliant section.

Create custom metric

Now you can create a custom metric using the newly created rule. For full description on how to create custom metrics, read this blog. Create the custom metric in the ABAP system template:

Refer to the newly create custom CoVa (configuration validation) rule:

And set the threshold:

For the to be expired certificates, we only want warning.

We repeat the same for the expired certificates, but now we make it a red alert by setting the thresholds differently.

Make sure both are now activated for monitoring:

Trouble shooting

There might be false alerts raised for this metric. This is for both the custom and standard SAP metric. The source is usually the data collection.

SAP note 3138046 – False Alert ABAP PSE certificates expiring in Focused Run describes the checks to perform.

Go to the configuration and configuration validation FIORI tile and select the system and search for the PSE certificates data collection details:

Monitoring Host Agent PSE Certificate Expiry

You have configured SSL for enabling secure connections to SAP Host Agent. In such a case you need to regularly update or extend the validity of the SAP Host Agent PSE certificate. With Focused run System Monitoring you can create custom metric for monitoring SAP Host Agent PSE certificate expiry.

Setup Monitoring Host Agent PSE Certificate Expiry

Step1: Navigate to Host Template maintenance

SAP Host Agent resides at OS level of each host of systems that you are monitoring using Focused Run. Hence you need to monitor the PSE certificate for SAP Host Agents of each host in your customer network.

In our recent blog we have explained how you can configure URL Certificate monitoring in Health Monitoring in SAP Focused Run. However configuring certificate monitoring for each SAP Host Agent in your customer network using Health Monitoring will be very cumbersome.

An easier way will be to setup a custom metric in the host level system monitoring template which when activated will be automatically applied to all hosts for which the monitoring template is used.

For template maintenance you can navigate to System Monitoring Template Maintenance app on the Focused Run launch pad.

In the template maintenance app navigate down to the Host (Server) node and then to the respective template which you want to edit and click on Edit button.

Step2: Create Custom Metric

In order to create a custom metric you need to activate expert mode. For this click on the Expert Mode button as shown below.

After enabling expert mode you can click on Create button. Select Metric in the drop down from Create button.

In the Metric creation pane, under Overview tab enter the details as shown below.

Then in the Data Collection tab, provide the details as shown below.

For the URL field you need to mention the URL https://$SAP_ComputerSystem.FQDName$:1129/SAPHostControl/?wsdl in which the expression $SAP_ComputerSystem.FQDName$ will dynamically resolve the respective FQDN of the host picked up from LMDB. Hence it is important to select the check box under Placeholder and select LMDB under Placeholder type.

Then navigate to the Threshold tab and provide the threshold as shown below. In this example the threshold is Yellow if certificate is expiring in 30 days and Red if its expiring in 15 days.

Then click on Next button to navigate to the Assignment tab where we assign this metric to an existing alert. In this step just click on the Finish button to save the metric. In this step we don’t assign to any alerts yet as we are yet to create a custom alert for this custom metric.

Step3: Create custom Alert and assign to custom Metric

In the expert mode maintenance go to the Create button and then from the drop down select Alert.

Enter the details as shown below and click on Next button.

Then in the Assignments tab you will see the custom metric you just created. Select the check box for this metric and click on Finish to save the alert.

Now your custom metric is ready together with alerting active.

To activate this template update on all hosts navigate to Managed Objects tab for the template and click on Apply and Activate button.

Upon activation the new metric will be available in system monitoring as shown below.

For more details on how to setup SSL for SAP Host Agent you can refer to the SAP documentation here.

SNC certificate expiry monitoring

SNC Certificate expiry is very critical for ABAP systems where SNC logon is used. As soon as the certificate expires users will no more be able to login to system.

In System Monitoring for ABAP systems SAP provides a standard metric called Expiring PSE Certificates which monitors all PSE certificates that includes SNC certificates. When this metric turns red it will tell how many certificates are expiring/expired but not which one. Hence its beneficial to monitor separately the status of SNC Certificates.

This monitoring can be achieved by using Configuration Validation.

You can create a custom policy with the below XML code that checks the PSE_CERT store to check on status of SNC Certificate.

<?xml version="1.0" encoding="utf-8"?>
<targetsystem desc="SNC Certificate about to expire" id="ASML_SNCERT_TOBE_EXP" multisql="Yes" version="0000">
  <configstore name="PSE_CERT" system_type="ABAP">
    <checkitem desc="Valid in range" id="1" operator="">
      <compliant>APPLICATION like '%SNCS%' and CONTEXT like '%' and TYPE like '%' and SUBJECT like '%sapci%' and ISSUER like '%' and SERIALNO like '%' and VALID_FROM like '%' and ( ( ( replace_regexpr ('^$' IN valid_to WITH (replace(current_date, '-', '')||replace(current_time, ':', '')))) &gt; to_number(replace(add_days(current_date, 30), '-', '')||replace(current_time, ':', '') ))
or (( replace_regexpr ('^$' IN valid_to WITH (replace(current_date, '-', '')||replace(current_time, ':', '')))) &lt; to_number(replace(add_days(current_date, 0), '-', '')||replace(current_time, ':', '') )) )</compliant>
      <noncompliant>APPLICATION like '%SNCS%' and CONTEXT like '%' and TYPE like '%' and SUBJECT like '%sapci%' and ISSUER like '%' and SERIALNO like '%' and VALID_FROM like '%' and not ( ( ( replace_regexpr ('^$' IN valid_to WITH (replace(current_date, '-', '')||replace(current_time, ':', '')))) &gt; to_number(replace(add_days(current_date, 30), '-', '')||replace(current_time, ':', '') ))
or (( replace_regexpr ('^$' IN valid_to WITH (replace(current_date, '-', '')||replace(current_time, ':', '')))) &lt; to_number(replace(add_days(current_date, 0), '-', '')||replace(current_time, ':', '') )) )</noncompliant>
    </checkitem>
  </configstore>
</targetsystem>

Note: In the above XML code, SUBJECT like ‘%sapci%’, you have to replace sapci with a hostname pattern that you use for all your SAP ABAP system hostnames.

Once you have created the policy, you can directly activate alerting on the policy.

For that go to the Configuration and Security Analytics app in the Advanced Configuration Monitoring area.

In the app navigate to Configuration Validation Alert Management under the the Related links tab.

In the Alert Management app click on Create button to create the alerting for the policy you just created.

In the next popup, enter details as shown below and then click on Select policy to select the policy for which you want to activate the alert.

In the next popup select the policy by clicking on the policy name.

Now click on Save to activate the alerting.

Additionally you can also activate email notification on the alert. For this in the Alert Management main screen, select the alert and then click on Notification/Outbound.

In the next popup select the notification variant and save.

Cloud Connector BTP certificate expiry

With SAP Focused Run 3.0 FP 2 SAP has delivered a configuration validation policy using which you can monitor Cloud Connector BTP Certificate expiry.

Note: For using this functionality you just have to ensure that you have registered your cloud connector managed system to your Focused Run System and have performed SSI for the cloud connector managed system.

You can do the monitoring via the Configuration & Security Analytics app in the Advanced Configuration Monitoring area of Focused Run Launchpad.

In the app click on the select button to select the policy to monitor Cloud Connector BTP Certificates.

In the pop-up you can search for SCC and then select the policy SAP_SCC_PSE_CERT. This is the standard policy delivered by SAP that performs configuration validation on Cloud Connector BTP Certificate expiry.

This policy monitors if a BTP certificate in cloud connector system is going to expire in less than 30 days or is already expired.

The first view upon selecting the policy is the Systems view. In this view all SAP Cloud Connector systems registered in Focused Run system are listed. A systems is marked as non compliant if it has any certificate which is going to expire in less than 30 days or has any expired certificates. This view also tells how many certificates are there in the system and how many are non compliant.

You can click on the row to see the details of the certificates which are expiring or expired.

To know more about Configuration and Security Analytics you can refer here.

Also you can find more detail at SAP documentation here.

<< This blog was originally posted on SAP Focused Run Guru by Manas Tripathy (Simac) and Frank Umans. Repost done with permission. >>

SAP Focused Run interface monitoring overview

The integration and cloud monitoring function of SAP Focused Run consists of 2 main functions:

  • Interface monitoring between SAP systems
  • Cloud monitoring between on premise and cloud SAP products (see blog)

This blog will give an overview of the interface monitoring between SAP systems.

Questions that will be answered in this blog are:

  • How does the interface monitoring in SAP Focused Run look like?
  • How much details and history can I see in SAP Focused Run interface monitoring?
  • How can I enable my systems for interface monitoring?
  • How do I set up a scenario to monitor?
  • How do I setup alerting for an interface scenario?
  • How do I setup Idoc monitoring?
  • How do I setup ODATA monitoring?
  • How do I setup qRFC monitoring?
  • How do I setup webservice monitoring?
  • How do I setup RFC monitoring?
  • How do I setup SLT monitoring?

Interface monitoring

To start the interface monitoring click on the Fiori tile:

In the next screen you now select one or multiple integration scenario’s:

Then you reach the scenario overview screen:

You can immediately see with the red colored scenario’s that there is an issue.

Click on the red scenario to open the details of the scenario topology:

The topology indicates most of the interfaces are correct. To see the detailed issue, click on the red line:

Click on the red error for the details:

On the right side of the you can click on the Dashboard icon to get an historical overview:

Link with alert management

Interface errors can be the trigger for an alert in the Alert Management function.

Technical scenario setup

e concept for interface monitoring is unfortunately a bit confusing at first.

There are 2 main things to remember:

  1. Systems data collection and alerting: this is where the action happens
  2. Graphical representation: this is where you make it visible

Unfortunately this means you have to do lot of double work.

Set up systems

Go to the Integration and cloud monitoring Fiori tile. On top right click on the configuration icon to change or add a scenario:

First add the systems:

Select the system:

Select the configuration categories:

Select the monitoring:

Here you must add the connections you want to monitor.

The alerting configuration is empty initially:

We will fill this later if we want alerts for a specific interface connection.

Save this system and repeat for the rest of the systems.

The system determines the actual data collection and actual alerting. The system can be re-used in multiple scenarios.

Scenario configuration

On the configuration screen now add the new scenario. Add a name and description for the scenario:

In the topology screen now add the systems in the drop down for Node Selection and use the + icon to add them to the screen:

Now select the source system (we will have 1 CUA central and 2 child systems) and select the Action box:

Select Add link to and then select the system.

Now add a filter to the link by clicking on the line:

In the dialog screen on the right now add the details:

Start by giving the group a name. Now add the filter. Give the filter a name (in this case RFC1). Select the central component and the category (in this case Connection monitoring SM59). Now add the RFC connection type (3) and connection name to be monitored.

Very important here: press Ok first to transfer the data. Only then press Save. Otherwise your data is lost. SAP UI is not ok for this area.

Repeat for the second scenario. The end result is that the dotted lines are replaced by straight lines:

Then Save.

The scenario is active now:

Reminder: you did have to add the same information in the system level as well in the Technical System as well: this will perform the data collection itself. If this is not done, then the scenario overview will show grey results for missing data collection.

The scenario is used to make the interfaces graphically visible.

Adding alert

When you have monitored the scenario long enough to see it is stable, the next step is to setup alerting so you get notified in the central alert inbox.

First add the alert in the Technical System as shown above. This will be the actual alert definition.

To add an alert to the graphical overview, go to the scenario definition and select the source system. Press the button alerts for component:

On the right hand side now add the alert by clicking the + button:

Then select the wanted Alert Category. And select the filter options. Add the connections for which you want to alert:

Give the filter also a name.

On the Description field you can set the alert to active:

You can also set the frequency of checking, and if an notification is to be send as well (via mail or towards outbound connector).

Also important here: first press Ok, then Save. Otherwise the data is lost.

Set up Summary and final check

After you have finished the graphical topology, you need to go back to the Systems overview to validate if everything is activated ok for both monitoring and alerting:

Reminder: there is a split in graphical representation in the topology and scenarios and the actual system monitoring and alerting in the Technical System overview.

Interfaces that can be monitored

Full list of interfaces that can be monitored is published on the Focused Run expert portal.

Specific interface monitoring topics are explained below:

  • Idoc monitoring
  • ODATA Gateway monitoring
  • qRFC monitoring
  • RFC monitoring
  • SLT monitoring
  • Web Service monitoring

Idoc monitoring

SAP Focused Run can both report on idoc errors and delays in idoc processing. Delay in idoc processing can cause business impact and is sometimes hard to detect, since the idocs are in status 30 for outbound, or 64 for inbound, but are not processed. SAP Focused Run is one of the only tools I know which can alert on delays of idoc processing.

The monitoring starts with the Integration & Cloud monitoring tile. Then select the modelled idoc scenario (modeling is explained later in this blog):

On the alert ticker you can already see there are alerts for both idocs in error, but also alerts for idocs in delay:

In the main overview screen click on the interface line to get the overview of idocs sent:

You can now see the amount of idocs that were sent successfully, which are still in transit and which ones are in error. Click on the number to zoom in:

Click on the red error bar to zoom in further to the numbers:

Click on the idoc number to get further details:

Unfortunately, you cannot jump from SAP Focused Run into the managed system where the idoc error occurred.

Documents monitor for idocs

A different view on the idocs can be done using the documents monitor. You can select the documents monitor tool on the left side of the screen:

Now you goto the overview:

You can click on the blue numbers to dive into the details. Or you can click the Dashboards icon top right of the card to go into the dashboard mode:

This will show you the summary over time and per message type. Clicking on the bars will again bring you to the details.

Data collection and alerting setup for idoc monitoring

In the configuration for interface monitoring in the Technical System settings, goto the monitoring part and activate the data collection for Idoc monitoring:

In the monitoring filter, you can restrict the data collection to certain idoc types, receivers, senders, etc. Or leave all entries blank to check every idoc:

The graphical modelling for idocs is similar to the explanation of the example above.

Alerting for idoc errors

First alert we set up is the alert for errors.

Create a new alert and select the alert for idocs in status ERROR for longer than N minutes:

Now we add the filter. In our case we filter on outbound idocs of type DESADV:

A bit hidden at the bottom of this screen is the setting for the N for the minutes:

The time setting is depending on your technical setup of idoc reprocessing jobs (see for example this blog), and the urgency of the idocs for your business.

In the description tab add the notification variant in case you want next to the FRUN alert also mail to be sent (setup is explained in this blog).

You can set up multiple alerts. This means you can have different notification groups for different message types, different directions, different receiving parties.

Save the filter and make sure it is activated.

Idoc alert for backlog

Next to alerting on errors, Focused Run can also alert on delay of idocs. This can be done for both inbound and outbound idocs.

To set up an alert for backlog choose the option idocs in status BACKLOG for longer than N minutes:

In the filter tab set the idoc filter and at the bottom fill out the value for N minutes of backlog that should be alerted:

And in the final tab set the notification variant if wanted:

Save the filter and make sure it is activated.

Definition of delayed and error idocs

On the SAP Focused Run expert portal on idocs, there is this definition of the determination of idocs in delay and error:

Data clean up idoc monitoring

If you get too much data for idoc monitoring, apply OSS note 3241688 – Category wise table cleanup report (IDOC, PI). This note delivers program /IMA/TABLE_CLEANUP_REPORT for clean up.

ODATA gateway monitoring

We assume in this use case that end users are using the ODATA in FIORI apps. In case ODATA is consumed by external applications like Tibco, Mulesoft, Mendix, etc., you have to replace USER with the corresponding application.

Model end users in LMDB

Before we can start the scenario modelling, we first need to model the end users in LMDB as a Unspecific Standalone Application System), just like we did for TIBCO in this blog.

Name the ‘system’ USER:

Make sure the status is Active.

Add this new system USER to the Technical System list in the Integration Monitoring setup.

The system will be display only.

Data collection and alerting setup for ODATA interfaces

In the configuration for interface monitoring in the Technical System settings, goto the monitoring part and activate the data collection for Gateway Errors:

In the monitoring settings, you can filter on specific items if wanted, or leave everything blank to report on any error:

In the tab alerting setup the alerting:

The filter for monitoring and alerting can be different. It cloud be you want to monitor all errors, but only activate specific important ones.

Save your monitoring data collection and alerting settings.

Graphical modelling of ODATA interfaces

In the graphical modelling add the backend system and the system created for USER:

Now add the link starting with USER towards the backend system:

Save your changes.

Also here: first scroll down to see the OK button. Press first OK before pressing Save, or you might loose the data and have to re-enter it. This it bit annoying in the UI.
Monitoring usage of ODATA interfacing

The end result in operations looks as follows:

In the graphical overview click on the red line. The screen with the exceptions opens. Click on the red number to see the overview:

Here you can see the trends and zoom into the specific errors:

qRFC monitoring

qRFC connections are frequently used in communication from ECC to EWM and SCM systems. For generic tips and tricks for qRFC handling, read this blog.

OSS notes for bug fixing qRFC monitoring

Please make sure bug fix OSS note 3014667 – Wrong parameter for QRFC alerts is applied before starting with qRFC monitoring.

Other OSS notes:

Data collection and alerting setup for qRFC monitoring

In the configuration for interface monitoring in the Technical System settings, goto the monitoring part and activate the data collection for qRFC Errors:

In the monitoring settings, you can filter on specific queues, direction and RFC name, or leave everything blank to report on everything:

In the alerting part check you can choose between age of qRFC entries and number of entries:

And set the filters for which ones, and the metric threshold for CRITICAL errors:

The filter for monitoring and alerting can be different. It could be you want to monitor all errors, but only activate specific important ones.

Save your monitoring data collection and alerting settings.

Queued RFC’s are normally back and forth between 2 systems. If this is the case you have to make the settings for both systems.

Graphical modelling of qRFC interfaces

In the graphical modelling add the filter between two systems for the qRFC monitoring:

Also here: first scroll down to see the OK button. Press first OK before pressing Save, or you might loose the data and have to re-enter it. This it bit annoying in the UI.

Queued RFC’s are normally back and forth between 2 systems. If this is the case you have to make the settings for both systems. You model first one direction and then model the direction back:

Monitoring qRFC usage

The end result in operations looks as follows:

You can see here qRFC is modelled back and forth between 2 systems. The blue line indicates messages in process. The red line is clicked on. Here you can see both messages in process and errors. Click on the red error number gives the details:

Monitoring RFC’s between SAP systems

RFC’s with fixed user ID

See the example above on CUA idoc monitoring.

Trusted RFC’s

If you have to setup an RFC monitoring for a trusted RFC (for example between Netweaver Gateway system and ECC system), then you have to take care of the user ID’s and rights. The system from which the SM59 test will run, will use that Focused Run user ID to log on to the other system. If your user ID’s are unique for each system you have to create the user ID in the other systems with the rights to be able to execute a ping and logon for the test.

End result RFC checks

The end results of the RFC is list of RFC’s with the latency time, availability and logon test overview:

Transactional RFC towards external system

To monitor transactional RFC (type T) towards an external system like TIBCO, Mulesoft, etc, you first need to model the external system in the LMDB. To do this goto the LMDB maintenance Fiori app:

Then select Single Customer Network and select the option Technical Systems. In this section choose the Type Unspecific Standalone Application System:

And press Create:

Fill out the details and Save. Make sure the status is Active.

Now the system can be added in the configuration of technical systems in the Interface monitoring configuration:

Now you can model the tRFC interface connection monitoring:

OSS notes for RFC monitoring

Relevant OSS notes:

SLT integration monitoring

This blog focuses specifically on SLT integration monitoring. Monitoring an SLT system itself is explained in this dedicated blog.

Set up SLT integration scenario

Start the integration and exception monitoring FIORI tile:

On the configuration add the SLT system:

Select SLT as specific scenario:

On the Monitoring part you can filter on a specific source system and/or SLT schema:

On the 3rd tab you can set the Alerting in cases of errors:

Now save and activate. The monitoring is active now.

Next step is to use this system in a model for your scenario:

Using the SLT integration monitor

If you open the Fiori tile and you have selected your scenario, you still need to perform an extra click to go to the SLT monitor:

First you get overview of your system(s):

You need to click on the blue numbers to drill down:

This gives overview of errors, source connection status and target connection status.

You cannot drill down further on this tile. If you see an error, you need to go to your SLT server and start transaction LTRO to see all detailed error and start fixing from there. Transaction LTRO can have errors shown that are not visible in transaction LTRC. Focused Run uses LTRO data.

Web service monitoring

Web services monitoring automates the monitoring in transaction SRT_MONI, which is extensively explained in this blog.

This monitoring does not check the connection availability of the web service. To make that happen, you would need to install a custom program from this blog, that writes an entry to SM21. From the SM21 entry, you can create a custom monitoring metric that alerts on the connection issue. How to setup custom metrics is explained in this blog.

SAP reference for web service monitoring can be found here.

Data collection and alerting setup for web service monitoring

In the configuration for interface monitoring in the Technical System settings, goto the monitoring part and activate the data collection for Web Service Errors:

In the monitoring settings, you can filter on specific criteria, or leave everything blank to report on everything:

In the alerting part check you can choose between amount of entries and number of error entries:

And set the filters for the alerting:

The filter for monitoring and alerting can be different. It could be you want to monitor all errors, but only activate specific important ones.

Save your monitoring data collection and alerting settings.

Graphical modelling of web services monitoring

In the graphical modelling add the filter between two systems for the web service monitoring:

Also here: first scroll down to see the OK button. Press first OK before pressing Save, or you might loose the data and have to re-enter it. This it bit annoying in the UI.
Monitoring usage of web services

The end result looks as follows:

You can click on the errors or success messages and zoom all the way down to individual messages:

<< This blog was originally posted on SAP Focused Run Guru by Frank Umans. Repost done with permission. >>