Upgrading SAP Focused Run

All new functions and innovations for SAP Focused Run are delivered in either upgrades or feature packs. This blog will explain how to plan and execute upgrade for SAP Focused Run.

Questions that will be answered in this blog are:

  • What is the SAP Focused Run release strategy?
  • How to prepare for the SAP Focused Run upgrade?
  • How do I execute the SAP Focused Run upgrade?

Release strategy of SAP Focused Run

In the SAP Focused Run overview document created by SAP there is one slide containing the SAP Focused Run release strategy:

All new functions and innovations are delivered in either upgrades or feature packs.

Preparations for SAP Focused Run upgrade

First look up the specific upgrade OSS note. In case of upgrade to Focused Run 4.0 SP02 these are OSS notes SAP Note 3374888: Focused Run 4.0 FP02 and 3394504 – SAP Focused Run 4.0 Feature Pack 02 – Update Preparation and Postprocessing Documentation.

In this note you will find:

  • HANA database version needed
  • Needed versions of the SDA (simple diagnostics agent)
  • Scenario specific pre and post actions required
  • Updates to authorizations in SAP Focused Run
  • Updates to authorizations in the connected systems
  • Pre upgrade and post upgrade actions to be performed

The HANA database can be upgraded before the actual upgrade or can be combined with the upgrade. The same applies for the SDA agent.

Best practice is to execute the HANA and SDA upgrades before. Upgrade your Focused Run test system first, leave the versions there for a few weeks to prove stability, then deploy on productive Focused Run system.

In case of changes to authorizations in the connected systems, you can already update these before the upgrade.

In case you use custom descriptions in the metrics, you must download them before the upgrade and upload them again after the upgrade. More information in OSS note 3077162 – Backup and Restore of MAI Custom description BEFORE and AFTER system Update/Upgrade.

ZDO upgrade option

As of Focused Run 3.0 you have the choice to go for a ZDO (Zero Downtime Option) upgrade to reduce the downtime of the upgrade.

Read the following notes carefully before deciding to go for this option:

Executing the SAP Focused Run upgrade

Start your upgrade first on your SAP Focused Run development system and write down all the steps you execute. You will need to repeat all steps in your productive system later on.

During the technical upgrade, you will have to perform with the SUM tool, you will need to execute the SPDD and SPAU technical upgrade actions. Store the actions in transport to be used in productive upgrade. After SPUA is done, also apply the updated collective notes listed in the central note 3374888 – Release Information Note for SAP Focused Run 4.0 FP02.

After the technical upgrade has been completed, follow and document carefully all the steps in the OSS upgrade note. For example running extra tasks lists, programs, redo SSI for JAVA, etc.

It can also be you come across items and issues that are not documented in the OSS note. Please write them down in your own runbook for production. When upgrading to SAP Focused Run 3.0 we found that the standard jobs are switched to the technical job repository SJOBREPO (since the 3.0 ABAP stack is based on the S4HANA 1909 version).

Apply all collective notes for all functions you are using. The collective note numbers are listed in the Release Information Note.

After the documented steps, update the authorizations in SAP Focused Run to get the new tiles for new functions available.

Rerun the task lists for the initial setup in STC01 (SAP_FRUN_SETUP_FOUNDATION and SAP_FRUN_SETUP_USECASE) with the variants of the use cases that you are using.

Update the monitoring content according to OSS note 2991255 – Manual content update for FRUN-CONT 300 in SAP Focused Run (FRUN-CONT). For the steps in detail, read this blog.

Check in the upgrade manual if any SSI needs to be redone. This is often the case with JAVA systems.

Finally when all actions are done, refresh your browser cache and backend FIORI cache (follow all steps from this blog).

Testing

Before deploying the Focused Run upgrade in production, you must test all your functions in the Focused Run development system. It is very helpful if you have a set of documented test cases that you can easily repeat each upgrade. With testing first focus on testing the current functions you are using. In a later stage you can explore, activate and test new functions.

