Author: Frank Umans

Working in SAP since 1998. Started as ABAP developer and later moved to SAP basis and authorizations. Since 2020 working with SAP Focused Run.

Cloud monitoring: CPI message monitoring…

SAP Focused Run Cloud Monitoring can be used to monitor messages to and from the SAP BTP CPI solution. CPI stands for Cloud Platform Integeration.

Questions that will be answered in this blog are:

  • How to monitor message to and from SAP CPI?
  • How to setup the monitoring towards SAP CPI?

End result of monitoring

The configuration of the scenario is described in the next chapter. We start explaining the end result.

Click on the tile for integration and cloud monitoring:

Select the scenario and the overview tile appears:

Click on the card to go to the scenario topology:

Zoom into the overview screen of the errors:

And drill down to any specific error:

Set up of the CPI monitoring scenario

Follow the steps from the SAP expert portal for CPI monitoring to setup the STRUST in SAP Focused Run for the CPI URL.

Validate in the SAP Focused Run ABAP stack that these two parameters are set in RZ11:

  • icm/HTTPS/client_sni_enabled = TRUE
  • ssl/client_sni_enabled = TRUE

If this is done, go to the cloud setup FIORI tile:

Add a new end point for CPI:

The application key, client ID and client secret will need to be provided by the basis person or functional consultant maintaining the CPI interface configurations on the BTP cloud. Depending on the security setup, a proxy is required as well.

After entering the details check the connection that connectivity is working as expected.

Now go to the configuration of the interface scenario and create a new cloud service for Cloud Platform Integration:

On the monitoring screen specify filters for specific IFlows if requiered:

On the alerting tab you can set up any alerting wanted:

Set the filter for alerting (in this case all failed flows):

Assign alert receivers and make sure everything is saved and activated.

Now you can model the scenario graphically as well:

Cloud monitoring: alert notification from BTP…

The BTP platform has a function called Alert Notification. This is a generic function that can be used to send alerts. It can be used to send alerts from applications, but also to send alerts from the HANA Cloud database.

SAP Focused Run can pick up these alert notifications form the BTP platform. From there Focused Run can be used to further relay the alert to notification teams.

End result of alert notification from BTP

Go to the Cloud monitoring FIORI tile:

Select the configured scenario (explanation of the setup is in the next chapter):

In this case we have setup the alert notification for HANA Cloud. Click on the card tile for details, and click on the interface line:

Now select the errors and the overview screen opens:

Click on a single line to go to the specific error details:

Setup of the scenario

First you need to prepare your BTP environment to allow SAP Focused Run to collect data from the Alert Management application from your tenant and subaccount. This will give you the URL, client ID and client secret (be careful this is only shown once). To do this, follow the steps on the SAP Focused Run expert portal in this link.

For the setup of the scenario in SAP Focused Run, go to the FIORI tile for cloud setup:

Set up the OAUTH end point:

After the setup save the details and test the connection.

Now this end point can be used in the scenario setup.

In the Scenario configuration create the Cloud Service and select the SAP Cloud Platform Alert Notification Service:

In the monitoring details set the Endpoint you just created and filter on the events:

In the third tab Alerting you can set up the alerts if wanted.

Save and activate.

In the scenario modelling you can now use an on premise system and the Cloud Service you set up above to model a graphical scenario:

Cloud monitoring: Ariba…

SAP Focused Run Cloud Monitoring can be used to monitor messages to and from the Ariba solution.

Questions that will be answered in this blog are:

  • How to monitor message to and from SAP Ariba?
  • How to setup the monitoring towards SAP Ariba?

End result of monitoring

The configuration of the scenario is described in the next chapter. We start explaining the end result.

Click on the tile for integration and cloud monitoring:

Select the scenario and the overview tile appears:

Click on the card to go to the scenario topology:

Click on the red line to zoom into the communication error details:

Click on the message to zoom into the details:

Set up of the Ariba monitoring scenario

Follow the steps from the SAP expert portal for Ariba monitoring to setup the STRUST in SAP Focused Run for the Ariba URL.

