Welcome to the Sensorboard

You've found the manual for the Sensorboard - home of sensors that keep an eye on details of your S/4 Hana system. This manual covers the individual sensors that are available on the board.

Welkom op het Sensorbord

Je hebt de handleiding gevonden bij een Nederlands- en Engelstalig sensorbord, thuishaven voor sensoren die een oogje in het zeil voor je houden voor het S/4 Hana systeem. De handleiding is alleen in het Engels beschikbaar. Deze handleiding behandeld de individuele sensoren op het bord.

Overview of groups for sensor types

The Sensorboard is a product that was designed and developed in Abap on S/4 Hana. The actual board is shown in a SAPGUI screen as HTML (CSS, JavaScript) document. The board refreshes automatically. Details from the board are also available as a service (oData) - which can be used to project the board content just about anywhere.

The sensorboard is displayed as an HTML page for which examples are shown below. Note that the below example does not respond to clicks where the real sensorboard (in SAP HANA) does.

The examples all show the same board content (roughly). The end user can select which display settings are best to use.

Responsive preview of a sensorboard with it's sensors.

Compact size - switch between normal and compact size - with a single click

Versions

A product like the sensorboard is never completely finished and finalized. New sensors are created regularly at the customer site. Some of these sensors may me applicable for other customers as well, thus new sensors (sensor type logic) can be added to the suite over time.

The board itself may also be improved. As we are working with customer requirements, there may be requirements that can be useful for other customers too.

This overview is the version or release blog, briefly explaining what was added/changed with the release. When this page is called directly from the sensorboard (click on version number), a version-check is done.

Two ways to do the check:

1. Click on the "Version ... " at the left side of the sensorboard main overview.
2. Set up a sensor with sensor type VERSION which reports on anomalies. The sensor also hosts a link to check the overall board.

Version overview

Sensor controls

Sensors are very customizable creatures. It's behaviour can be customized to respond with a warning or an error (general settings). But it can also be set up to just report on KPI's without further action. In addition to that, sensors can be fine-tuned with settings that are relevant to only that sensor.

Sensors can be fine-tuned to respective requirements. This is done through sensor parameters of which there are 2 types:

1. The sensor parameter, a series of control settings
2. The sensor long text, a much more elaborate set of settings, available as a text.

General settings

Settings that can be applicable to any sensor are called general sensor settings.

None of the general settings are mandatory, as defaults are available. It is however possible and even recommended to personalize sensors to what they do. Feel free to supply a new name to the "Dumps" sensor if they are about the dumps for today only. "Todays dumps" would be a suitable title.

The general settings include details like

• Title and UoM - these will appear as texts on the sensor tile and sensor full description.
• Warning and errorlevel - these will determine the sensor behaviour. The status of the sensor is determined with warning level and/or error levels.
• Delay - this controls how often the sensor should be checked. As it's pointless to have a sensor about yesterdays data redetermine the same results all day.
• Documentation link - this will present a documentation link on the sensor tile and sensor detail overviews.
• Logging - controls the logging options. Makes sense for some sensors, makes no sense on others.
• Detailed - indicates whether the sensor detailed logging should be performed. This is a 2-step process, first the sensor needs to be flagged as "Detailed" and then the sensor engine report needs to be scheduled to actually capture these details. Thus the frequency is a arranged in the scheduled batch job (or jobs).

The sensor general settings form the general controls over (all) sensors. They may seem "picked at random" but they all serve a purpose. Take Delay for example. When a sensor consumes a lot of time (anything over 4 seconds), you should consider setting the delay. Effect ? The sensor is not executed every time - which adds up to a lot of processing time at the end of the day. Just so you realize: each setting has it's own story.

Sensor parameters

The sensor parameter is a short 1-liner that consists of upper-cased and mostly optional instructions for the sensor. A common example would be

DATING:10

Feel free to compose a new group with the best of relevant sensors from other groups.

To find out what parameters are available on the sensor you want to use, simply use the F4 function on the parameters field (which lives on the Sensor settings editor). Only (and all) relevant parameters will be listed here.

The TIMING parameter

Usually, there is only one of DATING and TIMING specified. Examples:

TIMING:180

TIMING:180-5

The DATING parameter

For dating, the same formatting is used. There is however - this thing called "today". The most common examples of DATING:

DATING:1

DATING:1-1

DATING:45-14

DATING:0

If a sensor throws errors on an item that can age, then simply fill in the DATING parameter with the number of days you want to look back. E.g. DATING:30. And add a backup sensor with parameter value DATING:120-30 for the old cases (90 days).

The DATING can also be used to select dates older that a given date.

DATING:-90

DATING:+30

DATING:10+30

DATING:20260101

Parameter as Range Variable (RV)

Sensors often use parameters for their main selections. Using a sensor parameter, the sensor can be controlled to work with a limited selection. Only for a specific job or only for a specific user. Many parameter fields have an -RV counterpart - where RV stands for Range Variable.

Sensor type SUIM is about users and it has a USER and a USER-RV parameter. This is what you can do with these (example) parameters:

• Set USER:MAASDAMW - to make the sensor work with a single user.
• Set USER:MAAS* - to make the sensor work with all user ID's that start with MAAS.
• Set USER-RV:USERS - to make the sensor work with a Range Variable called USERS.

  Using ranges, numerous selection settings can be done. List all required users individually, exclude certain users from the selection. Use ranges (from to) exclude ranges (from to), use or exclude a pattern (MAAS*), there are many options.

Once the use of a range variabele is set up - the sensor detail report will show what select options were used. The sensor will thus explain how its KPI result was composed.

Sensor long text

The sensor long text holds sensor settings that are applicable to all sensors of the same type. There is no limit to the settings, lower cased values are supported and there is usually a mechanism like ID or NAME in place to link the settings to a specific sensor from the board. The ID or NAME would need to be specified on the sensor parameters.

The documentation on the sensor long text is available only for sensors that use the long text. A documentation button is shown in the Sensor settings editor.

Note that this documentation is available only in English. And for those who will add their own sensors to the framework: the sensor long text documentation is derived from comments in your coding. Make sure you also add such comments - to serve our end users.

Here's how that looks:

        "Fetch longtext information, for lt_whitelist (to be skipped) and lt_blacklisted (marked as high importance)
        DATA(lt_textlines) = zcl_sensor_manager=>get_longtext( ).
*| The sensor text can be used to specify which runtime errors can be ignored
*| (whitelist) and which ones are super important (blacklist). Memory-related
*| dumps have already been blacklisted for you (embedded in the coding of the
*| sensor). For additional settings:
*| /: BLACKLIST
*| *  TSV_TNEW_BLOCKS_NO_ROLL_MEMORY
*| *  SYNTAX_ERROR
*| /: WHITELIST
*| *  TIME_OUT
*| *  RAISE_EXCEPTION
        LOOP AT lt_textlines INTO DATA(lv_textline).	
	

Info - the setting that is available for any sensor

There is one option that is available on all sensor types. The INFO tag can be used to add information texts to your sensor. It can be made language specific and it can be made reference specific.

Here's how that looks:

  /: INFO
  *  This sensor has special features you want to know more about.

  /: INFO:EN
  *  This sensor has special features you want to know more about.
  /: INFO:NL
  *  Deze sensor heeft speciale functies waar je meer van wilt weten. 

  /: INFO:DOCU01:EN
  *  This sensor has special features you want to know more about.

The additional information text will be displayed at the end of the standard text. Note that the standard text can also be changed - through the Internationalization features.

Types of sensors

Each sensor on the sensorboard is in fact an implementation of a Sensor Type. Each sensor type will have a clear link to a class (with interface ZIF_SENSORS) and method (SENSOR_{sensor_type}). The class name and sensor type is mentioned on the sensor report output.

The standard set of sensor types that is delivered with the product (over 70 types) are captured in classes with naming convention ZCL_SENSORS_* and a hand-full of sensors on ZCL_SENSOR_MANAGER.

When a sensor is added to the board, a group needs to be selected. It is not possible to add a sensor with the same sensor type and the same parameter settings to a group. Here's the rule:

Sensor = Sensor type + Parameters

The sensors that are supported by a fixer report are highligted with the tools-icon.

Performance

When the system performance is low, there are a number of root-causes to consider. The sensors listed here have a focus on system-wide performance. This includes CPU utilization on dialog processes and background processes, memory - which will reveal the first signs of system struggles.

Getting started

To monitor the system's performance or system health, CPU, memory and space are the main subjects. And a lot of preperation for this can be skipped, when using this group with prepared sensors:

Download: systemhealth-sensors.json

The json file contains a group with all the main system health related sensors - as described on this page. Plus a handful of other paragraphs.

The sensors

• ST06UPTIME Last system restart
  
  This sensor has a KPI counting the days since the last system restart. Much like the "days since last accident" signs on factory floors. A healthy system doesn't need to restart very often. The sensor shows the last date/time the system and it's database started. In addition the application servers are listed - with their respective status.
  
  
  
  
• ST06CPU CPU utilization
  
  This sensor checks CPU utilization on the system. Processors can be idle or occupied, the over-occupied Processors will have an impact on the performance. An S/4 Hana system is equipped with multiple processors, thus the information on CPU utilization is monitored in clusters. The sensor's purpose is only to warn on excessive CPU utilization. For more detail - check out transaction ST06.
  
  

  Parameter	Description
  APPSERVER	Specific to an application server APPSERVER:1 of APPSERVER:p11-paisd1_SD1_21

  
  
  
  
  
• ST06MEMORY Memory usage
  
  This sensor checks Memory usage on the system. An S/4 Hana system is all in memory, but part of this is process memory used by processes (and limited). The sensor's purpose is only to warn on excessive memory usage. For more detail - check out transaction ST06.

  Note that memory is an application server matter, hence the calculated percentage is for all application servers combined. The sensor can also be set up to measure a single application server. Thus a sensor for each server can be set up.
  
  

  Parameter	Description
  APPSERVER	Specific to an application server APPSERVER:1 of APPSERVER:p11-paisd1_SD1_21

  
  
  
  
  
• SM50 Work processes
  
  The system has dialog processes and background processes which are made available. The number of processes in use versus the number of available processes is returned as percentage KPI. Dialog processes and background processes can be separated through parameter settings. Application server can also be specified.

  For more detail - check out transaction SM50.
  
  

  Parameter	Description
  SERVER	SERVER:servername, only for application server servername
  TYPE	TYPE:BTC, only background processes

  
  
  
  
  
• SPEEDPROBE Speed probe measurement
  
  

  The system is slow ! Which itself is something that can be measured. A clever speed-probe setup was cooked up for this. Here's how that works:

  • Fact: the sensorboard has a heart-beat batch job that runs every few minutes (3 or 4 normally).
  • This heartbeat job will execute a wide variety of sensors, each with their own selections and determinations.
  • These continuous executions can be regarded as a "stable work package", which is executed all day every day.

  A stable work package can be used as a fully automated system-performance-thermometer. This sensor will gather performance information from the log that is produced by the heartbeat job. The KPI for this sensor is the total number of seconds (milliseconds) that was consumed by the sensor selections/calculations.

  Do note that the definition of a stable work package should also include update processes - which are available but limited (updates on sensorboard administration only).

  The number of milliseconds is in fact not saying much. It only becomes information when the "score" is compared to the previous scores. Therefore this sensor works best in conjunction with the INDEXER sensor, which will report the results as an index (much like the AEX index). You even get to choose the period of time to use for indexing.

  Note that this setup utilizes already consumed processing times, thus no performance is lost in the measurements itself.

  Note that sensors can be slow and the "delay" can be set for slow sensors. This ensures they are not executed continuously. Sensors with a delay are automatically omitted from the performance measurements on this sensor.
  
  

  Parameter	Description
  JOBNAME	Use specifically for a given job, e.g. JOBNAME:SENSOR_HEARTBEAT

  
  
  
  
  

Logs

The system is set up to keep track of what happened, for which many logging setups are available.