While testing you will find issues. Solutions are normally:

  • Updates in authorizations
  • OSS notes to be applied
  • SICF services and Gateway services activation
  • Forgotten step in the activation

Capture all fixes in either transports or in your runbook.

If you still have key issues with bugs, you will need to raise a message to SAP.

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

SAP Focused Run guided procedures

SAP Focused Run has offer guided procedures guide and automate tasks

Questions that will be answered in this blog are:

  • How to run the guided procedure for ABAP health check?
  • When to run the guided procedure for ABAP health check?

Running the ABAP health check guided procedure

The goal of the ABAP health check guided procedure is to structurally check the health of an ABAP system.

To start the guided procedure for system health check, open the Guided Procedures Fiori tile:

Now select from the guided procedure for advanced system monitoring the System health check for ABAP systems:

Select the Plus icon to execute a new guided procedure:

Add the scope of systems to the guided procedure:

Then press the Execute Manually button to start.

The guided road map will now open:

Select the checks and press Perform to execute the checks. After the checks are done, you can zoom in the detailed results:

The next checks are shown below:

When to run this ABAP system health check guided procedure?

he ABAP system health check guided procedure can be run:

  1. In case of reported system issues with performance: to quickly find potential root cause
  2. For example monthly or quarterly to check how system is doing

You can also automate the guided procedure and run it on scheduled basis and mail the results to you. This you can for example setup for your primary ECC production system on daily basis.

Automated scheduling of health checks including mail sending

SAP Focused Run provides a mechanism to periodically schedule automatic execution of guided procedures. With this you can optionally enable email notification. This way we can schedule periodic run of System Health Check guided procedure. From each automatic execution of the guided procedure, an email will be sent with the status of the system health check.

Scheduling Guided Procedures

In the Guided Procedures app navigation block click on Guided Procedure Planning.

In the Guided Procedure Planning area, click on the “+” sign to create a new Plan and follow the steps to create a plan.

Step 1: Select guided procedure System Health Check for ABAP Systems.

Step 2: Scope Selection: Select the systems (Ext. System ID) for which you want to run the system health check.

Step 3: Processing Parameters: Select for one time execution or periodic execution.

Step 4: Notification Settings: In this step provide the following details for setting up the email layout for sending the email notification for the guided procedure execution result.

  1. Email Customization (Optional) : Select either of the two options available for this field. With this selection we use the pre-built/inbuilt SAP eMail template provided by SAP.
  2. To: Provide the Recipient List to which you want to send the mail to (You can’t provide direct mail IDs here).
  3. Type: Select Single or Aggregated. The single option sends individual mails for every single system selected in the scope whereas the Aggregated option send an aggregated mail including all systems selected in the scope.

Finally you can click on the Create button as shown below to schedule your guided procedure.

Once scheduled, you can navigate back to the Guided Procedure Planning home screen to see the list of scheduled guided procedures and their current execution status.

Below is sample email for your reference.

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

SAP Focused Run operation dashboard

With Focused Run a dashboarding framework is available called Operation Dashboard. This enhancement comes under the Advanced Analytics & Intelligence (AAI) functionality of Focused Run.

With Operation Dashboard you can configure a 3 level drilldown dashboard to track the current situation of monitoring and alerting in the areas of System Monitoring and Real User Monitoring.

Currently you can track metrics and alerts only from areas of System Monitoring and Real User Monitoring.

Views in Operations Dashboard

Operation Dashboard provides 3 types of view to provide a consolidated view of the current status of monitoring and alerting.

  1. Analytics Map: Consolidate monitors to a specific region on the world map. The region is colour coded to the aggregated monitoring status of the monitors included. Aggregation uses worst case rule i.e The colour of the region is green only if all the involved monitors are in green.

2. Tile View: Shows the consolidated monitoring status of a specific Scenario/System/Managed Object. Aggregation uses worst case rule.