Validate in the SAP Focused Run ABAP stack that these two parameters are set in RZ11:

  • icm/HTTPS/client_sni_enabled = TRUE
  • ssl/client_sni_enabled = TRUE

If this is done, go to the cloud setup FIORI tile:

Add a new end point for Ariba:

The application key, client ID and client secret will need to be provided by the basis person or functional consultant maintaining the Ariba interface configurations on the Ariba cloud. Depending on the security setup, a proxy is required as well.

After entering the details check the connection:

Now go to the configuration of the interface scenario and create a new cloud service for Ariba Network Transaction:

On the Monitoring tab connect to the end point create above and set the wanted filters:

If you want, you can also set up alerting in the third tab.

Save and activate the setup.

Now you can model the scenario graphically as well:

Interface monitoring: Idoc monitoring…

The generic interface monitoring setup in SAP Focused Run is explained in this blog. This blog will zoom into monitoring of Idocs.

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 who 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

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

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:

Alerting for 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.

Alerting 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.

Determination 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:

Graphical modelling

The graphical modelling of idoc monitoring is identical in principle as with RFC and qRFC. You can read the set up in these two blogs: qRFC and RFC modelling.

Data clean up

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.

Security & configuration validation check for client 001 and 066 existence…

Security & configuration validation can be used to check for the existence of clients 001 and 066.

The 066 early watch client and old delivery clients 001 are only security risks (unless in rare cases 001 has been chosen as execution client). Best to delete them from security point of view (see reference blog).

Setting up security and configuration validation rule to check for existence of clients 001 and 066

Go to the security and configuration validation policy tile:

Create a new policy with the following syntax:

<?xml version="1.0" encoding="utf-8"?>
<targetsystem xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" desc="Test CLIENTS Store" id="TEST_CLIENTS" multisql="Yes" version="0000" xsi:schemaLocation="csa_policy.xsd">
  <configstore name="CLIENTS">
    <checkitem desc="CLIENTS_CHECK" id="1.0.0.0">
      <compliant>MANDT = '000' or MANDT = '010' or MANDT = '100'        </compliant>
      <noncompliant> MANDT = '001' or MANDT = '066' </noncompliant>
    </checkitem>
  </configstore>
</targetsystem>

In the compliant section add more clients that are valid and/or change the numbers to your own situation.

Basically the rule says: 000 and main client(s) listed are compliant. 001 and 066 are not compliant.

Running the check


Run the check will give you all existing 001 and 066 clients as incompliant items:

IT Calendar access for Non-SAP Focused Run Users…

The work mode management function is use to maintenance. During the maintenance the alerts are suppressed. The same information can also be made generally available to serve as a IT calendar for all interested persons. This can be people for the IT department and the business. These users are mainly interested in planned downtime of the IT systems.

Use of the IT calendar for non-SAP focused run users

After the setup each person can now use this URL:

https://<host>:<port>/sap/bc/ui5_ui5/sap/itcal_external/index.html? FILTER_VARIANT=<public_variant-name>&sap-client=<client>

End result looks like this:

Setup of IT calendar access for non-SAP focused run users

The basic steps are described in OSS note 2926433 – IT Calendar access to Non-SAP Focused Run Users.

Create a system user with copy of role SAP_FRN_APP_ITC role and update it with the UI5 application “itcal_external”(IWSG and IWSV).

Also add these 4 not documented authorizations:

Display for service availability management:

Display for work modes:

Add generic services:

Add filter bar rights:

Activate these 2 SICF services:

  • /default_host/sap/bc/bsp/sap/itcal_external
  • /default_host/sap/bc/ui5_ui5/sap/itcal_external

On the Logon tab of these 2 services set the user ID and password of the newly created system user.

Do the same for the external system alias /sap/itcalnonsolman (also in SICF transaction): also here set the user ID and password for the newly created system user.

After settings are done, execute testing. Most issues are coming from lack of auhtorizations.

OSS notes

Relevant OSS notes:

Performance analysis in System Analysis…

In the system analysis function there is a special function to monitor system performance based on ST03 system data from the managed system.