• SLG1 Business Application Logs
  
  

  The business application log or BAL is for transactional logs. These should be made available for actual identifyable topics such as documents (an purchase order, a sales order, or even an Idoc). Business application logs are accessible through transaction SLG1 (there's also SLG0 and SLG2) and these logs are made visible on a dedicated sensor only when they contain errors.

  The sensor can work with a specific object and subobject, which allows linking it to a given process. The sensor also measures the total size of BAL logging information available - with a hint on how to clear it.

  I it's not only errors that need to be monitored, consider using the SQL sensor on table BALHDR.
  
  

  Parameter	Description
  DATING	DATING:31, the past 31 days including today
  EXTERNAL	Specific to the SLG1 external ID (EXT) (wildcards allowed)
  EXTERNAL-RV	Selection with a range variable (see sensor type RANGES)
  MAXCOUNT	MAXCOUNT:1000000 (default), the limit on the BALHDR table, shows warning The SLG1 administration can become quite large when left unattended. Best leave the default in tact.
  OBJECT	Specific to the SLG1 object (OBJ)
  OBJECT-RV	Selection with a range variable (see sensor type RANGES)
  SUBOBJECT	Specific to the SLG1 subobject (SUB)
  SUBOBJECT-RV	Selection with a range variable (see sensor type RANGES)
  TIMING	TIMING:120, the past 2 hours (default 1 hour)

  The parameter string for this sensor can be quite long. Therefore the parameter names for OBJECT, OBJECT-RV, EXTERNAL, EXTERNAL-RV, SUBOBJECT and SUB_BJECT-RV can als be shortened to OBJ, SUB and EXT.
  
  
  
  

• SCU3 Change Documents
  
  

  Change Documents keep track of mostly functional documents on the system. Old and new values for a wide variety of objects are captured in Change Documents. There are sensors that keep track of the size of the tables on which Change Documents are held (CDHDR and CDPOS). This sensor covers a different demand: it seeks out specific changes you may be interested in.

  The sensor long text settings can be used to specify which specific change or changes are relevant to monitor. The sensor KPI is the number of detected changes.
  
  

  Parameter	Description
  DATING	DATING:10, select data for the last 2 days
  CHECKID	CHECKID:CHECK1, for a specific check ID (sensor text settings) The sensot text administration uses a CHECKID for it's checks.
  TIMING	TIMING:120, the past 2 hours (default 1 hour)
  OBJECT	OBJECT:ADRESSE, for a specific change document object class The object is the Change Document object class.

  
  
  
  
  
• SXI_MONITOR Processed XML messages
  
  The XML message monitor or SXI_MONITOR logs XML traffic for the system. This setup also carries a log, for which the sensor was set up.
  
  

  Parameter	Description
  DATING	DATING:31, the past 31 days including today
  TIMING	TIMING:120, the past 2 hours (default 1 hour)
  USER	USER:PI_REMOTE, specifically for user
  USER-RV	Selection with a range variable (see sensor type RANGES)

  
  
  
  
  
• SRT_MONI SOAP message processing
  
  Another message monitor as transaction SRT_MONI monitors traffic to and from the system. This sensor checks whether messages could not be processed. The SRT_MONI can also retry errored messages, which will effect the sensor KPI.
  
  

  Parameter	Description
  DATING	DATING:31, the past 31 days including today
  IF	IF:INTERFACENAME use for specific interface (wildcards allowed)
  IF-RV	Selection with a range variable (see sensor type RANGES)
  TIMING	TIMING:120, the past 2 hours
  USER	USER:PI_REMOTE, specifically for user
  USER-RV	Selection with a range variable (see sensor type RANGES)

  
  
  
  
  

  This sensor has autofix support. When you schedule the ZSENSOR_FXR_SRT_MONI with a properly filled variant, the report will attempt fixing the sensor-reported issues. The sensorboard engine can also be instructed to throw a batch event - for the fixer run. When using batch events, you should condider using the TIMING parameter. When this parameter is set, the sensorbard engine will trigger a batch event every time it runs ( and the sensor is in error). Without the TIMING parameter, it will only trigger a batch event when the sensor turns red. Download: fixer report SRT_MONI The sensor (type) settings for the sensor are used to capture what the sensor fixer (FXR) should do. Only Entries with sensor parameter value AUTOFIX:Y will be processed. The step plan to using this fixer report: The fix that is executed by the fixer report is the "resend of failed messages". The fixer report will restart all the messages that are reported on the sensor. Control the retry-frequency by scheduling the job (hourly, daily, ..) Control how log retries should be attempted by setting the DATING or TIMING parameters on the sensor. Schedule the fixer with the exact same parameter value as specified on the sensor.

Batch jobs

Batch jobs cover an important and continuous workload of tasks that need to be done. Keeping a close eye on batch jobs is good sensor-ship. The heartbeat of any system - keeping it alive at all times.

What could go wrong ?

Batch jobs can be cancelled, which would stop the job. They could run for too long because of the workload or some deadlock situation. When a job step (a report call that is executed for the job) encounters a serious ploblem (e.g. divide by zero), the job will be stopped with a dump. Many jobs throw an error to indicate it couldn't do anything (suicide). Nd then they can also be stopped manually (user action). They could be started before the previous job stopped. And they could log an issue - without cancelling, which could still be a point of interest for our sensor.

Transaction SM37 will show details on batch jobs, from where all available batch job information is accessible. Next to the periodically scheduled jobs - there's also the jobs that are triggered from an event. Also available from transaction SM37 and also scheduled to wait for the event.

The most important thing to realize with batch jobs - is that they are meant to "do something". Batch jobs cause changes or creations. When they don't run - something doesn't get done.

As there is quite some options on batch jobs, there are also quite some sensor types available.

Quick guide to the batch job sensors

As batch jobs are a quite prominent system feature, it comes with a variety of sensor types. Each of these types focus on a different feature. A short guide to help you out:

Batch job sensor types

• SM37 Batch jobs
  
  This sensor focusses on failing jobs. The simplest form is the total number of failed jobs on the current day. The sensor works with the TIMING and DATING parameters, which control how long the sensor should look back.

  The sensor can also be set up to focus on a specific job. Parameter NAME can be used to specify the focussed job. This can be used to compose a group specific for a process. The SM37 sensor can be set up to focus on batch job used by the process (covered in a group).
  
  

  Parameter	Description
  CREATOR	Use specifically for a given user, e.g. CREATOR:DDIC
  CREATOR-RV	Selection with a range variable (see sensor type RANGES)
  DATING	DATING:2, the past 2 days
  EXECUTOR	Use specifically for a given executor, e.g. EXECUTOR:DDIC The executor is the user that will execute the job-step.
  EXECUTOR-RV	Selection with a range variable (see sensor type RANGES)
  JOBNAME	Use specifically for a given job, e.g. JOBNAME:SAP_SLD_DATA_COLLECT or *_MC If there is a naming convention applied, like *_MC for Mission Cirtical of FIN_* for Finance department, just set the jobname with wildcards.
  JOBNAME-RV	Selection with a range variable (see sensor type RANGES)
  STATUS	Use specifically for a given status, e.g. STATUS:R for active jobs The default is status A, which is cancelled jobs. P=Planned, S=Scheduled, R=Running, F=Finished and A=Abandoned.
  STATUS-RV	Selection with a range variable (see sensor type RANGES)
  TIMING	TIMING:120, the past 2 hours

  
  
  
  
  
• SM37ALL Batch job overview
  
  This sensor composes a list of the (all) batch jobs that are scheduled. This list is used to compose a list of unique batch jobs and their steps.

  This sensor helps to check the overal health of the batch job administration. The sensor lists the active jobs and caters for an in-sensor registration. The sensor long text can be used to specify each specific job. Contact information (who to contact for this job) and a description (which has no max length) can be specified - information will be displayed on the overview.

  The KPI on this sensor is the counter of non-registered batch jobs. This could be used to keep an eye on newly created (periodic) batch jobs.

  The alternative KPI on this sensor can be set to the number of warnings that the sensor picked up. These include things like "batch jobs that have no named variant" or "batch job creator and batch job step executor are not the same person". A poor habit matter rather than show stoppers - however having a good solid clean batch job house-hold goes well with running the system properly.

  A refreshing view on batch jobs

  This sensor offers a refreshing view on the state of affairs with batch jobs. It reports the available jobs and steps, with periodicity information, job creator and step executioner (users). The sensor KPI indicates the number of unregistered jobs, but even without registering any jobs, the overview shows what is active (and how active) - in summarized form.

  Try transaction ZENDOCTOR for a dedicated report on sensor SM37ALL results.

  This can be used to indicate what steps could be grouped together (so several daily house-keeping steps can be captured in a single house-keeping job) or to check which regular users are running jobs under a system user (which has more authorisation). Any steps that are scheduled under multiple jobs ? With the reporting on this batch job overview, job and step matters are clarified.

  Naming conventions

  Batch jobs are scheduled to keep the system running and to keep the main tasks for the finance team in mint condition. The same listing of batch jobs serves the full company - hence a naming convention is very important.

  The (nearly all) batch job related sensors - can work with your naming convention. All you would need to do is some settings on the SM37ALL sensor where convention and description meet. Just name your mission critical jobs like .._MC and specify the naming convention on the SM37ALL sensor. Not only will the "Mission critical" label appear on the sensor reports, but you can now also set up a SM37 sensor to shout out when a mission critical job fails.

  Job registration

  The sensor settings also cater for "job registration" of periodic and event triggered jobs. A registered job is one that is mentioned in the sensor text settings, which makes it a "known job". Registered jobs can have the following details:

  • Contact the person or department to contact about the batchjob (e.g. when it fails).
  • Description a brief description on what the job does.

  But even without specific contact or description a batch job can be registered. The idea behind this is having a mechanism of keeping track of new jobs (as these are unregistered by default).

  A simple solution for a rather serious problem: a clear administration on the company batch jobs is often not available or incomplete.

  This information is also listed on the SM37 sensor when a job fails. Thus the person to contact can be logged on the sensorboard - which will use it as context-relevant information.

  Need some tools to do adjustments ? There's the BTC_MASS_JOB_CHANGE report. Change job creator, change step executor. Get it right.

  The sensor-reported content can also be composed as a list of job-steps. Instead of batch job names, the reports that are executed for the jobs are the main subject of the overview. Actual batch job information is also made available.
  
  

  Parameter	Description
  AS_WARNINGS	AS_WARNINGS:Y KPI on warning messages The KPI for this sensor is defaulted to the number of batch jobs that were not registered on sensor text Settings. An alternative KPI is available as the counter of warnings.
  DETAILED	DETAILED:Y, show extra details
  JOBNAME	Use specifically for a given job, e.g. JOBNAME:SAP_SLD_DATA_COLLECT or *_MC If there is a naming convention applied, like *_MC for Mission Cirtical of FIN_* for Finance department, just set the jobname with wildcards.
  JOBNAME-RV	Selection with a range variable (see sensor type RANGES)
  NO_WARNINGS	NO_WARNINGS:Y hide warning messages To simplify the reported output of the sensor, the warnings can be switched off.
  STEPS	STEPS:Y, reporting based on steps An alternative to reporting on individual jobs, the sensor can also be set up to report on the steps on these jobs. This can be useful when guarding step-duplication.

  
  
  
  
  

Alternate KPI: warnings

Instead of a KPI on unregistered batch jobs, this sensor can also be utilized in another way. The Sensor shows warnings as (!) texts - which address common issues. The warnings listed:

• Batch job creator - no longer exists
• Step executor - no longer exists
• Batch job creator is not the same as step executioner
• The variant of a step is ad-hoc (&00000000001 for example) - a bad habit
• A step / variant combination is already planned on another batch job - duplicate?
• Multiple batch jobs share the same name

These warnings can also be used to compose the KPI, using parameter AS_WARNINGS or omitted with parameter NO_WARNINGS.

The jobdoctor

Transaction ZENDOCTOR.
The report report that will help keep the batchjob pool in control.

The ZENDOCTOR report reveals the true state-of-affairs on the periodic (and event triggered) jobs on the system. It shows the overview of jobs with relevant details including the warnings from the SM37ALL sensor.

As the sensor report holds a lot of information, it reaches a sensor's limit to report its details. This is why a dedicated report is available on the sensor details. The report shows everything that is up and running on your system. An overview of tasks with relevant details, warnings where applicable and steps with relevant details. Additionally it shows recent run history (the last 10 runs) and it indicates registered tasks.

A single report that should help doctor your batchjobs to a healthy state. The report ZSENSOR_REP_SM37ALL or transaction code ZENDOCTOR.






• SM37CPU Batch job continuous performance
  
  This sensor calculates how many processing seconds were consumed by running batch jobs. It checks the batch job start and end times and calculates how much processing seconds can be claimed on the last hour. All the time combined is likely to be more than 60 minutes in the hour (as systems have multiple processors).

  As a stand-alone KPI count, this does not mean much. But if the sensor results are logged, it will reveal a pressure-gage graphic indicating how busy the system is. The same (nearly) information can be retrieved in standard SAP by running SM37 with a given time-slot. The SM37 report has a column on processed time which is totalled. The one thing to take into account here is that jobs that have been active for multiple hours will mess up the data. The sensor has focus on the last hour (or alternative period of time) even if the actual job already ran multiple hours.

  Note that the determination logic behind this sensor is "light weight", as it simply selects logged start and en times and calculates the totals from that.
  
  

  Parameter	Description
  DATING	DATING:31, the past 31 days including today
  PERIODIC	PERIODIC:Y, only periodic batch jobs
  SHOWZERO	SHOWZERO:Y, also show batch jobs without processing time (0 sec.)
  TIMING	TIMING:120, the past 2 hours (default 1 hour)

  
  
  
  
  
• SM37LOGS Batch job logs details
  
  This sensor checks the logs of a job for specific entries. Jobs that reveal an issue in the joblog without stopping the job, can still be monitored on a sensor.

  For custom developments, this means that the developer has an easy way to link his/her batchjob to a sensor. All that needs to be done is to add a message to a job log for a report when the special case to be monitored occurs. This sensor type will respond to that message.

  Applicable to any message on any log. Do note that the KPI on this sensor is the number of batch jobs that contain the specified message on the batch job log. It does not count the number of times the message appears.
  
  

  Parameter	Description
  DATING	DATING:31, the past 31 days including today
  JOBNAME	Use specifically for a given job, e.g. JOBNAME:SAP_SLD_DATA_COLLECT
  JOBNAME-RV	Selection with a range variable (see sensor type RANGES)
  STATUS	Use specifically for a given status, e.g. STATUS:F for finished jobs
  STATUS-RV	Selection with a range variable (see sensor type RANGES)
  TIMING	TIMING:120, the past 2 hours (default 1 hour)

  
  
  
  
  
• SM37LONGEST Longest batch job
  
  This sensor focusses on long running jobs. The simplest form will determine which of the active jobs has been active for the longest time.

  Long running jobs can indicate problems like dead locks or processing loops.
  
  

  Parameter	Description
  DATING	DATING:31, the past 31 days including today
  JOBNAME	Use specifically for a given job, e.g. JOBNAME:SAP_SLD_DATA_COLLECT
  JOBNM-RV	Selection with a range variable (see sensor type RANGES)
  TIMING	TIMING:120, the past 2 hours (default 1 hour)

  
  
  
  
  
• SM37SINGLE Batch job details check
  
  Some health checks that apply to specific batch jobs can be checked by this sensor. Expectations on the longest runtime, or the maximum time between jobs can be tested. In some cases the job should be scheduled by a system user, which can also be tested.

  This type of sensor is usually only applied to serious mission critical batch jobs, that need full focus attention. The general health of a job comes with expectations on how long it runs (with a minimum and/or maximum), what maximum period of time is allowed in beween runs and also who should be the batch job author.

  "If it runs that long again - we need to know about it". This sensor will serve you.

  Note: no need to check all these checks, just use it for the check you need, all others are optional.
  
  

  Parameter	Description
  DATING	DATING:31, the past 31 days including today
  JOBNAME	Use specifically for a given job, e.g. JOBNAME:SAP_SLD_DATA_COLLECT
  TIMING	TIMING:120, the past 2 hours (default 1 hour)

  
  
  
  
  

System health

Sensors that are essential to keep the system stable include system-wide features such as Runtime Errors, the system log and information from the Hana cockpit.

The HANA Cockpit is available to monitor the systems database matters. It houses many tools that can be used to pinpoint issues with data storage or performance. The new version of transactions DBACOCKPIT or DB02.

Note that the Hana cockpit can be configured to send out a notification mail if something gets out of hand. The same applies to the sensors listed here - sensors that act on the same system administration that is used for the Hana cockpit. The sensorboard can thus inform you when you should look at the Hana Cockpit, for a selection of the potential issues.

• SM21 System Logs
  
  

  The log of all logs is the system logs. Dedicated to keeping the system up and running. Not the place where transactional data issues should be logged.

  It is possible to let custom build logic drop a message on the SM21 log, but it is not recommended. the SM21 log is for standard SAP matters which include logon fails, connection fails, dumps, break-point interruptions, memory issues, space issues and much much more. When a system goes down, the role of SM21 in determining the root cause is very important.

  Note that the sensor will only report on the error messages on SM21.
  
  

  Parameter	Description
  TIMING	TIMING:120, the past 2 hours (default 1 hour)

  
  
  
  
  
• ST22 Runtime errors
  
  

  Runtime errors

  Any system will have problems that can't be resolved. On an SAP system these end up in the ST22 dumps overview. Dumps are the generated logs for processes that were stopped - by the system. A division by zero, a timeout on a user process that ran too long or even a programming error.

  The thing with runtime errors

  There are so many processes running on the system all day (and night), that some will inevitably be stopped. The system will automatically gather available information - and create a detailed logging for it: the dump. The log is a "dump of the details" for a runtime error. They can be found in transaction ST22.

  So what's the concern ? There can be many, as a runtime error on a process can happen on any process. A few points of interest - on runtime errors:

  • A runtime error halted a process - "in mid-air". This process thus didn't get the chance to finish it's task (and the process doesn't know about this). A runtime error is an interruption of a process.
  • A common reason for runtime errors is the TIME_OUT. A user starts a report which selects so much data, that the time-out time is exceeded (something like 20 or 30 minutes). The system will stop the process and log it's details in a dump. This type of dump is usually low priority and no concern, as it does not involve updates and there is only 1 disappointed user.
  • To avoid the TIME_OUT, the user could schedule the report to run in the background, to which TIME_OUT is not applicable.
  • For other dialog or background processes, many things could go wrong. Sometimes even as a series of runtime-errors, which could seriously influence the system.
  • Is your system using system-users for batch jobs ? This would be a very useful feature, as the jobs and the runtime-errors they may throw can easily be recognised as system-relevant (making them more important).
  • Is the actual runtime-error related to an issue that has an effect on all processes ? E.g. memory related runtime errors ? When memory is running out, eventually all processes are involved. Another way to prioritize runtime errors.
  • It is not uncommon for runtime errors to appear during or after transports were applied. A faulty or incomplete transport can damage coded objects leading to syntax errors.

  This sensor checks for (new) runtime errors.

  This sensor settings work with a blacklist and a whitelist for runtime error codes. Errors that are deemed irrelevant (like TIME_OUT) can be whitelisted (will not be reported) and the errors that need attention are blacklisted giving them a higher priority. Memory-related runtime errors would be suitable candidates for the blacklist.

  The sensor caters for selection refinement - to e.g. a system user.
  
  

  Parameter	Description
  EXCEPTION	EXCEPTION:SYNTAX_ERROR, for a specific runtime error (EX: also works)
  EXCEPTION-RV	Selection with a range variable (see sensor type RANGES)
  MAXRECORDS	MAXRECORDS:1000, shows additional message on historic dumps (default 10000)
  PRIORITY	Show only high priority dumps PRIORITY:HIGH
  TIMING	TIMING:120, the past 2 hours
  USER	Show only for specific user USER:DDIC
  USER-RV	Selection with a range variable (see sensor type RANGES)

  
  
  
  
  
• DBALERTS Alerts from the cockpit
  
  Use transaction DBACOCKPIT or HANA COCKPIT to check the Alerts. Select Current status, then Alerts.
  
  

  Parameter	Description
  LEVELS	LEVELS:1,2 Only 1=Information, 2=Warning and 3 = Error

  
  
  
  
  
• DBMEMORY System available memory
  
  Use transaction DBACOCKPIT or HANA COCKPIT to check the available memory.
  
  

  Parameter	Description
  IN_GB	IN_GB:Y In Gb (Gigabytes)

  
  
  
  
  
• DBUSRMEMORY System available memory
  
  Use transaction DBACOCKPIT or HANA COCKPIT to check the memory consumption per user. This will point out the user or users that consume most system resources.

  When using this sensor you may soon notice that it is the system users that are the top consumers. To rule them out, simply set the sensor long text settings. The long text settings can be used to specify which users are system users to be ignored for this sensor (e.g. SYSTEM_USER:SAP_SYSTEM).
  
  

  Parameter	Description
  COUNTED	COUNTED:Y KPI is number of measurements
  REPORT	REPORT:SAPMSSY1 Select specific main program
  SUMMED	SUMMED:Y KPI is sum of all measurements
  TCODE	TCODE:FP04 Select specifiec transaction
  TOP	TOP:25 show the first n results (default 25)

  
  
  
  
  
• DBSTATEMENT Expensive statements
  
  Use transaction DBACOCKPIT or HANA COCKPIT to check expensive statements. These are the sysyem top 2000 (or so) statements that consume most resources. An excellent pointer towards root cause analysis for performance issues.
  
  

  Parameter	Description
  TOP	TOP:10 show the top n results (default 25)
  TOTAL	TOTAL:Y KPI calculation on full top n results

  
  
  
  
  

Fingerprint data comparison

System landscapes surrounding S/4 Hana system(s) are commonly linking up with other systems. And whether this is Sales Service Cloud or Successfactors or any other system, systems that work together will share data.

Fingerprint data comparison is a mini framework for the comparison of the data that is expected to be aligned between different systems. Data is crunched into a compact MD5 encrypted format (small, secure) and made available in the central checking system (S4 Hana). The checking is regularly executed and the sensorboard reveals what mismatches and missing entries are found.

The concept is explained in detail - following an example.

An example business case

At myCompany.Pro we host several systems that use roles or relations that determine what a person is allowed to do from some web portal. Some of this is used to determine authorisation for portal functions, some of this is used to limit the selection of data to ensure it is relevant to the requestor (portal user).

For this business case, we mention SSC (Sales Service Cloud) as the source of the data. Then CDC as the main hub for role data - as acces point to check authorisation. And the S/4 Hana backend system which holds the data as relations.

So effectively: when a new person is added to SSC, the role of the person is first determined. SCC information is then replicated to CDC and S/4 Hana, where it lands as role information (CDC) and relations (S/4 Hana). The assumption now is that the 3 separate forms of role/relation information (referred to as data) is the same in all three systems. Whenever something changes with the data - these changes should be reflected in all 3 systems, where SSC is leading.

The step plan approach - for digital fingerprint checks

• Determine the key for data comparison.
  For this example, the Person number is used as landscape-wide person key field. Checks are done for data for the person.
• Determine the data to be compared.
  For this example: the data to be compared is all roles/relations which are valid the moment the check is performed.
• Ensure key and data align for all involved systems. Uniformly.
  For this example: the Person number is to be represented in a uniform manner. E.g. without leading zero’s. The role data would lead to a series of codes. These codes are to be represented in a uniform manner, for which a translation table is likely to be required. The data should match exactly - to enable compariron.
• Group the data fields into a single string. Uniformly.
  The (all) fields to be checked should be grouped together into a singlulare value (e.g. a string). The sequence of possible fields is important here. With or without spaces is not too important - as long as it is done uniformly for all involved systems. Duplicate spaces are removed (leaving single spaces available).
• Hash the above results into a hashCode, using the well known MD5 method.
  MD5 is a common and widely used way to create a hashcode for a string value. A hashcode is a 16 or 32 character hexadecimal code that operates as a fingerprint on the data it hashed.

• The information captured with type, key and hash is now composed for the full set of (unarchived) persons for each system and made available on the system of comparison.
• The system of comparison can be any system and does not even have to be one of SSC, CDC or S/4 Hana.
• The key elements of this comparison source is the data key and the hash code, which is an Person number and a hash code for this business case. But it could also be a company or an order.
  Note that the system that would perform the comparison will store/hold the data.
  Note that the system that holds the data - will also automatically clear the aged version of that (fingerprint) data. Thus fingerprint data is only available in the latest version.

The information on the interface will hold only Person number and a hashcode. Information that reveals no relevant detail other than a list of active Person numbers. When it is stored in the system of comparison (the system that will compare all supplied sources) a few more key fields will be added. The source system and the type of data - which will make the setup scalable to other comparisons.

With all fingerprints gathered in a single system, the comparison can be executed. This will capture the differences in data. This will also capture the Person numbers that may be missing - in other systems. In the proposed solution this will be captured in a (one) sensor type on the sensorboard, the FINGERPRINT sensor.

Then there is the scalability. Where this business case example involves 3 systems for role data, the source of record one of these systems. The same setup (based on the same framework) can also be used for other control data, other systems involved. The source of record for the control data can differ per comparison. Fingerprint comparison captures control data essence in a 32 character GUID code created from however much control data. It ensures control data is aligned and stays aligned - through your system landscape.

So to summarize: the mechanism requires all involved parties (systems) to deliver fingerprints of their control data. Where differences arise the data-consistency breaches are spotted and alarm bells can be set to ring. The purpose here is to detect and not to correct. The hashcode fingerprint comparison mechanism is lean and secure (as no actual data can be extracted from it). The mechanism can be used for different sources, different types of control data and in different directions.

• FINGERPRINT Fingerprint comparison
  
  The sensor type that can be used to report on comparison results between source and target. Simple in essence, flexible in use. Typically implemented in pairs: one with a source and target and another one with source and target swapped around.

  Parameter	Description
  DATING	DATING:31, the past 31 days including today The DATING parameter is used to select which comparison pairs are processed. Actual comparison is done with all available data - thus also information that is not within DATING range.
  LOAD	LOAD:Y KPI is calculated as all checked results (match, mismatch and missing combined) - the positive KPI This KPI can be used in combination with DATING, to ensure the feeds are being delivered. Without it the reported results could seem to be positive where in reality no checks are done as no check information is delivered.
  MISMATCH_ONLY	MISMATCH_ONLY:Y KPI is calculated as available as mismatch source and target
  MISSING_ONLY	MISSING_ONLY:Y KPI is calculated as available in source missing in target

  
  
  
  
  

The fingerprint framework

The framework for fingerprint data checking can be seen as "separate to the sensorboard framework" but it does contain the FINGERPRINT sensor type. As it is a small setup, it is described as sensor type documentation here. Consider this the technical design revealing technical components, which are already installed with the sensor board framework.

Data model

Fingerprint comparison - header
zfingerprint_hdr(id(i4), source(c30), type(c20), date, time)

Fingerprint comparison - item hash
zfingerprint_itm(id, key(c16), hash(c32))

Every time source data is delivered, from a PC file, a server file or a service, the information is stored in these 2 tables (only).

1. The header is added for each "data delivery".
2. The item is stored in the item table - for all data on a single delivery.
3. The framework will automatically remove the old version of item data
4. The framework will automatically remove the old header - when items are no longer available on it.

Main components

zcl_fingerprint_manager - manager class.

Class on the S4 Hana system that holds the following functionality:

1. Actual comparison functionality - where 1 source and 1 target are compared.
   This captures the following comparison results: (1) mismatches in Hash coding - “mismatch”. (2) Key available in source, not in target - “missing”.
2. Insert/update functionality on the fingerprint tables - updates to the fingerprint tables are all done in this class.
   When a new entry is added, the aged entry is looked up and automatically removed. When the last item under a header is removed, the header is automatically removed as well.
3. MD5 encryption functionality.
   The class will host compression and encryption functionality on the data to be checked. A key component here is the encryptor, a method that takes a string value and returns it’s MD5-generated GUID.

   Before encrypting the concatenated string of all involved/relevant data fields (in a predetermined sequence) duplicate spaces are removed (in Abap: condense).

4. Sensorboard sensor logic - the sensor type FINGERPRINT functionality to enable monitoring comparison issues.

zfingerprint_uploader - Upload report

Report that can upload fingerprint information - from any source. File-based and picking up information from the front-end or from the back-end.

A good thing to realize here is that the fingerprint check is mean and lean, but it should be checking full data sets leading to millions of records. File based is not necessary - but should be a supported option.

This report can be scheduled to run periodically to fetch file data that (from a single file or multiple files) was prepared by other systems. The actual data is unusable for external reading (as it only contains a key field and a hash code). The uploader report can also be instructed to delete the source file - once it was fully processed.

A clear file naming convention should be used, which will be used to determine the source and type of the upload file.

fprint-cdc-roles-20251202-0741.txt as
fprint + source system + type + date + time.

The uploader can be used for many types of data. It is versatile. Schedule it with a folder name from the server side and it will automatically process all files starting with fprint-*. Use the automatic delete option to ensure processed files are cleared off when processed.

zfingerprint_housekeeping - Housekeeping report

Cleanup functionality is automatically in place as with every bit of new data the old version is removed. This implies data can still age and the housekeeping report can target that - by deleting retired entries. Expected to be scheduled monthly.

zfingerprint_template - Data generation report

An example report that populates data for fingerprints - originating from the S/4 Hana system. This report can be used to create an actual data generator report which can be scheduled to run periodically. The output here is a file and there should be an option to output directly into the tables (for performance / ease of processing).

One thing to note here is that even though the actual comparison is done in S4 Hana, the source of record of the control data could be another system. So to create a suitable set of fingerprint data from the data on S4 Hana, actual codes in that data may still need to be mapped to the control data on the source of record. E.g. a type=Z00001 in S4 Hana where it's counterpart is type=AB04 in Sales Service Cloud. The fingerprint data should be composed with mapped/translated values.

Also: the reason also supporting output to a file is that the system that should perform the checks does not need to be the S/4 Hana production system. With this option in place the necessity of utilizing the live S4 Hana system for checking is gone. As the success of the framework is directly linked to the table consumption - there is always the option to move (all or part of the) checks to the acceptance system.

FINGERPRINT Sensor type

Counters and difference reporting is captured in the fingerprint sensortype. In sensor type settings, the comparison pair is defined as a set of (2) sources. A sensor will monitor the system compare for 2 sources and a single role. The KPI is the number of mismatches. Detailed overview will show the key and type of mismatch (mismatch or missing).

Where more than 2 sources are involved, multiple sensors are used, for each separate comparison.

Example: Roles: [Sales service cloud] + [CDC] + [S/4 Hana] would be presented in 3 sensors (all the same sensor type) as

1. [Sales service cloud] with [CDC]
2. [CDC] with [S4 Hana]
3. [S4 Hana] with [ Sales service cloud]

1. [Sales service cloud] with [CDC]
2. [CDC] with Sales service cloud]
3. [CDC] with [S4 Hana]
4. [S4 Hana] with [CDC]
5. [S4 Hana] with [Sales service cloud]
6. [Sales service cloud] with [S4 Hana]

1. [Sales service cloud] with [CDC] - Mismatches
2. [Sales service cloud] with [CDC] - Missing entries
3. [CDC] with [Sales service cloud] - Mismatches
4. [CDC] with [Sales service cloud] - Missing entries
5. … (you'll get the point)

1. KPI for mismatches only or for missing in target only
2. KPI as total matches (the positive KPI)
3. DATING parameter, which will only perform the comparison if fingerprint information is available within the specified period of time. The comparison itself is allways done using all available data. This will hide aged mismatches.

Open SQL selection

Any selection that can be executed in the SQL console of Eclipse, can also be executed in this sensor. The sensor will report on the results and determine what the KPI value should be.

As this sensor should support multiple selections, the setup caters for NAME-usage, which should alway be filled in. Thus: the NAME parameter should be set.

• SQL SQL selection
  
  A simple selection like SELECT * FROM T000 would already be sufficient to make this sensor work. The sensor KPI would be the number of entries on T000 and the first 8 columns of this table would be listed as sensor detailed output.

  The sensor long text plays an important role in using this sensor. Make sure you check the explanation on the sensor long text, which is available from a button on the sensor settings. It explains all details.

  This is the most versatile sensor the board holds. It can capture any selection or any result(count) that can be captured in an SQL selection. This includes JOIN or CDS view selections. Don't underestimate this sensor. It can capture the logic from several other sensors.

  Example 1: minimal

  As a minimalized example, a single-line selection is done on the T001 table, which holds the company codes that are set up for the system.

  	SELECT mandt, bukrs, butxt from t001 
  	

  Note that the client (mandt) needs to be specified (or set in selection) for client-dependant tables.

  To apply this selection to the sensor, simply create a sensor from Sensor settings. Select a group and fill in SQL for the Sensor type, press enter. If this sensor is already available, consider copying it.

  The sensor text for this sensor should be edited, as per example:

  	/: T001
  	*  This sensor lists the T001 entries / companies.  
  	/: SQL
  	*  SELECT mandt, bukrs, butxt from t001 
      

  To use the sensor, set it's parameter to:

  	NAME:T001
  	

  When the sensor is executed, the KPI will be set to the number of selected entries and the sensor content will show a table with MANDT (Client), BUKRS (Company code) and BUTXT (Company description) of all the available clients. Adjust the selection to the required client:

  	SELECT bukrs, butxt from t001 where mandt = '120'
  	

  Or using the current (logon) client

  	SELECT bukrs, butxt from t001 where mandt = @SY-MANDT
  	

  Note that the KPI is delivered as the number of selected records.

  The result will use the field names as column title. You can change these through alias by using an AS, like so:

  	SELECT bukrs as company, butxt as description from t001 
  	

  An you can also specify your own names, using the COLUMNS settings, like so:

  	/: T001
  	*  This sensor lists the T001 entries / companies.  
  	/: SQL
  	*  SELECT mandt, bukrs, butxt from t001 
  	/: columns
  	*  MANDT:Client
  	*  BUKRS:Company code
  	*  BUKTX:Description
      

  Multiple clients

  When you are using a system with multiple clients (ignoring client 000), the selection on tables with CLIENT or MANDT should cater for this. Simply add the client field to the selection and use @sy-mandt for the current client.

  SELECT bukrs, butxt from t001 
    where mandt = @sy-mandt
      

  The sensor will warn about this - when omitted.

  Example 2: using a result counter

  If one of the fields is named RESULT, this will be used to determine the selection KPI. To demonstrate, we will use the DBTABLOG table (always packed with data).

  	SELECT count( distinct tabname ) as RESULT from DBTABLOG 
  	

  This selection will return a single counter which will be recognized as the sensor KPI.

  Another example using counters:

  	select tabname, count(*) as result
        from dbtablog
        group by tabname
      

  This will compose a KPI for the total number of records on DBTABLOG, with detailing to the counters on the table per tablename.

  Example 3: involve date and time

  Sensors often use DATING and TIMING to limit the selection to a specified period of time. If the results should be for the past 10 days only, the SQL selection can be adjusted to:

  	select tabname, count(*) as result
        from dbtablog
  	  where logdate IN DATING
        group by tabname
      

  Parameters on the sensor should then specify DATING, like so:

  	NAME:DBTABLOG-EX3;DATING:10
  	

  The sensor will apply this to the selection and report the results.

  The same setup can be applied as TIMING for time fields:

  	select tabname, count(*) as result
        from dbtablog
  	  where logdate IN DATING and logtime IN TIMING
        group by tabname
      

  Parameters on the sensor should then specify DATING and TIMING, like so:

  	NAME:DBTABLOG-EX3;DATING:0;TIMING:3
  	

  Example 4: involve parameter(s)

  The sensor selection can be specific to a company code or any other selectable value, which can be used to create similar (but not the same) sensors. Use the P1 and P2 parameters to accomplish this.

      select tabname, count(*) as result
        from dbtablog
  	  where tabname = '@P1'
        group by tabname
      

  The parameter setting for this selection could be

  	NAME:DBTABLOG-EX3;P1:MARA
  	

  Parameter	Description
  DATING	DATING:31, the past 31 days including today
  NAME	Specify the name of the query The sensor settings for the SQL sensor type can hold many SQL scripts and descriptions. To use one on a sensor, the NAME must be specified.
  P1	Free-format selection parameter (1) The parameter parameters P1 and P2 are applied to the SQL selection clause. This can be used for a company code (value) or other specifics on the selection. Uppercased only (as it is a sensor parameter settings).
  P2	Free-format selection parameter (2)
  TIMESTAMP	TIMESTAMP:Y, apply DATING as a timestamp In some tables there is no actual date or time, but a timestamp is used instead. This indicator instructs the sensor to apply the DATING setting as a timestamp.
  TIMING	TIMING:120, the past 2 hours

  
  
  The helper report ZSENSOR_REP_SQL for this sensor type
  
  
  
  
• SQLINDX SQL indexing
  
  This is largest sensor in coded logic. It is designed to determine a growth-index on a KPI, measured over a period of time and the same period before that time. KPI measurements from the 2 periods are compared and the growth or shrinkage are displayed as a percentage (either positive or negative). Much like the AEX-index.

  The versatility of this sensor is the fact that the KPI selection can be done in open SQL - so you get to decide what is being indexed. Factors at play:

  • KPI calculation results are to be made available in a column named RESULT.
  • The KPI can be a count, but also a value (or sum of values).
  • To determine a period, there should always be a date on the selection. Option IN DATING should be used (once) on a relevant date (mostly the create date).
  • Whenever the date is used (without time), the current date is not selected. This will have an effect on sensors that are refreshed all day - as these will return the same information all day.
  • When in addition to a date (e.g. create date) a time is also available, the sensor will become near-real-time. The period is calculated from the current time, as reported on the sensor. This is the preferred way of using the sensor.
  • Sensor parameters should include DAYS or HOURS (or both), which is a requirement on determining the selection periods.

  The sensor long text plays an important role in using this sensor. Maks sure you check the explanation on the sensor long text, which is available from a button on the sensor settings. It explains all details.

  Example 1: minimal

  To clarify how this sensor works, let's go through an example. Table DBTABLOG holds table changes for a wide variety of changes. Let's assume this is interesting information - as it "shows system activity", which can be interpreted as "In business as usual".

  An SQL selection would be required, with an outcome (KPI) on a selection that involves a date:

  	  SELECT count(*) as RESULT from DBTABLOG 
  	    WHERE logdate IN DATING
  	

  In this example the RESULT and IN DATING segments are needed to link the selection results to the sensor. The "IN DATING" part is not standard SQL (it was cooked up by the creator of the sensorboard).

  The above selection can be implemented on the sensor longtext. To do this, the selection would require a name, an optional description and the SQL selection. This would look like this:

  	/: TABLOG-ACTIVITY
  	*  This sensor measures the number of changes logged on the DBTABLOG 
  	*  table, as an indication of system activity. 
  	/: SQL
  	*  select count(*) as RESULT from DBTABLOG 
  	*    where logdate IN DATING
  	

  The sensor can now be set up for the above selection. Go to sensor settings, on the Sensors tab, select a group and fill in Sensor type SQLINDX, press enter. If it already exists, consider copying it. The parameters on this sensor require NAME and DAYS (or HOURS). In our example, set the sensor parameter to:

  	NAME:TABLOG-ACTIVITY;DAYS:10
  	

  The sensor is now ready to be used. It will:
  • Execute the selection for LOGDATE = 10 days ago until (and including) yesterday for period T
  • Execute the selection for LOGDATE = 21 days ago until 11 days ago - for period T-1
  • Report on the results where T-1 and T selections are shown together
  • Calculate the deviation percentage from period T-1 to T - as KPI percentage with 3 decimal positions

  Example 2: involve timing

  The most up-to-date index results can be determined when time is available. Applied to our example:

  	  SELECT count(*) as RESULT from DBTABLOG 
  	    WHERE logdate IN DATING and logtime IN TIMING
  	

  This will change the selection setup quite a bit. It will involve the time in such a way that link date and time together. So when IN TIMING is used with DAYS:1 (or HOURS:24) and the current time is 13:15, it will select data from yesterday 13:15 until today 13:15.

  Note that the date and time information that is used for the selections is reported on the sensor.

  Example 3: add columns

  In the above example, the outcome of the selection is a single counter. It is however also possible to involve other columns - elaborating on where the counter information comes from. To demonstrate this, the table name is involved. Counter results will be grouped by this table.

  	  SELECT tabname, count(*) as RESULT from DBTABLOG 
  	    WHERE logdate IN DATING and logtime IN TIMING
  		GROUP BY tabname
  	

  The effect of this will be that more information is revealed on the sensor report. To take this a bit further, let's also add the description of a TABNAME:

  	SELECT log~tabname as table, DT~ddtext as description,
        count( * ) as result
        FROM dbtablog as log
         LEFT OUTER JOIN DD02T as DT on DT~tabname = log~tabname and
           DT~ddlanguage = 'N' and DT~as4local = 'A' and
           DT~as4vers = 0000
        WHERE log~logdate IN DATING and log~logtime IN TIMING
        GROUP BY log~tabname, DT~ddtext
      

  Note: the LEFT OUTER JOIN is used, because not all table descriptions are available in English (and the selection outcome should not be influenced when a description is missing).
  
  

  Parameter	Description
  DAYS	DAYS:3, period in days from yesterday
  HOURS	HOURS:3, period in hours from last hour
  NAME	Specify the name of the query Mandatory, as many queries can be specified on the sensor type settings.

  
  
  
  
  

Queues

Work that can't be processed immediately can be processed from a queue. So whenever the job to be done gets somewhat serious, the workload is captured in a queue and processed from there.

The system has many variations on these queues. The amount of work that is being piled up on the respective queues - can become a concern. One thing to remember here is the simple fact that the use of queues relieves the system from having to do it immediately.

Getting started

The sensors on this chapter are all about queues, which has a strong relation to interfacing. To set up a group for this on the sensorboard is easy to do, but it is also already prepared for you.

Download: queue-sensors.json

The json file contains a group with all the sensors for queues - as described on this page. They are layed out for you to use immediately. Simply upload the file onto the board which will create the QUEUES group filled with sensors.

Fixer reports

The FXR reports use a small framework class for application logging and fixer-common operations. You will need to implement this before you can implement the fixer reports mentioned below.

Download: helper class ZCL_SENSOR_FIXER

For new fixer reports, a template report is available:

Download: report ZSENSOR_FXR_TEMPLATE

• SMQ1 Outbound tRfc queue
  
  

  Queue entries can be faulty or unprocessed for a long time. Both potential issues can be monitored with this sensor.
  
  

  Parameter	Description
  DATING	DATING:2, the past 2 days
  DEST	DEST:XXXCLNT300, focus on specific destination(s)
  NOTREADY	NOTREADY:Y, focus on the errors (not status READY)
  QNAME	QNAME:BW*, focus on specific queues
  QNAME-RV	Selection with a range variable (see sensor type RANGES)
  RETENTION	RETENTION:Y, count only expired calls This is the setting that will change the way the sensor operates. Other parameters are no longer used when this parameter is set. With RETENTION:Y the sensor will involve the sensor long text settings, which should hold retention periods. The KPI becomes "retired calls" and a fixer report can automatically delete them.
  TIMING	TIMING:120, the past 2 hours

  
  
  
  
  

  This sensor has autofix support. The sensor long text can be used to determine what the retention period for selected queues should be. Calls that are older than the retention period can automatically be deleted with report ZSENSOR_FXR_SMQ1. Download: fixer report SMQ1 The sensor (type) settings for the sensor are used to capture what the sensor fixer (FXR) should do. Only Entries with AUTOFIX:Certified will be processed.

  
  
  
• SMQ1LONGEST Outbound tRfc queue
  
  

  When a queue holds old information that is not processed, processing the information may no longer be relevant. This sensor focusses on the oldest queue entries.

  When old entries are left unattended, there is the risk they would get reprocessed. Reprocessing old queue entries is much like going back in time. The subject of these queue entries may have been sent out again (and again) after failed message.
  
  

  Parameter	Description
  DATING	DATING:2, the past 2 days
  DEST	DEST:XXXCLNT300, focus on specific destination(s)
  DEST-RV	Selection with a range variable (see sensor type RANGES)
  QNAME	QNAME:BW*, focus on specific queues
  QNAME-RV	Selection with a range variable (see sensor type RANGES)

  
  
  
  
  
• SMQ2 Inbound tRfc queue
  
  

  Queue entries can be faulty or unprocessed for a long time. Both potential issues can be monitored with this sensor.
  
  

  Parameter	Description
  DATING	DATING:2, the past 2 days
  NOTREADY	NOTREADY:Y, focus on the errors (not status READY)
  QNAME	QNAME:BW*, focus on specific queues
  QNAME-RV	Selection with a range variable (see sensor type RANGES)
  RETENTION	RETENTION:Y, count only expired calls This is the setting that will change the way the sensor operates. Other parameters are no longer used when this parameter is set. With RETENTION:Y the sensor will involve the sensor long text settings, which should hold retention periods. The KPI becomes "retired calls" and a fixer report can automatically delete them.
  TIMING	TIMING:120, the past 2 hours

  
  
  
  
  

  This sensor has autofix support. The sensor long text can be used to determine what the retention period for selected queues should be. Calls that are older than the retention period can automatically be deleted with report ZSENSOR_FXR_SMQ2. Download: fixer report SMQ2 The sensor (type) settings for the sensor are used to capture what the sensor fixer (FXR) should do. Only Entries with AUTOFIX:Certified will be processed.

  
  
  
• SMQ2LONGEST Inbound tRfc queue
  
  

  When a queue holds old information that is not processed, processing the information may no longer be relevant. This sensor focusses on the oldest queue entries.

  When old entries are left unattended, there is the risk they would get reprocessed. Reprocessing old queue entries is much like going back in time. The subject of these queue entries may have changed in the mean time.
  
  

  Parameter	Description
  DATING	DATING:-2, anything older than 2 days
  QNAME	QNAME:BW*, focus on specific queues
  QNAME-RV	Selection with a range variable (see sensor type RANGES)

  
  
  
  
  
• SM58 Rfc queue
  
  

  Queue entries can be faulty or unprocessed for a long time. Both potential issues can be monitored with this sensor.

  This sensor needs a bit of extra attention, when it comes to parameter settings. The sensor will focus on the full queue (a table with messages) where the SM58 transaction only works with part of that queue. To momic the output of transaction SM58:

  1. Add parameter DATING:365 to make it look back a full year
  2. Add parameter STATUS-RV:SM58_STATUS to involve a RANGES parameter
  3. Go to the RANGES sensor and add this:

     	/: SM58_STATUS
     	*  DESCRIPTION: SM58 status selection (to exclude RECORDED records) 
     	*  E,EQ,RECORDED
     	

  4. Check the sensor results against the SM58 transaction results (e.g. for a given date).
  
  
  

  Parameter	Description
  DATING	DATING:2, the past 2 days
  STATUS	STATUS:SYSFAIL Use specifically for a given status
  STATUS-RV	Selection with a range variable (see sensor type RANGES) Set the range variabele to E,EQ,RECORDED to mimic the output of the SM58 transaction. This transaction only reports the errors and active calls.
  QUEUE	QUEUE:DRF_REPLICATE Use specifically for a given queue
  QUEUE-RV	Selection with a range variable (see sensor type RANGES)
  TIMING	TIMING:120, the past 2 hours

  
  
  
  
  
• SM58LONGEST Rfc queue
  
  

  When a queue holds old information that is not processed, processing the information may no longer be relevant. This sensor focusses on the oldest queue entries.

  When old entries are left unattended, there is the risk they would get reprocessed (even by accident). Reprocessing old queue entries is much like going back in time. The subject of these queue entries may have changed in the mean time.

  There is a report that can be used to remove aged entries, which should be handled with due care. Check out RSTRFCQD - as per suggestion on the sensor report.
  
  

  Parameter	Description
  DATING	DATING:2, the past 2 days For this sensor, the DATING parameter should be set to 365 days, or more.
  STATUS	STATUS:SYSFAIL Use specifically for a given status
  STATUS-RV	Selection with a range variable (see sensor type RANGES) Set the range variabele to E,EQ,RECORDED to mimic the output of the SM58 transaction. This transaction only reports the errors and active calls.

  
  
  
• SM59 Rfc connection
  
  

  The system will have RFC destinations that need to be up and running. Transaction SM59 houses functionality to test this, which is also captured in sensor type SM59. Effectively, this is a sensor that will perform a PING to check whether the receiving RFC destination is available.

  There is a report that can be used perform the test. Check out RSRFCPIN which is also called from the SM59 transaction.

  When CALL_FUNCTION_OPEN_ERROR or CALL_FUNCTION_SEND_ERROR dumps appear, you should consider setting up a sensor for the RFC destinations that is used. The ST22 dump should show a code or variabele ad DESTINATION for a CALL FUNCTION. Find out what the value is and look it up in transaction SM59. If it's there, you found the RFC destination. Test the connection in SM59 or put it on a sensor.
  
  

  Parameter	Description
  DEST	The RFC destination (mandatory) The RFC destination from SM59 must be supplied here. Note that the RFC destination can be a lowercased value. The value that is set as parameter value on the sensor is always an uppercased value. The sensor will find it.

  
  
  
• SMICM HTTP queue
  
  

  ICM keeps a close eye on the HTTP queues that are operational. This sensor reflects the results from the SMICM monitor as a sensor, with the number of available queues as it's KPI.

  Use the (only) parameter to present the KPI as a percentage, where the measured peek value is compared to the maximum available value (threads, connections, queues or all combined).
  
  

  Parameter

  Description

  PERCENTAGE

  KPI as percentage (THREADS/CONNECTIONS/QUEUES/COMBINED) The KPI is the number of threads from the SMICM transaction main overview. But the overview also reveals information on peak counts and maximum values, which can be presented as a percentage. E.g. PERCENTAGE:THREADS will make the sensor report it's KPI as percentace "peek over maximum". Ensure you adjust the sensor UoM accordingly (to %). The option COMBINED calculates the average percentage over the 3 value-sets.

  
  
  
  
  
• SWEQADM Workflow event queue
  
  

  Workflow events can be set up to execute immediately or via a queue. The event queue should be processed in full which can take a while when the system is busy. In addition to that the processing of an event can throw an error, which will show on the queue. This sensor keeps a close eye on the event queue.

  Old events could no longer be relevant for processing. Hence this queue (like many other queues) should be kept clean and fresh. Consider deleting the old entries - once the risk of reprocessing them is too high.
  
  

  Parameter	Description
  DATING	DATING:2, the past 2 days
  TIMING	TIMING:120, the past 2 hours

  
  
  
  
  



• STRUST Certificates
  
  

  Transaction STRUST holds the system certificates - which are sort of essential for systems to connect.

  A certificate in the context of SAP (especially as managed in transaction STRUST) is a digital document used to establish secure communication and prove the identity of systems or users. It contains a public key and is issued by a trusted entity called a Certificate Authority (CA).

  This sensor lists the available certificates and determines its KPI by counting the certificates which have an end date in the "lookout period". Set the LOOKOUT parameter to the number of days to look forward. The sensor is thus aimed at the certificates which need attention: certificates with an end date coming soon.
  
  

  Parameter	Description
  DETAILED	DETAILED:Y show more details
  FORGET	Forget about expired certificates after n days
  LOOKOUT	LOOKOUT:15 certificates that expire within 15 days

  
  
  
  
  

Save space

An S/4 Hana database is superfast because of clever architecture (column based), it caters for working with multiple processors (even within a single selection statement) and it operates from memory. Operation from memory with a backup to disk - is costly. Thus removal of data that is no longer needed, is a way to save money and energy and the environment. These are a set of sensors that keep you informed on where table space can be saved.

These sensors target the most common standard SAP tables that hold change logs, processing logs and tables that contain information that is also applied somewhere else (e.g. Idocs). This in itself holds a lot of knowledge in the system. Which tables are about change documents ? What report is available to clear aged documents ? These are all part of the sensors.

There is an overview sensor and there are detailed sensors which also have a FIXER or FXR report. A fixer report will take care of clearing old data for a retention period.

Fixer reports

The FXR reports use a small framework class for application logging and fixer-common operations. You will need to implement this before you can implement the fixer reports mentioned below.

Download: helper class ZCL_SENSOR_FIXER

For new fixer reports, a template report is available:

Download: report ZSENSOR_FXR_TEMPLATE

The fixer reports perform the actual cleanup actions - and are clearly separated from the sensorboard. Where the board functions as reporter/notifier, the fixer can perform actions. The fixers that are available here can or should be scheduled once a day or once a week. Schedule a single job with all fixer operations, which will produce a step-list like so:

Example steplist on which all required fixer jobs are defined

Once the fixer jobs are up and running, the sensor settings control what the fixer jobs do. And a lot of preperation for this can be skipped, when using this group with prepared sensors:

Download: saver-sensors.json

The json file contains a group with all the saver-sensors - as described on this page. The SAVER_ALL sensor holds sensor text settings that contain detailed information about tables, relations between tables and standard SAP cleanup reports that can be (are) used by the fixer reports. Use the sensor editor to upload the file into your sensorboard.

The sensors

• SAVER_ALL Overview of space saver candidates
  
  Today's information will inevitably age until it is no longer relevant at all. This sensor composes a list of database consumers (tables) with record counts and storage size. For each of the subjects (e.g. Change Documents, Idocs) a retention period can be defined. The sensor calculates the amount of storage Mb's that have aged, forming the sensor KPI.

  The SAVE_ALL sensor should be used as an overall trigger. Add your own tables by filling in the sensor settings text. Use transaction DB02 on your system to find the top consumer tables - and decide how long the information is required.

  With every reported subject, the report that can be used to perform housekeeping cleanup actions is also mentioned as a hint. So to action the savings, start scheduling jobs.

  Simply stop hanging on to aged data.

  As this sensor relies on quite a suite of table settings to be available on the sensor long text, a lot of effort goes into finding the tables, determining suitable retention periods and also pinpointing the reports that will help clear retired data. Below you will find a .JSON file with these settings. When new candidates are found, they will be added here. All you need to do is upload this JSON file and a MONEYSAVER group will be created with a sensor of type SAVER_ALL.
  
  

  Parameter	Description
  DETAILED	DETAILED:Y for extra columns (maintenance)
  KPI	KPI:MB shows KPI as Mb
  TABLE	For specific table name

  
  
  
  
  

  The going price for an Mb is a fixtional 10 cents per month (adjust to what your company is paying). Every month. And not just on the production system.
  
  
  
  

• SAVER_BAL Business Application Log
  
  Business Application Logs (transaction SLG1) hold processing logs. Not just for errors, these logs are created by numerous processes. This sensor focusses on these logs, per object. A retention period can be applied, per object. And a FIXER report is available for this sensor. Simply schedule report ZSENSOR_FIXER_SAVER_BAL to automatically follow up on the AUTOFIX option on this sensor.
  
  

  Parameter	Description
  AS_PRICE	AS_PRICE:Y show KPI as price
  DETAILED	DETAILED:Y for extra columns (maintenance)
  MIN	MIN:1000 (default) the minimal number of logs per object This can be used to focus on the more relevant objects (as the small ones are omitted).

  
  
  
  
  

  This sensor has autofix support. The sensor long text can be used to determine what the retention period for selected types should be. Results that are older than the retention period can automatically be deleted with report ZSENSOR_FXR_SAVER_BAL. Download: fixer report SAVER_BAL The sensor (type) settings for the sensor are used to capture what the sensor fixer (FXR) should do. Only Entries with AUTOFIX:Certified will be processed.

  
  
  
• SAVER_BCS BCS Business Communication Documents
  
  The BCS system captures documents of many types, from a variety of applications. It could hold anything from abap-produced report to Excel file to powerpoint presentation or flat data file. Usually documents that could also be available as a file. Table SOFFCONT1 is the main table for size concerns.
  
  

  Parameter	Description
  AS_PRICE	AS_PRICE:Y show KPI as price
  DETAILED	DETAILED:Y for extra columns

  
  
  
  
  

  This sensor has autofix support. The sensor long text can be used to determine what the retention period for selected documents should be. Results that are older than the retention period can automatically be deleted with report ZSENSOR_FXR_SAVER_BCS. Download: fixer report SAVER_BCS The sensor (type) settings for the sensor are used to capture what the sensor fixer (FXR) should do. Only Entries with AUTOFIX:Certified will be processed.

  
  
  
• SAVER_CD Change documents
  
  Change documents hold change logs. These are created for numerous objects, standard SAP and custom build. This sensor focusses on these logs, per object class. A retention period can be applied, per object class. And a FIXER report is available for this sensor. Simply schedule report ZSENSOR_FIXER_SAVER_CD to automatically follow up on the AUTOFIX option on this sensor.
  
  

  Parameter	Description
  AS_PRICE	AS_PRICE:Y show KPI as price
  DETAILED	DETAILED:Y for extra columns
  MIN	MIN:1000 (default) the minimal number of entries per object

  
  
  
  
  

  This sensor has autofix support. The sensor long text can be used to determine what the retention period for selected documents should be. Results that are older than the retention period can automatically be deleted with report ZSENSOR_FXR_SAVER_CD. Download: fixer report SAVER_CD The sensor (type) settings for the sensor are used to capture what the sensor fixer (FXR) should do. Only Entries with AUTOFIX:Certified will be processed.

  
  
  
• SAVER_DBTLOG Table change Log
  
  The DBTABLOG table holds change logs for tables, applied whenever the table is updated. This sensor focusses on these logs, per logged table. A retention period can be applied, per logged table. And a FIXER report is available for this sensor. Simply schedule report ZSENSOR_FIXER_SAVER_DBTLOG to automatically follow up on the AUTOFIX option on this sensor.
  
  

  Parameter	Description
  AS_PRICE	AS_PRICE:Y show KPI as price
  DETAILED	DETAILED:Y for extra columns
  MIN	MIN:1000 (default) the minimal number of change logs per object

  
  
  
  
  

  This sensor has autofix support. The sensor long text can be used to determine what the retention period for selected documents should be. Results that are older than the retention period can automatically be deleted with report ZSENSOR_FXR_SAVER_DBTLOG. Download: fixer report SAVER_DBTLOG The sensor (type) settings for the sensor are used to capture what the sensor fixer (FXR) should do. Only Entries with AUTOFIX:Certified will be processed.

  
  
  
• SAVER_IDOC Idocs
  
  Inbound and outbound Idocs are created and processed, after which they become disposable. This sensor focusses on Idocs, per message type. A retention period can be applied, per message type. And a FIXER report is available for this sensor. Simply schedule report ZSENSOR_FIXER_SAVER_IDOC to automatically follow up on the AUTOFIX option on this sensor.
  
  

  Parameter	Description
  AS_PRICE	AS_PRICE:Y show KPI as price
  DETAILED	DETAILED:Y for extra columns
  MIN	MIN:1000 (default) the minimal number of idocs per message type

  
  
  
  
  

  This sensor has autofix support. The sensor long text can be used to determine what the retention period for selected documents should be. Results that are older than the retention period can automatically be deleted with report ZSENSOR_FXR_SAVER_IDOC. Download: fixer report SAVER_IDOC The sensor (type) settings for the sensor are used to capture what the sensor fixer (FXR) should do. Only entries with AUTOFIX:Certified will be processed.

  
  
  
• SAVER_SPOOL Printer output
  
  Printed output is maintained in an elaborate setup which works with spools. It supports many types of output which could be sent to a printer, but it does not actually need to be printed. For example a batch job can produce a report a mile long, which is accessible for the job as a print spool. Print spools (transaction SP01 are normally cleared from the system within weeks or a month.
  
  

  Parameter	Description
  AS_PRICE	AS_PRICE:Y show KPI as price
  DETAILED	DETAILED:Y for extra columns

  
  
  
  
  




This sensor has autofix support. The sensor long text can be used to determine what the retention period for selected spools should be. Results that are older than the retention period can automatically be deleted with report ZSENSOR_FXR_SAVER_SPOOL. Download: fixer report SAVER_SPOOL The sensor (type) settings for the sensor are used to capture what the sensor fixer (FXR) should do. Only entries with AUTOFIX:Certified will be processed.

• SAVER_WF Workflows
  
  When a workflow or seingle step task completes it's processing, it becomes disposable. Workflows and their containers should never be the single source of information. The container is designed to reference existing documents and carry content that is relevant to the flow itself. As the workflow ended (status COMPLETED) it can be removed (with transaction SWWL). This sensor focusses on workflows, per workflow ID and/or single step task ID. A retention period can be applied, per workflow or task. And a FIXER report is available for this sensor. Simply schedule report ZSENSOR_FIXER_SAVER_WF to automatically follow up on the AUTOFIX option on this sensor.
  
  

  Parameter	Description
  AS_PRICE	AS_PRICE:Y show KPI as price
  DETAILED	DETAILED:Y for extra columns

  
  
  
  
  

  This sensor has autofix support. The sensor long text can be used to determine what the retention period for selected workflows should be. Results that are older than the retention period can automatically be deleted with report ZSENSOR_FXR_SAVER_WF. Download: fixer report SAVER_WF The sensor (type) settings for the sensor are used to capture what the sensor fixer (FXR) should do. Only Entries with AUTOFIX:Certified will be processed.

  
  
  
• SAVER_RESULT Overview of savings (historic)
  
  The space-save operations that are executed through the sensorboard fixer reports are also measured. Measurement results are accumulated into a table (ZSENSOR_GRIPSLOG) from where the information is reported on this sensor. Typically information only, a warning level or error level should never be applied on this sensor.
  
  

  Parameter	Description
  DATING	DATING:120, the past 120 days
  DETAILED	shows data per table (KPI in Mb)
  KPI	KPI:MB shows KPI as Mb

  
  
  
  
  

Locks and updates

Any updates need to be locked and the actual update process (database process) can fail leaving update errors.

Getting started

The sensors on this chapter are all about locks and updates which involve continuous daily processing. To set up a group for this on the sensorboard is easy to do, but it is also already prepared for you.

Download: lock-sensors.json

The json file contains a group with all the sensors for this - as described on this page. They are layed out for you to use immediately. Simply upload the file onto the board which will create the LOCKS group filled with sensors.

The sensors

• SM12 Locks
  
  The system hosts a locking mechanism that ensures our updates are protected. In extreme cases, there can be so many locks generated by some update process, that the locking mechanism itself needs attention. Are old locks released ? Is some automated process claiming too much ?
  
  

  Parameter	Description
  USER	USER:DDIC Show only for specific user
  USER-RV	Selection with a range variable (see sensor type RANGES) This can be used to filter out system users, which are expected to work with higher lock counts.
  AS_MAX	AS_MAX:Y Determine the maximum number of locks by 1 person This will change the sensor function from guarding the total number of locks to focussing on the top consumer. Note that the USER and USER-RV parameters are best combined with the AS_MAX parameter.

  
  
  
  
  Transaction SM12 reveals more detailed information on locks.
  
  
• SM13 Update failures
  
  A database update is a series of events that should lead to your changes being applied. The database should accept the changes - which is not always possible. An update error queue is available for this. Some errors can be reprocessed from the queue.
  
  

  Parameter	Description
  DATING	DATING:2, the past 2 days
  TIMING	TIMING:120, the past 2 hours
  USER	USER:DDIC Show only for specific user
  USER-RV	Selection with a range variable (see sensor type RANGES)

  
  
  
  
  Transaction SM13 reveals more detailed information on update errors.
  
  
• SM13LONGEST Oldest update failure
  
  It is good practice to clear the SM13 queue regularly. If this is not done, there is a change that an update error is reprocessed long after it's relevance sell-by date. The update would be done on a document that may have been updated since the update error. This sensor warns about old (aged) update errors.
  
  
  
  Transaction SM13 reveals more detailed information on update errors.

Idocs

It's becoming a bit old-fashioned, but Idocs or Intermediate Documents are a common means to interface data (documents) between systems.

The Idoc processes has 3 sensors in it's sensor-suite. One for change pointers - effectively a triggering mechanism for outbound Idocs. One for inbound Idocs and one for outbound Idocs. There is also a sensor on the space that the Idoc system consumes (SAVER_IDOCS) - see Save space save money.

Getting started

To monitor Idocs, a lot of preperation for this can be skipped, when using this group with prepared sensors:

Download: idoc-sensors.json

The json file contains a group with the main (3) Idoc related sensors - as described on this page.

The sensors

• BD21 Change pointers
  
  Checks the queue of change pointers.

  Change pointers can be set based on e.g. change documents, to ensure that relevant updates are sent out as outbound Idocs. It's a queue and queues should be processed. The sensor gives an insight on what is in the queue. Transaction BD21 is available on this.
  
  

  Parameter	Description
  DATING	DATING:2, the past 2 days
  MAXCOUNT	MAXCOUNT:2500 (default), the limit on the BDCP2 table, shows warning
  TIMING	TIMING:120, the past 2 hours

  
  
  
  
  
• BD87INB Inbound Idocs
  
  Checks the Idocs that are sent out from the system.

  The inbound Idocs, or Idocs that are presented to the system, should be processed into actual documents. Whenver this fails, the sensor will respond. Transaction BD87 shows Idoc traffic and status (for both in- and outbound Idocs).
  
  

  Parameter	Description
  DATING	DATING:2, the past 2 days
  MSGTYP	Specific to a message type, like MSGTYP:MATMAS
  MSGTYP-RV	Selection with a range variable (see sensor type RANGES)
  ALL	ALL:Y to select all Idocs, not just faulty ones
  TIMING	TIMING:120, the past 2 hours

  
  
  
  
  
• BD87OUTB Outbound Idocs
  
  Checks the Idocs that are sent to the system.

  The outbound Idocs, or Idocs that are pushed out of the system, should be created when relevant (e.g. triggered by change pointers). Whenver this fails, the sensor will respond. Transaction BD87 shows Idoc traffic and status (for both in- and outbound Idocs).
  
  

  Parameter	Description
  DATING	DATING:2, the past 2 days
  MSGTYP	Specific to a message type, like MSGTYP:MATMAS
  MSGTYP-RV	Selection with a range variable (see sensor type RANGES)
  ALL	ALL:Y to select all Idocs, not just faulty ones
  TIMING	TIMING:120, the past 2 hours

  
  
  
  
  

Users

The system is a servant to it's users. The sheer number of (dialog) users that are active on the system can itself become a concern. Especially when some of them run heavy reports.

The sense of how crowded the room is (was) during the day is a good indication on why the system seems slower. Thus an active sensor logging (with logging switched on) on this topic, is a nice to have you should have. The SUIM sensor will cater for this.

Emails

The system can compose and send out emails to notify users (or other receivers). When the system fails to deliver, the sensor can make users aware.

• SUIM User activity
  
  Checks the number of active users.

  A system is sized on the number of users. Serving users is the system's main task. One can imagine that serving 100 users or 1000 will make a huge difference in required CPU time (and memory). This Sensor keeps track on active users. When KPI logging is switched on for this sensor, a measurement on how many users the system is serving during the day is available.
  
  

  Parameter	Description
  CLASS	CLASS:SCC-EXTERN Select only users form a group
  CLASS-RV	Selection with a range variable (see sensor type RANGES)
  DIALOG	DIALOG:Y Select only dialog users
  USER	USER:DDIC Show only for specific user
  USER-RV	Selection with a range variable (see sensor type RANGES)

  
  
  
  
  
• SUIMHISTORY User history
  
  Focus on the user ID's that have not been used for a longer period of time - which are also flagged as inactive. Users which have an end-date in the past.
  
  

  Parameter	Description
  CLASS	CLASS:SCC-EXTERN Select only users form a group
  CLASS-RV	Selection with a range variable (see sensor type RANGES)
  DATING	DATING:-90, up to 90 days ago This is where you decide how long it takes for a user to become historic.
  DIALOG	DIALOG:Y Select only dialog users
  USER	USER:DDIC Show only for specific user
  USER-RV	Selection with a range variable (see sensor type RANGES)

  
  
  
  
  
• SUIMSLEEPERS Inactive users
  
  Focus on the user ID's that are no longer used. This sensor identifies potential candidates that can be removed from the system - which saves licence costs.

  User ID's that have not been active for a longer period of time could lead to an overhead of licence costs. The inactive users or sleeping users sensor reports on the users with their last login date. Especially dialog users that have not logged on can be considered inactive.

  Use the parameters to specify how many days you regard as "enough to be a sleeper", e.g. 180 or 365 days. If you know what licence costs per user apply, this sensor can be set up to report actual saving costs (use parameter FEE:35 for this - when a user licence fee is 35 euro). Parameters can also be used to focus on a user class or only dialog users.

  The sensor determines up to 3 dates:

  1. The date that user was added to the system.
  2. The date the last user activity was measured, on a table - this is explained below.
  3. The date the user last logged on.

  The date the user was created will always be available, the other dates can also be blank. A background user can't log in, but a background user can temporary be a dialog user. And the activity determination does not necessarily pick up on all user activity.

  Measure the last user activity

  The Inactive users sensor can detect user activity by selecting the most recent create or change date on a table. The most common tables for this are the Change Document log (table CDHDR) and the Business Application Log (table BALHDR). Your own choice of tables can be added to this setup, through sensor longtext settings. Here's how it works:

  The sensor can be provided with the following info:

  • Table name
  • Field name for the user ID
  • Field name for the date to be checked
  • Optional field name for the client, if it is not called MANDT.

  The sensor will use this information to effectively perform a selection of the most recent available date on the system. Multiple tables can be added, which will make the sensor look for the most recent activity date on the combined tables. The result is a single date for the user.

  Check the sensor longtext settings for details on how to add table information. This text will show the following example:

  /: CDHDR/USERNAME/UDATE/MANDANT

  The sensor will pick up on this and report it as settings on the sensor. What the sensor will to with this is execute the following SQL query:

  SELECT username as USER, max( UDATE ) as LAST_ACTION  
    from CDHDR 
    group by username
  

  Note that the fieldnames and table name are applied from the sensor text settings (CDHDR, USERNAME and UDATE). Results will be returned like this:

  USER	LAST_ACTION
  MAASDAMW	2025-03-12
  MOONSY	2023-12-02
  MUNSTER	2025-01-21

  Sensor logic will compose these results for multiple selections and merge them into a single result holding the last action dates. Any table which holds a user name and a create or change date can be used to capture activity.
  
  

  Parameter	Description
  CLASS	CLASS:SCC-EXTERN Select only users form a group
  CLASS-RV	Selection with a range variable (see sensor type RANGES)
  DATING	DATING:-90, up to 90 days ago
  FEE	FEE:25 Monthly licence fee (euro) If you want the KPI to show what savings are applicable here, just supply the montly licence fee.
  TYPE	TYPE:A Select only dialog users (A,B or S)

  
  
  
  
  
• ZOMBIES Offboarded user activity
  
  When users leave the project or company, the offboarding procedure should take care of user access on the systems. The ZOMBIES sensor checks whether this was successful.

  The sensor takes some settings, to identify the user and the active until date for the user. A list of users can be specified. What the sensor does is look for proof on the tables, that should prove the user is really inactive. From change documents to application logs, or really any other table (with a user id and a date) can be used for this.

  The most common issue that can show up here is the batch jobs that were scheduled by the user that is offboarded. Net result of the zombies sensor is proof that offboarding was completed. Throughout the landscape.
  
  

  Parameter	Description
  USER	USER:DDIC Show only for specific user
  USER-RV	Selection with a range variable (see sensor type RANGES)

  
  
  
  
  Settings from the SUIMSLEEPERS are used for this sensor. The reason for this is that the sleepers functionality also searches the system for the latest changes.
• SOST Outbound emails
  
  The sensorboard relies on email itself as well. A mail notification should be sent out to the subscriber of a sensor group when one of it's sensors turns red. This sensor monitors failing outbound email messages.

  It is also possible to utilize this sensor on inbound emails. Set the DIRECTION:R parameter for this.
  
  

  Parameter	Description
  DATING	DATING:2, the past 2 days
  DIRECTION	Set DIRECTION:R for inbound emails
  MAXCOUNT	MAXCOUNT:50000 (default), the limit on the SOOS table, shows warning
  OPTION	OPTION:HISTORIC for an historic overview, longer period of time
  TIMING	TIMING:120, the past 2 hours

  
  
  
  
  Transaction SOST reveals more detailed information on sending emails.

Seperation of duties

The SOD sensor can be used to target authorisation-assignment mishaps, by testing user authorisation combinations.

Check for sensitive combinations

1. A group is created, for which authorisation checks (Object + Parameter + Value) can be added.
2. Each group holds 2 or more checks.
3. The checks on the group are tested for every user.
4. At least one of the checks should fail - to avoid violations.
5. When a user is authorized for all the authorizations on the group - the violation is a fact.

Feeder for the SOD sensor

The feeder report ZSENSOR_FDR_SOD does the heavy lifting for the SOD sensor results. It picks up sensor settings from the SOD sensor and uses this together with the selection screen settings to create a Business Application Log with potential violations.

Download: feeder report SOD

The feeder report is required to feed the sensor. And the sensor logic itself is not part of the standard sensors suite, hence the following class also needs to be implemented to make the SOD sensor available on the sensorboard.

Download: SOD sensor class

Transaction codes

/: DEVELOPERS
*  DES:Things developers should not all be able to do
*  OBJ:S_TCODE
*  PAR:TCD=SM31
*  OBJ:S_TCODE
*  PAR:TCD=SM24
	

Companies and salesareas

And another thing: the feeder report can be scheduled to run several times with several variants. Duplicate violations will be removed on the sensor KPI calculation.

Download: sensor class ZCL_SENSORS_SEPERAT_OF_DUTIES

• SOD Seperation of Duties
  
  Reports on the results from the sensor feeder report ZSENSOR_FDR_SOD which populates a Business Application Log with processing results.
  
  

  Parameter	Description
  DATING	DATING:5, the past 5 days
  TIMING	TIMING:120, the past 2 hours

  
  
  
  
  

Workflow

Workflow processes run well if everything is set up and operational. There are background tasks that need to be scheduled, there is a queue for events that controls processing and individual work items could end in error without anyone noticing.

• SWI1 Workflow work items in error
  
  This sensor checks for workflow work items in the Error status - which will stop the workflow. Check out transaction SWI1, SWI5 or SWI6.
  
  

  Parameter	Description
  DATING	DATING:8-1, 7 days up to yesterday
  TIMING	TIMING:120, the past 2 hours

  
  
  
  
  
• SWI1ACTIVE Active workflow work items
  
  This sensor checks for active workflow work items in a normal status. These are sitting in someone's inbox waiting to be processed. Check out transaction SWI1 or SWI6.
  
  

  Parameter	Description
  DATING	DATING:-30, up to 30 days ago This will focus on active workflows that have been active for more than 30 days.

  
  
  
  
  
• WORKFLOW Workflow operations
  
  There is a small suite of batchjobs that should be up and running for Workflow to be operational. These jobs (or rather job steps) are checked here. This sensor reports on the batch job steps that are not executed regularly - which will affect the Workflow system.
  
  
  
  
• SWEQADM Workflow event queue
  
  

  Workflow events can be set up to execute immediately or via a queue. The event queue should be processed in full which can take a while when the system is busy. In addition to that the processing of an event can throw an error, which will show on the queue. This sensor keeps a close eye on the event queue. Check out transaction SWEQADM.
  
  

  Parameter	Description
  DATING	DATING:2, the past 2 days
  TIMING	TIMING:120, the past 2 hours

  
  
  
  
  

Printer output

Printer output or spools can accumulate as output from batch jobs that are not necessarily printed.

• SP01 Printer output
  
  An overflow of spool output can become quite an issue for the system, as all processes that generate spool output will be affected. This sensor reveals the state of affairs on printer output - with errors.

  The PAGECOUNT parameter can be set to select larger spool outputs. E.g. PAGECOUNT:500 will also list any spools (printer output) that are larger than 500 pages.
  
  

  Parameter	Description
  DATING	DATING:30, the past 30 days
  PAGECOUNT	Selection of large spool files through page counting, PAGECOUNT:250 This will focus on larger prints.
  TIMING	TIMING:120, the past 2 hours

  
  
  
  
  Transaction SP01 reveals more detailed information on spools.

Number ranges

SAP and any other database system has dealt with number ranges since forever. Number ranges control what the next order number should be, when created through a BAPI or API or through whichever available means. Ranges have a starting point, an endpoint and a current value. When the highest value of a number range has been consumed - no new numbers will be available.

• SNRO Number ranges
  
  The number range sensor will check all number ranges on the system. It determines which of the ranges are "getting close" to their respective high values. The KPI for this is expressed as a percentage.

  The sensor longtext caters for settings that can be used to ommit a number range object from the checks. And a sensor parameter can make the sensor focus on a specific number range, to make it relevant specifically for a certain process.
  
  

  Parameter	Description
  OBJECT	OBJECT:FAA_AS91 for a specific object This will make the number range check specific to a number range object, e.g. for documents that are relevant for a certain department.
  OBJECT-RV	Selection with a range variable (see sensor type RANGES)

  
  
  
  
  Transaction SNRO reveals more detailed information on number ranges.

Tables

Home of data.

This sensor has focus on tables, record counts, size and growth.

• TABLES Table information
  
  Every bit of information is held on a table. The S/4 Hana database is one that grows and grows with every minute of every day.

  The TABLES sensor type keeps track of the tables of your choice. The sensor long text holds information on which table to track. The sensor produces a report of the settings and a report with the focussed tables. It calculates the number of entries and the estimated size on the database (occupied memory space, disk space is ignored here). The sensor settings can be used to specify what maximum table size is acceptable. When this maximum is breached, the sensor KPI is increased (by 1).

  For tables with a creation date, it is also possible to specify a maximum table growth. Specify which field is the (create) date on the table and how many days the check-period should be. The sensor will determine record counts for 2 periods (T-1 and T) and calculate the growth percentage. A growth spike can be measured on the sensor, on any (transparent) table the system uses.

  To check these tables, transaction DBACOCKPIT or DB02 can be used, or SE16 and SE16N, SE17 or the SQL console or Data preview in Eclipse.
  
  

  Parameter	Description
  INCLUDETODAY	INCLUDETODAY:Y Include today for deviation calculation
  TABLE	For specific table name

  
  
  
  
  

Files and folders

Each application server lives on a file system, which will have a limited space for it's files and folders. So what would happen if this file-space runs out because large files are created ? The application server would be stopped. Hence the FILES sensor was made available.

• FILES Files
  
  This sensor checks a series of file-related measurements. Settings for this are captured in the sensor long-text, which can hold details on multiple groups.
  
  For this sensor to work, the folders that need to be checked should be set in the sensor long-text. This is done "under an ID". The ID specifies the group to be checked and the details that should be checked. The sensor can then be added to the sensorboard. If the sensor is created without ID: parameter, all checks that don't have SKIP:Y will be checked.

  If the sensor is used to monitor a certain process, an ID for this process can be added and the Sensor will focus only on the given ID.

  For each folder several measurement points can be checked.:

  • MAXFILECOUNT - for the maximum number of files that are expected in the folder
  • MAXTOTALSIZE - for the maximum total filesize on the folder
  • MAXFILESIZE - for the maximum allowed size of a single file

  • SUBDIRECTORYLEVEL - Can be used to specify the number of subdirectory levels should also be checked.

  Use transaction AL11 to find details on the server folders and files.
  
  

  Parameter	Description
  ID	For specific ID (as specified on sensor longtext)

  
  
  
  
  
• ST06SPACE Server space
  
  This sensor checks the available space on mount-locations available to the (application) server. These locations add up to a total storage capacity and all locations should have space available. The highest occupance percentage is also the sensor KPI.
  
  

  Parameter	Description
  ID	For specific ID (as specified on sensor longtext)

  
  
  Transaction ST06 reveals more detailed information on available space.
  
  

Housekeeping

The system relies on housekeeping actions to clean up on data that is no longer required. Old logs for batch jobs, dumps from over a month ago, Idocs which have been processed into actual documents a long time ago. It is easy to overlook these steps, as they cause no immediate harm. Until they do.

There are many cleanup jobs available as delivered by standard SAP. These sensors see to these jobs getting scheduled.

A custom setup that produces data, should also be set up to clear this data. House keeping on custom tasks can be added to these sensors.

• REPORT Submit a report and show the detail
  
  The sensor type REPORT allows you to run any report and shows simplified output on a sensor. Often enough the reports that should perform housekeeping tasks have a "test" flag. This flag will perform a full selection and tries to find which objects are to be fixed or even removed. Having a test flag also means the report does not do updates.

  With sensor type REPORT a sensor can be set up to look out for housekeeping tasks when they appear. It works with any report output, whether it is classic lists (WRITE) or ALV (which is transformed to classic list output).
  
  

  Parameter	Description
  REPORT	Report name (mandatory)
  VARIANT	Variant name (mandatory)
  SKIP	SKIPT:3 skip the first n lines
  SKIPEND	SKIPEND:2 skip the last n lines

  
  
  
  
  
• AIF AIF housekeeping
  
  This sensor ensures that a set of AIF related housekeeping jobs are scheduled. Check the sensor itself for a listing of these jobs.
  
  
  
  
• SYSTEM System housekeeping
  
  This sensor ensures that a set of general system housekeeping jobs are scheduled. Check the sensor itself for a listing of these jobs.
  
  
  
  
• CUSTOM Custom housekeeping
  
  This sensor ensures that a set of general customer housekeeping jobs are scheduled. Check the sensor itself for a listing of these jobs.
  
  
  
  
• SAPAPO APO housekeeping
  
  This sensor ensures that a set of SAP APO housekeeping jobs are scheduled. Check the sensor itself for a listing of these jobs.
  
  
  
  
• WORKFLOW Workflow housekeeping
  
  This sensor ensures that a SAP's Workflow housekeeping jobs are scheduled. Check the sensor itself for a listing of these jobs.
  
  
  
  
• SM35 Batch input housekeeping
  
  This sensor determines the amount of space that is occupied by batch input recordings and logs that are produced with the use of transaction SM35. There is a report available to clean this up - all standard.
  
  
  
  
• SM37CLEANUP Batch jobs housekeeping
  
  This sensor determines the amount of space that is occupied by batch jobs and logs that are produced with the use of transaction SM37. There is a report available to clean this up - all standard.
  
  
  
  

Transports

Heart of the deployment mechanism in SAP.

This sensor reports on recent imports, with focus on errored imports.

• STMS Imported transports
  
  The sensor that hosts functionality that can be useful on the whole landscape, when development projects are ongoing.

  The STMS sensor type keeps track of imported transports, whether the inport was successfull or not. The focus could be on errored transports, but the setup can also be used to "be informed" of changes becoming available.

  As the sensor KPI is not necessarily indicating a problem, note the following: this sensor should only be set up with an error level - when the option ONLY_ERRORS:Y option is set.
  
  

  Parameter	Description
  DATING	DATING:2, the past 2 days
  ONLY_ERRORS	ONLY_ERRORS:Y, show errors only
  SYSTEM	The target system for the transports

  
  
  

  Inform subscribers for groups

  Import of transports which is completed successfully, does not reflect an error-situation. The sensor KPI is thus in fact nothing concerning - but still good to know. If the project team is insterested in a daily overview of transport moves - the "Inform subscribers for groups" option.

  Here's a step-plan on how to do this:

  1. Create a group, call it TRANSPORTS (as example).
  2. Add the sensor (or multiple sensors) to the group.
  3. Specify on the sensor that it should report on today's transports only (DATING:0) or today and yesterday. Align with requirements (and make sure nothing is missed).
  4. Schedule a ZSENSOR_ENGINE run the moment you want to be informed. The option "Inform subscribers for groups" should be selected here.

     Suggested time would be in the morning so you are informed what was "moved" the day before. Make sure the option "Only KPI with value" is ticked on - to avoid emails being sent out when no transports were imported.

  5. Make sure the interested users are subscribed to the group.

  The result is that users will receive an email in the morning, stating transports were moved the day before. When these users visit the sensorboard, the sensor(s) on the board will show a detailed overview of the transports.

  In addtion the sensors can be visited ad-hoc as well, which will reveal the imports that were performed during the day - as well.
  
  

Development only

The sensorboard is not just for production systems. The board is available on all systems on the landscape and sensor settings can be moved around (to and from production). Some sensors are for the development system only. Think of a playground setup, from a class in the $TMP development class.

These are the sensors that can only be applied on the development system. On subjects that make no sense to monitor on acceptance or production.

• ZONE Zone documented objects
  
  

  Welcome to the Zone - home of reusable (custom) components - packed with extra live details.

  The Zone (transaction on the development system) holds the overview of custom coded components, classes, reports, function modules, tables and service definitions. Once the development community is used to working with the Zone - which acts as an interactive news paper - sensor type ZONE can be used to inform on recent changes.

  Is your development community unfamiliar with the Zone ? It is made available with the rollout of the sensorboard. The components from the sensorboard itself is already listed (but can also be removed).
  
  

  Parameter	Description
  DATING	DATING:2, the past 2 days
  ONLY_ERRORS	ONLY_ERRORS:Y, show errors only
  SYSTEM	The target system for the transports

  
  
  
  
  

Self service

The sensorboard is a sub-system that itself could run unto some trouble. The board is set up to refresh every 20 seconds or so - for the end user. But the actual sensor updates are processed from a batch job, that should be up and running for the board to work. A sensor - for the sensorboard itself.

• SENSOR Self service
  
  The self service sensor ensures the board is operational. This implies that sensor KPI values are updated regularly, but also that emails are being sent out when applicable. The sensor will gather potential problems and report on them.

  As the main engine behind the sensor framework is a batch job, elaborate reporting on what each available batch job is tasked with is reported on this sensor.

  Note tbat this sensor is also executed when the ZEN transaction is started. Whenever this sensor errors, it is visible in the selection screen of transaction ZEN.

  The sensor self-service sensor is embedded in the framework as it deserves a "special place".

  There are a few settings that are applied on the sensorboard, which are customizable for the whole framework. These are:

  1. The background image of the sensorboard, which covers the whole sensorboard (unless dark mode is selected). (BACKGROUND)
  2. The location of the manuals, which is accessible from the Sensor editor (DOCUMENTATION and DOCUMENTATION-DETAIL)
  3. The names of batchjobs that perform sensor-related tasks, such as board feeder jobs (job feeder: a report that is scheduled to follow-up on the content of a sensor, so-called automatic fix jobs). (BATCHJOBS).
  4. As the sensor board is composed in HTML relying on CSS settings, custom settings can be added or existing settings can be overwritten. (CSS).

  These settings are covered/explained in the sensor long text for the Self-service sensor (SENSOR).

  Note that the self-service sensor also shows an overview of all available sensor types and an indication on their usage or usage count.
  
  
  
  

• SUBSCRIBE Subscribers for groups / shared inboxes
  
  This sensor is all about subscribers. Whenever a group has sensors that can reveal an error, there should also be a subscriber that will get the notification. The SENSOR sensor type also checks this, for priority P1 groups. This sensor elaborates on subscribers, revealing all users and email addresses for the whole board.

  The SUBSCRIBE sensor is also the home for shared inbox details. SAP users can subscribe and unsubscribe any group, for which the user is notified via his/her own email address (SU01D). however when shared inboxes are used, there will be no SAP user available for this. To tackle this, user id ZEN_USER_01 is available (and 02 and ...). Details on the shared inbox (name and email address) can be set up on the sensor long text and is reported on this sensor.

  External users can also have multiple emails thus multiple receivers.

  The sensor delivers on transparency - as it produces a report which lists all sensorboard receivers with name and email address. A private address should stand out.
  
  

  Parameter	Description
  GROUP	GROUP:SYSTEMHEALTH focus on specific group
  PRIORITY	PRIORITY:P1 focus on groups with a specific priority

  
  
  
  
  
• RANGES Range variables - values
  
  The sensors on the board can be fine-tuned through parameter settings. A sensor that can check something for all available information, can thus also be set up to check a more select selection. The most common candidate for this is the user ID. A sensor which lists a user ID in it's output, can probably be linked to a range variabele which will make the sensor work only for a select group of users (like everyone from a department).

  Ranges are selection definitions in which "a selection range" can be specified. A brief example to demonstrate:

  Sign Option Low      High    Description
  I    EQ     BROWN            Include values EQual to BROWN
  I    EQ     RED              Include values EQual to RED
  I    BT     X        ZZ      Include values BeTween X and ZZ
  E    EQ     YELLOW           Exclude values EQual to YELLOW
  E    CP     P*               Exclude values Containing Pattern P*
  

  Multiple lines can be set up for the range variabele. Sensors that use these range variables will also report on the usage.

  The RANGES sensor holds information that is used for other sensors. Range variables are used to feed -RV parameters, such as USER-RV. With a range variabele, a set of selection values can be supplied. This will make the sensor use only a small set of users, or even exclude some users.

  Use it to fine-tune your sensors.

  This sensor does not have any parameters. It does host a ZSENSOR_REP_RANGES report which lists the available settings in an orderly manner.
  
  
  
  
  
  

• INDEXER Indexer on neighbouring sensor
  
  This sensor feeds on the logged KPI results of another sensor. With selected results, e.g. the measurements for the past month, the logged KPI measurements are gathered. The period (1 month) is split into 2 parts and the hour-by-hour day-by-day measurements are condensed into 2 average values. These values are then used to determine a growth/shrinkage percentage (like the AEX index on a company value).

  Meta-data sensor - which consumes the KPI results from another sensor. SPEEDPROBE would be a nice example for this sensor type.
  
  

  Parameter	Description
  DATING	DATING:2, the past 2 days
  LOGID	LOGID:412 The source sensor logging-ID An alternative way to determine the source sensor for indexing. A LOGID can be found on the sensor in table ZSENSORS.
  SENSOR	SENSOR:SPEEDPROBE The sensor for which indexing is required The referenced sensor can be identified with the sensor type name. If the sensor is available multiple times (in the same group), the LOGID can be used to uniquely identify the source sensor.
  TIMING	TIMING:120, the past 2 hours

  
  
  
  
  

• ECHO Echo sister sensor - KPI checking
  
  Sensors on the sensorboard host a warning limit and an error limit. It is generally assumed the higher the reported value, the bigger the issue. But what if values should hover in a range. Or what if the moment a KPI value breaches a value (either though increase or decrease) as KPI trigger ? Use ECHO.

  The sensor reports on KPI fluctuations and settings - based on rules. The source sensor is the Sensor that is places to the left of the ECHO sensor. Hence: a sister sensor.
  
  
  
  

• RATING Average rating from 1-10 for the group
  
  This sensor feeds on the logged KPI results of all other sensors in the group. That is - sensors that have an errorlimit. It will check the KPI values, warning limits and error limits from the sensors of a group and calculate a rating. The KPI for this sensor is the average rating for the other sensors.

  The calculation is done as follows:

  • KPI values below the warning limit are presented as rating=10 (of 10).
  • KPI values higher than the error limit are presented as rating=1 (of 10).
  • KPI values between warning limit and error limit are calculated as the linear calculation formulea:

      rating = 10 - 9 * 
        ( ( KPI - warninglimit ) / ( errorlimit - warninglimit ) )
    

  
  
  

  Parameter	Description
  DEFCON	DEFCON:Y use the DEFCON priorities (scaled as 1-5)

  
  
  
  
  

• SEARCH Search sensor reported content - for a specific word (or words)
  
  Sensors on the sensorboard each explain what happened and list details of the problem cases. This can be very useful to search on. The latests sensor reported results are stored on the database, which makes them accessible for a quick search on any word you like. Note the search field on the sensorboard itself, which uses the same principle: you supply the search word and the system lists all sensors which mention the word (case-insensitive). The SEARCH sensor does this for you - resulting in a KPI count as the number of sensors that mention your search word.

  Multiple search words ? Use the sensor longtext to specify a group of words to be monitored. All the searchwords will be checked.
  
  

  Parameter	Description
  ID	ID:HOTPOSTCODES Search through sensor report results with (all) specified searchwords
  GROUP	Focus on the sensors from a specific group
  SEARCH	SEARCH:726356 Search through sensor report results with the searchword

  
  
  
  
  
• REMOTE Remote sensorboards
  
  Whenever the sensorboard is used on multiple SAP systems, the "other" board can be checked through a sensor. The REMOTE sensor can be set up with an RFC (Remote Function Call) name of the target system.

  The sensor reports sensors in error, on the other board.
  
  

  Parameter	Description
  GROUP	Focus on the sensors from a specific group (from the remote system)
  RFCDEST	RFCDEST:SYS123 The RFC destination of the alternate system (SM59)
  SENSOR	Focus on the sensors from a specific type (from the remote system)

  
  
  
  
  
• FOOTPRINT Data footprint of the sensorboard
  
  Running the sensorboard with it's KPI logging and sensor history features consumes data. This sensor measures the sensor framework footprint and throws an error when it is getting out of hand.

  The sensorboard heartbeat job also houses housekeeping features that should be scheduled to run every now and then. Not with all heartbeat runs. But once a month would be nice. When forgotten, this sensor will feature the consumption.
  
  
  
  

• VERSION Version check
  
  The sensorboard framework components are rolled out to multiple installations at multiple customers. With it's version management sensor, it can detect the smallest of changes on the framework components that should not be changed. Why should an open source solution not be changed ? Because changes are in the way of upgrading, as a custom change would get overwritten.

  Version checking is done using a hash-technique. A GUID-like hashcode is generated for the source coding of relevant components and these are embedded into the version control class (hardcoded). This hardcoded class it itself also hashed into a code, which is available centrally. Validity of this code can be checked any time.