3. List Deatils View: Shows the list of involved monitors.

The above three views are linked automatically to eachother to enable the drill down functionality. That is, if you click on a perticular region which is rated in the world map view, you will get the correspoding systems/componenets for that region in the tiles view and the corresponding monitoring metrics in the list view.

Operation Dashboard Setup

To access Operations Dashboards click on Operations Dasboard tile under Advanced Analytics & Intelligence section in the Focused Run Launchpad.

Step 1: Create a new Operation Dashboard

Create a new Operations Dashboard by clicking on Add Custom Page in the navigation pannel of Operations Dashboard app.

Step 2: Name your dashboard

When you create a new dashboard, the dashboard setup are will appear on the right hand side of your screen. Click on the rename button as shown below.

Step3: Configure layout

You can configure the layout of your dashboard in a Grid format. Each grid in the layout will hold a view of your dashboard. As we have 3 types of views you can form a layout of 3 grids. To configure the grid layout click on the Grid button in the setup area – View Management section:

In the pop-up you can drag and drop to form a Grid layout:

Step4: Select monitoring content

To customize your Operations Dashboard, you first need to select the monitoring content as the source of data from either of System Monitoring or Real User Monitoring or both. For this navigate to Page Personalization area.

In the Default Settings area you can

  1. Select or deselect monitoring area (System Monitoring/ Real User Monitoring)
  2. Select or deselect metric or alerts
  3. Select or deselect category (Availability/Exception/Performance)
  4. Alert Severity ( Alerts of same or more severity are included in the scope of the dashboard)

Step 5: Create scenarios

In Order to link systems/ components to a particular region in the world map you need to create scenarios and link them to specific regions in the world map.

In this step you create named Scenarios or Regions to which you can later on tag your monitors. For this navigate to the Content Settings Area , Custom Scenarios Settings. To create a new scenario click on the + sign.

In the pop-up you can directly enter the country name or code or you can click on search to search for your respective country/region and it’s code.

You can see the list of all scenarios you created in the Custom Scenarios section.

Step 6: Add monitors and tag monitors

In this step you add systems/components and tag them to specific scenarios you created in the previous step.

For this navigate to Content Settings area, Data Source Settings and click on the + sign.

In the pop-up screen select the system/component you want to add and accept to continue.

Now back in the Data Sources list select the scenario for the system/component you just added.

Now your Operations Dashboard is ready.

  1. In View 1: World Map, the regions are coded as per the aggregated rating of all systems/componenets tagged to a specific scenario in the Data Sources settings in Step 6.
  2. In View 2: Tiles View, by default shows the Region/scenarios aggregated rating in tiles. In this view you can drill down to aggregated rating for each system/Compoenent/monitor by simply clicking on the tile. (For instance below shows the Tile view of the systems in Germany shown in the image 2 of this blog.

3. In View 3: the List View, shows the monitors for all the system/componenet shown in Tiles view, that is, if you drill down in Tiles View, accordingly filtered monitors are shown in Tiles view.

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

ABAP debugger stop at modification

As ABAP developer you can be asked to help out with issues in standard SAP to help debug the issue.

First of all, you normally use the ANST tool to check if there are any standard SAP notes available.

The second step is to search for user-exits and BADI’s for a transaction.

The third step you can do is use the new ABAP debugger script to search for customer enhancements during debugging. To do this, load the new script by applying OSS note 3415810 – New ABAP Debugger Script RSTPDA_SCRIPT_MODIFICATION.

Now start debugging like usual and go to the Script tab:

Then load the script RSTPDA_SCRIPT_MODIFICATION:

Then start the script and choose your break-point stop conditions:

Now you can check if there is any modification or custom coding interfering with standard SAP.

When no custom coding involved and issues is still persisting, you can debug, but will still be forced to file a case at me.sap.com for an SAP solution.

SAP Focused Run monitoring applications

This blog will explain specific items to keep in mind when monitoring certain applications.

Applications discussed and explained:

  • Adobe document servers (ADS)
  • BW systems
  • Cloud connectors
  • Content servers
  • ECC and S4HANA servers
  • EWM (enterprise warehouse management) servers
  • GTS (global trade system) servers
  • Netweaver gateway FIORI hub systems
  • SCM (supply chain management) servers
  • SLT servers
  • Web dispatchers

For each system we explain the monitoring of productive and non-productive system.

Adobe document server (ADS) application monitoring

Adobe Document Server (ADS) is used to generate PDF’s for output and/or interactive PDF forms.

Monitoring productive ADS systems

When monitoring a productive system, you will need to finetune the monitoring templates for:

  • SAP J2EE 7.20 – 7.50 Application template, for the JAVA application
  • SAP J2EE 7.20 – 7.50 Technical instance template, for the JAVA application servers
  • System host template
  • Database template

JAVA APPLICATION TEMPLATE for adobe document server monitoring

Make sure you cover in the JAVA application template the following items:

Availability:

  • JAVA HTTP availability
  • Expiring certificates
  • JAVA license expiry

From the JAVA instance template make sure to cover the following items:

  • J2EE application status
  • Instance HTTP availability and logon
  • JAVA server node status
  • GC (Garbage collection)

Fine tune the metrics so you are alerted on situation where the system is having issues.

ADobe document server template for monitoring

ADS has a specific Technical instance template.

Make sure you activate it:

Most important here is the first one: ADS availability. Please make sure you are alerted when this one is not available.

BW application monitoring

BW systems are at the often used as reporting systems within an SAP landscape.

The basic monitoring of a BW system is the same as for any ABAP based system.

For a BW system some numbers are typically higher than on an ECC or S4HANA system. Response times of 1.5 seconds would indicate horrible performance on ECC, but are normal on a BW system.

Process chain monitoring

BW uses process chains. To monitor process chains, read this dedicated blog.

Cloud connector application monitoring

The Cloud connector is used between on premise systems and Cloud solutions provided by SAP.

Monitoring of cloud connector focuses on availability and connectivity.

Monitoring productive cloud connector systems

The cloud connector template contains all the needed elements out of the box:

If your landscape has only one cloud connector that is also used for non-productive systems, you might find a lot of issues in the non-productive system. Like expired certificates, channels not working, many logfile entries. If the cloud connector is very important for your business, it is best to split off the productive cloud connector from the non-productive usage. This way you can apply sharp rule settings for production: even single issue will lead to alert. While on non-production the developers will be making a lot of issues as part of their developer process.

Monitoring non-productive cloud connector systems

In your landscape you might have a non-productive cloud connector that is used for testing purposes. In the non-productive cloud connectors you might apply a different template with less sensitive settings on certificates, logfiles and amount of tunnels that are failing.

Relevant OSS notes for cloud connector monitoring

3391143 – Cloud Connector system is not coming into SAP Focus Run LMDB

Content server application monitoring

Content servers are often used to store attachment and data archiving files. They are technical systems with usually no direct access for end user. End users normally fetch and store data form content server via an ABAP or JAVA application.

Technical setup for content server monitoring

The technical setup for monitoring content server in SAP Focused Run is described in detail in a PDF attached to OSS note 3151832 – SAP Content Server 6.40/6.50/7.53 Monitoring with SAP Focus Run. There is no need to repeat here.

The main part of content server monitoring is availability.

ABAP connection to content server monitoring

In some cases both your ABAP stack and content server are up and running, but communication between them is failing on application level. This leads to not working system for end users. Root causes can be firewall issues, certificate issues, or somebody altered settings.

To test the ABAP system connection to content server a custom ABAP program is needed. See this blog. You can schedule the program in batch and set up a new custom metric to capture the system log entry written by the program.

System host template for content server monitoring

For system host the regular CPU, memory, disc template is sufficient. Finetune the thresholds to your comfort level.

Database template for content server monitoring

Important items of the database template:

  • Database availability
  • Database health checks
  • Backup

In most installations it is chosen to install Content Server with the SAP MaxDB database (similar to LiveCache).

Relevant OSS notes for content server monitoring

ECC and S4HANA application monitoring

ECC and S4HANA systems are at the core of each SAP landscape, and most vital to the business.

When monitoring a productive system, you will need to finetune the monitoring templates for:

  • ABAP 7.10 and higher Application template, for the ABAP application
  • ABAP 7.10 and higher Technical instance template, for the ABAP application servers
  • System host template
  • Database template

ABAP application template

Make sure you cover in the ABAP application template the following items:

Availability:

  • Message server HTTP logon
  • System logon check
  • RFC logon check
  • License status
  • Certificates expiry
  • Update status

Performance and system health:

  • Critical number ranges
  • Enqueue lock % filled
  • SICK detection
  • Dumps last hour
  • Update errors last hour
  • Cancelled jobs last hour
  • Long running work processes and jobs (see blog)

Security:

  • Global changeability should be that the system is closed
  • Locking of critical users like SAP* and DDIC (see blog)

Fine tune the metrics so you are alerted on situation where the system is having issues.

ABAP application server template

Make sure you cover in the ABAP application server template the following items:

Availability:

  • Local RFC logon test
  • Local HTTP logon test
  • Local Logon test
  • Message server disconnects (see blog)

Application server performance and health:

  • Amount of critical SM21 messages
  • No more free work processes (see blog)
  • Update response times

You can consider to setup extra custom metrics for the application servers:

System host template

For system host the regular CPU, memory, disc template is sufficient. Finetune the thresholds to your comfort level.

Database template

Important items of the database template:

  • Database availability
  • Database health checks
  • Backup

Functions monitoring

Next to the availability and performance mentioned above, check also for monitoring certain functions:

EWM (enterprise warehouse management) application monitoring

EWM systems are at the often used as stand alone systems that make sure logistics and warehousing can keep running at high availability. If the connected ECC or S4HANA system is down, EWM can continue to support logistics operations.

EWM can be older version based on SCM/BI system core. Newer EWM systems are using S4HANA with EWM activated as standalone.

Extra in an EWM system are the use of qRFC and the CIF (Core interface). And many EWM systems have users that interact with the system via ITS GUI based handheld scanners.

EWM systems are at the often used as stand alone systems that make sure logistics and warehousing can keep running at high availability. If the connected ECC or S4HANA system is down, EWM can continue to support logistics operations.

EWM can be older version based on SCM/BI system core. Newer EWM systems are using S4HANA with EWM activated as standalone.

Extra in an EWM system are the use of qRFC and the CIF (Core interface). And many EWM systems have users that interact with the system via ITS GUI based handheld scanners.

CIF monitoring

The CIF is the core interface between SCM and ECC system. The interface typically uses RFC and qRFC. And it is working both ways.

Setup for the CIF specific RFC’s and qRFC’s the monitoring:

Handheld scanners

Many EWM systems are having interaction with scanners via the ITS server. Basically this is a small web page on a scanning device.

Make sure you monitor the availability of the URL’s that the scanners are using. More on URL monitoring can be found in this blog.

GTS (global trade system) application monitoring

GTS systems are at the not frequent in use. When in use they do play a vital role in import and export business scenario’s when good are crossing borders.

Since a GTS system is normally installed, and often no to little maintenance and software changes are performed on the system. Also basis teams tend not to look at it too often, since it normally runs stable.

In case of non-availability of GTS, ECC scenario’s linked to GTS might fail and can causes severe business disruptions.

For this reason it is important to set up monitoring in FRUN for your GTS system and also configure mail alerts in case of issues. They will not happen too often, but when they happen you can act fast. This will also save the basis team spending a lot of time on checking GTS system for log (most cases, the checks are good).

When monitoring a productive system, you will need to finetune the monitoring templates for:

  • ABAP 7.10 and higher Application template, for the ABAP application
  • ABAP 7.10 and higher Technical instance template, for the ABAP application servers
  • System host template
  • Database template

The next step is to set up interface monitoring for RFC from the ECC system towards the GTS system.

Netweaver Gateway Fiori hub system application monitoring

Netweaver Gateway systems are used to host Fiori applications.

Netweaver gateway template

For Netweaver gateway, also assign and fine tune the Gateway template:

The important custom check on URL availability is best to setup as well: read this blog for instructions.

Consider to setup interface monitoring for RFC‘s from End User to Gateway and Gateway to ECC backends.

SCM (supply chain management) application monitoring

SCM systems are at the often used logistics optimization systems. They are mainly used in combination with traditional ECC systems. They are less needed in combination with S4HANA systems (or you can use the embedded SCM of HANA).

The core of an SCM system is a BI system. Many data is using similar extractors and process chains as a BI system. Hence follow the tuning needed for a BI system.

Extra in an SCM system are the LiveCache and the CIF (Core interface).

The basic monitoring of an SCM system is the same as for any ABAP based system.

For an SCM system some numbers are typically higher than on an ECC or S4HANA system. Response times of 1.5 seconds would indicate horrible performance on ECC, but are normal on an SCM system.

LiveCache monitoring

LiveCache is normally running on a MaxDB database.

So it is important to activate, assign and finetune the metrics for the MaxDB database:

Focus on:

  • Availability
  • Backup
  • Performance

Next to the database, you also need to activate, assign and finetune the LiveCache specific application template:

This template contains the primary elements to monitor for the LiveCache functions like:

  • Availability of LiveCache as a function
  • Structure check for LiveCache
  • Memory issues for LiveCache specifically

Fine tune the metrics so you are alerted on situation where the system is having issues.

CIF monitoring

The CIF is the core interface between SCM and ECC system. The interface typically uses RFC and qRFC. And it is working both ways.

Setup for the CIF specific RFC’s and qRFC’s the monitoring:

Process chain monitoring

SCM uses process chains. To monitor process chains, read this dedicated blog.

SLT system application monitoring

SLT systems are mainly used to replicate data from source systems like ECC and S4HANA towards target systems like Enterprise HANA, HANA cloud and other data pool systems.

SLT DMIS template for SLT system

For SLT systems, apply the SLT DMIS template:

In the SLT system itself, make sure job /1LT/IUC_HEALTH_C with program R_DMC_HC_RUN_CHECKS runs. This will collect data that is needed for SLT itself, but which is also re-used by SAP Focused Run.

OSS notes to apply and check:

Anyhow you should make sure to regularly apply the notes for the DMIS component. See this blog.

SLT DMIS dummy template backend system

For SLT to work, the DMIS component is installed in both the SLT system and the backend system. For the backend system SLT component, Focused Run will pick up the template as well. But this will not make any sense in monitoring, since it is the source system and not the SLT system.

For this reason, set up a dummy empty template with every monitoring item disabled:

Assign this dummy template to your backend system.

SLT integration monitoring

Set up the SLT integration monitoring to monitoring communication.

Web dispatcher application monitoring

Standalone web dispatchers are used to load balance web traffic towards ABAP and/or JAVA systems. Common use case is to have web dispatcher for a large Netweaver Gateway FIORI installation.

Monitoring productive cloud web dispatchers

Monitoring of web dispatchers focuses on availability, connectivity and performance.

The web dispatcher template contains most needed elements out of the box:

Issues with performance are often caused by limitations set in the web dispatcher configuration. Keep these settings active.

You might want to add specific custom metric to monitor the most important URL for your web dispatcher. Read more in this specific blog.

Next to this setup the normal host monitoring to make sure the file system and CPU of the web dispatcher are not filling up and causing availability issues for the web dispatcher function.

Monitoring non-productive web dispatcher systems

For monitoring non-productive web dispatcher systems, it is normally sufficient to restrict to host and availability monitoring.

Relevant OSS notes for web dispatcher monitoring

3373764 – Issue with Content Server on Web dispatcher templates

LMDB OSS notes

3104059 – Troubleshooting ABAP Data supplier populating LMDB

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

ABAP performance examples

The ABAP workbench has a set of examples to show you how to make the best coding with regards to performance.

You can reach the examples in SE38 transaction by selecting menu Environment, Examples, Performance Examples. You then reach the performance examples demos screen.

On the left hand side you can choose a topic and double click on it. You then see 2 examples of implementation. By clicking on the Measure Runtime button:

Now the two examples are evaluated at runtime. At the bottom you can see the documentation and explanation on what is best to use.

SAP Focused Run health monitoring overview

Health monitoring can be used to monitor special use cases:

  • SLL certificate monitoring
  • Windows service monitoring
  • OS process monitoring
  • OS scripts
  • Logfile monitoring
  • URL availability monitoring

Health monitoring

Health monitoring can be started with the Fiori tile:

The overview screen opens:

From the overview you can immediately zoom to the error by clicking on the red bar:

Health monitoring content update

For updating content of health monitoring, follow the instructions in OSS note 3360399 – Unable to import the FRUN-CONT package FRUNCONT40003_0-80008241.ZIP.

URL availability monitoring

Health Monitoring provides a functionality called Availability Monitoring wherein we can monitor:

  1. HTTP Availability: Monitoring availability of URLs.
  2. TCP Availability: Monitoring the availability of a TCP port or the availability of a host.
  3. RFC Availability: Monitoring availability of RFCs specifically for measuring availability of an application server instance of an SAP system or the availability of a message server port of an SAP system.

In this blog we will explain how you can configure a HTTP Availability monitor to monitor availability of a URL.

Setup of URL availability monitoring

Step1: Assign Agent for data collection

The HTTP availability is measured by making a URL http or https call by a designated Simple Diagnostic Agent from your specific customer network in the Focused Run system.

The first step is to assign a Simple Diagnostic agent as the collector for this metric.

For this open the Health Monitoring App from the Focused Run launchpad.

Navigate to Configuration area by clicking on the Configuration button.

Expand the Customer Networks node and click on the button.

In the next popup select the agent from the list of all connected agents to this customer network.

Step2: Configure HTTP Availability Metric

In the Configuration area expand the metric node and click on the button for Availability under Metrics node.

In the next pop-up screen click on the button to add a metric.

In the next pop-up screen select HTTP Availability

Enter the following details for a basic URL Availability check.

FieldDescription
Metric NameA descriptive name for the metric
Customer NetworkSelect the customer network for which you want to create the metric
Collection FrequencySpecify the collection frequency, how frequently the check should be performed.
URLEnter the URL to be monitored
ProxyEnter the proxy detail if the URL is reached via a proxy from the customer network. Else select None.
AuthenticationEnter the authentication type None or Basic or oAuth and enter the details based on authentication type.
TimeoutPeriod in milliseconds (ms) before a call fails.
Number of RetriesNumber of times the data collector calls a URL until it receives a response.

You can also further customize based on type of call you want to do to the URL for instance sending a POST request. For details you can refer to the SAP documentation here.

Optionally you can also enable alerting and notification in the Alert section of the configuration.

After entering all the details save your configuration to activate the metric.

URL availability monitoring usage

To navigate to the URL availability monitors you can click on the Availability button in the navigation panel.

Or you can also navigate from home screen.

Upon navigating to the Availability monitor metric list you will see the status of all URL availability metrics configured. The metric list view shows us the number of days and hours since the URL is available or unavailable. It also shows us the response time when accessing the URL.

This way you can not only monitor the URL availability but also the performance of an URL with regards to the response time while accessing the URL.

OS process monitoring

With OS Process Monitoring functionality we can monitor the availability of critical OS level processes on any host.

With System Monitoring templates you can also activate custom metric for monitoring OS processes however this will be applicable for all system/hosts for which you activate the template.

For monitoring critical OS processes for specific hosts you need to setup using Health Monitoring functionality.

To access Health Monitoring functionality you can navigate to Health Monitoring app in the Focused Run launch pad.

Prerequisite for OS process monitoring

The only prerequisite for configuring OS process monitor in Health Monitoring is that you should have registered the host and deployed Simple Diagnostic Agent (SDA) on the host where you want to monitor the critical process.

Setup of OS process monitoring

For setting up the OS process monitor you need to navigate to the settings page of the Health Monitoring App.

In the settings area expand the metrics node and click on the pencil button (Edit Metric) for OS Processes.

In the OS Process edit metric screen click on Add Metric button to start creating the OS Process Metric.

In the OS Process edit metric screen click on Add Metric button to start creating the OS Process Metric.

FieldDescription
Process NameName of the OS process. This parameter needs to be maintained as a regular expression. SDA will use this expression for searching for the respective OS process at OS level.
User (Optional)You can further restrict the search for processes running through a specific user. You need to enter the name as a regular expression
Command Line (Optional)You can further restrict by the specific command line with which the process is running . This is specifically useful if there are multiple processes running with the same name but you want to monitor the process which is running with a specific argument or parameter. This also needs to be maintained as regular expression.
HostnameName of the host where the process to be monitored. You can select from a list of all hosts connected (also SDA deployed) to the Focused Run system.

In the General Settings tab you can also specify the data collection frequency and the threshold. By default 5 minutes frequency and Already Rated threshold is set.

Optionally you can update the alert settings for this metric in the Alert Settings tab. By default alerting is active with medium severity.

After entering all details, to activate the metric click on Save button.

You can monitor all you OS process metrics in the OS Processes tab of the Health Monitoring App.

SSL certificate monitoring

You can configure monitors to monitor the SSL certificate of a URL using Health Monitoring functionality in SAP Focused Run system. This monitor measures the remaining validity (in days) of a SSL certificate for a https call to a URL. The URL is called by Simple Diagnostics Agent of a designated host in your customer network.

The Health Monitoring app also provides a separate section called as URL Certificate Monitor where in you can centrally monitor expiry of SSL certificates of any https URL.

To navigate to URL Certificates monitor you can click on the URL Certificate button as shown below in the navigation panel of the app.

Setup of SSL certificate monitoring

To configure URL Certificate monitors , navigate to the Configuration area, expand the Metrics node and click on the change button.

In the popup window click on the Add Metric.

In the Metric Configuration window enter the following details in the General tab.

FieldDescription
Metric NameA meaningful name to the monitor
URLURL whose certificate to be monitored.
Proxy URL (Optional)The Proxy URL if the URL is accessible via a proxy URL
Customer NetworkThe Customer Network to which this URL belongs. The designated SDA from this customer network will be performing the check.
Technical System (Optional)You can optionally link this monitor to a specific cloud service you have registered in your LMDB. This is the Cloud Service you would have created if you are using AIM scenario for Cloud Service Monitoring. Select from the drop down.
Collection IntervalFrequency of data collection. Select from available options.
ThresholdThreshold for remaining days for expiry. By default 200 Days for Yellow and 100 days for Red.

Additionally and optionally in the Alert Settings tab you can activate alerting and notification settings as shown below.

That’s it, now your monitor is active.

Using SSL certificate monitoring

To monitor navigate to the URL Certificate tab in the Health Monitoring App.

You can also refer to this SAP documentation to know more about various features available with Focused Run Health Monitoring.

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