This blog will explain how to setup and use this data.

Performance analysis

Start on the System Analysis tile:

Now choose the menu option for ABAP performance:

The performance overview will now open:

You can click on many items now to get to the details.

Setup of Performance Analysis

Before the above works, the click on the settings wheel and click on the Configure Collection of ABAP performance data:

Make sure the system you need analysis data from is activated correctly.

If the data collection is not ok, check the Collector Status button and Agent logs. Also check the backend system user used to see if this user has sufficient authorization to fetch the required data.

Service Availability Management…

Since SAP Focused Run is measuring availability issues, it can also be used to manage the figures you need for service availability management:

  • Uptime of the system
  • Planned and unplanned downtime of the system

All service availability management functions are present using this FIORI tile:

On the left hand side there is the menu with all options:

Service availability management definitions

There are 2 definitions we need to configure:

  1. The outage customization
  2. Service availability definitions

First we start with the outage customizing:

Make the required settings for planned and unplanned downtime.

Now you add a new service management definition:

Provide a name and validity date for the definition and use the + symbol to add systems for which the definition is relevant.

In the tab availability set the SLA threshold for the availability percentage:

If relevant you can set specific contractual maintenance time in the last tab:

Example of use for this tab: you are running your SAP system hosted on for example AWS or Azure. Those platforms can have scheduled maintenance as well. That is not in your control.

Carefully check your entries and definition before saving. They cannot easily be changed later!

You cannot delete an active definition. To make it inactive you need to change the end date of the definition to today, and then delete it next day.

Each system can only be in one SLA definition!

Classifying the outages

On the Outages overview you can see the outages. The outages can be 0, or there can be open and/or confirmed outages:

Click on the open alert to classify it (click once for the line, click on the line for the details):

Classify the outage (planned/unplanned) and set the status. Fill out the text to clarify. And then save the update.

Outage reporting

There are 2 main reports. The uptime and outage reporting. The uptime reporting shows how long your system is up since the last reported planned or unplanned downtime. This overview is not so useful.

The useful overview is the outage reporting which shows you the downtime per system and per month:

In the example above 1 system had outage, but that was short enough to still meet the SLA target. Availability was 99.64% versus SLA target over 99.5%.

System monitoring custom metric for errors in table locking of TBTCO…

From availability perspective, you want to detect as quickly as possible if you are suffering from locking errors of table TBTCO. TBTCO table is used for printing. If the locking error situation occurs the printing function will fail, and even worse, it can impact the complete SAP ABAP system.

You can create a custom monitoring metric to measure and act on this.

Creation of the custom metric for errors in table locking of TBTCO

Create a custom metric following the steps in this blog. The template to be adjusted is the technical instance SAP ABAP 7.10 and higher template.

Don’t forget to tick it on for monitoring otherwise it is not active.

In expert mode create a custom metric.

Create technical name Z_METRIC_ERR_LOCK_TBTCO:

In the data collection:

Data to enter: RFC on diagnostics agent (push). Select ABAP System Log Stats. Filter on message text *TBTCO*. This captures severe errors for TBTCO like the locking error.

Define the threshold for alerting:

And assign the metric to the ABAP Instance not available alert group:

System monitoring custom metric for message server disconnects…

From availability perspective, you want to detect as quickly as possible if you are suffering from message server disconnects.

You can create a custom monitoring metric to measure and act on this.

Creation of the custom metric for message server disconnects

Create a custom metric following the steps in this blog. The template to be adjusted is the technical instance SAP ABAP 7.10 and higher template.

Don’t forget to tick it on for monitoring otherwise it is not active.

In expert mode create a custom metric.

Create technical name Z_MESSAGE_SERVER_DISCONNECT:

In the data collection:

Data to enter: RFC on diagnostics agent (push). Select ABAP System Log Stats. Filter on message number Q0L, Q0M and Q0N. Any of those indicate message server errors. For more information on system log messages, read this blog.

Define the threshold for alerting:

And assign the metric to the ABAP Instance not available alert group: