Welcome
- What is a sensor ?
- A use case
- Sensor states: warnings and errors
- Show the sensorboard
- Recieve an email on calamities
- Running the board
- Feature overview
Sensor settings
- Group settings
- Sensor settings
- Subscribers
- Schedules for groups
- Upload and download
Technical matters
- The framework
- Steps: add a sensor
- Parameters and sensor text settings
- The zone
- Internationalization
- oData sensor services
- Advanced topics

Show all

Welcome to the manual for

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. The manual consists of 3 main subjects:

Introduction to the setup. What is the sensorboard, what are sensor types, what are sensors, how can the sensorboard be used.
The sensor editor - where all customizing for a sensor is done.
The technical matters - with a step-by-step guide to adding custom sensor types.

The board comes with a suite of operational sensors, which are explained in Sensorboard - sensors manual.

So where did you first hear about the problem ?

That's right,
The first signs came from the sensorboard.
Which does exactly what is was designed to do.

Only minutes after it happened.

Welkom op het Sensorbord

Je hebt de handleiding gevonden bij een Nederlands- en Engelstalig sensor bord, 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 en dekt in hoofdlijnen de volgende onderdelen:

De introductie: wat is een sensor type, wat is een sensor, hoe kan het gebruikt worden en wat kun je allemaal met een sensor (bord).
De instellingen applicatie voor sensor instellingen.
De techniek - met een stap-voor-stap gids voor het maken van een nieuw sensor type.

Het sensor bord is uitgerust met een set operationele sensoren die zijn beschreven in de volgende handleiding Sensorboard - sensors manual.

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 to continuously show the latest available detail. The detail is presented as a KPI (Key Performance Indicator) number each of which which is explained in the sensor detail report.

Preview of the sensorboard with errors and warnings

An alternative view, where the sensors are compacted.

Preview of the same sensorboard - compacted

Compacted with a background image

The examples show some of the different settings the end user can select for themselves. All examples show the same sensorboard.

The product comes with a series of over 50 technical sensor types that can be customized to perform many possible sensor tasks. The framework also caters for custom sensors - which can easily be added to the board. These will most likely be sensors for functional checks. How to add a custom build sensor to the board is explained on this manual.

De gehele applicatie is beschikbaar in het Nederlands (en tegelijkertijd in het Engels).

The complete application is available in English (and simultaneously in Dutch).

Documentation is only available in English.

Manual about sensors

This is the manual for the sensorboard and framework.

There's also a manual describing the sensors.

Sensorboard - sensors manual

Feature overview

The setup of the sensorboard with groups of sensors enables organizing the board. An overview of means to organize and work with your sensors:

Organize: arrange groups and sensors

Create a group and add some sensors. The group should form a logical subject like a proces. But it can also be used as a place where sensors relevant to a department reside. Or even someone's personal preference.

It is good to realize that the same sensor can be used in multiple groups. The sensor results are determined once and applied everywhere.
The user with special requirements - can have his/her own group.
Set the sequence in which groups are displayed (Sequence on board - on the group settings).
Set the sequence in which sensors are displayed in the group (Board tile sequence - on sensor settings).
Each sensor has it's warning limit and error limit, which is set for the group. Thus a sensor that is throwing errors in one group, can be displayed without warning or error in another group. Thus: what is super important in one group, can be purely informational in another.
Each sensor has it's own parameter settings (optional) and text settings (optional). Use F4 on the parameters field to let the system inform you on the available options (specific to the sensor). And use the help button to let the system inform you on available options in the sensor long text. Again relevant to the sensor being processed.
Sensors that don't have a warning and/or error limit are still operational and still deliver an up-to-date KPI.
A sensor which is Off can still be executed. It will update it's KPI and report it's details as if it was active.

Personalize: your sensorboard

The look and feel of the board has 3 options, all available on the selection screen. Normal, Compact and Super compact.

All these options will show selected sensors in their respective groups. Even the Super compact option (which shows a sensor as a tiny colored square) works as an operational board. Click on a sensor to execute it and reveal it's details. Hover over the sensor to reveal it's title.
The "Dark mode" shows the sensorboard with a darkened background.
The selection screen of the sensorboard can be used to focus on sections of the board. Select specific groups or even specific sensors.
The other options on the selection screen, help quick focus on priority groups or only the groups to which the user is subscribed.
Once the settings are applied, all the end user needs to do is save his/her settings as a variant. This will make the sensorboard pick up on user-specific settings the next time the board is started.

Emailing and subscribers

Users can subscribe to a group (or groups).
Shared inbox users can subscribe to a group (or groups) (see sensor SUBSCRIBE for more on this).
Subscribed users receive an email on the sensor or sensors that "turn red", the moment they do
Subscribed users can also receive a regular overview with all the sensors of a group - periodically.
This feature can be used for periodic KPI overviews, e.g. analytical sensors (the AEX-like index sensors that show growth in percentage) as mail overview.
An overview of all subscriptions is available on sensor SUBSCRIBE.

To receive overviews at regular intervals

The sensorboard is not just about errors and issues. Some KPI's are used as performance indicators without ever being faulty (white sensors). To receive an email about these sensors:

Create a group and add some sensors.
The end user should subsribe to the group (subscribers can also be assigned by others).
Batchjob ZSENSORS_ENGINE is scheduled at set intervals (e.g. daily) - with option "Inform subscribers for groups (email)".
All active sensors on the group are listed in an overview mail to the subscriber(s).
For sensors that have historic data, an SVG image or images are available on the sensor. To make this available on email, the complete sensor report (including historical graphs) is attached to the email.

Keep track: sensor logging

Sensor logging can be switched on a sensor. This will log the KPI of a sensor and results will be added to the sensor detail screen.
For some sensors the behaviour of the sensor can be relevant. As sensor KPI values are often a reflection of "how bad" things are going, a view on it's historic values can be valuable. When logging is switched on, the system will monitor the KPI values and report them as a bar-chart going back up to 90 days.
The other means of sensor logging is the snapshot of sensor details. This is much more elaborate than just keeping track of the KPI value.

With the comparison report logged sensor results from 2 measurement moments can be shown side-by-side for comparison.
Find the comparison report on the sensorboard selection screen or the sensor settings editor.
Note that both these logging methods can be used on any sensor.

Secure: sensor settings - backup and move

The sensor settings application is equiped with download/upload functionality, which can be used to move your sensorboard settings to other systems (dev/test/prod).
The format used for upload/download (and backup) is JSON - which implies changes can be applied to it (if you dare).
A backup for a group or a backup for the whole board can be created - which will be stored in the database.
With the power to do upload and download also comes the power to whipe out all settings. Hence backup functionality is available for the groups and sensors (and sensor settings) of the board.
Backups can also be scheduled. The sensor engine (the background job that comes with the sensorboard) has an option to determine and store a backup for the whole board (or a specific group).
To keep things from duplicating: each backup is checked against the previous backup, to determine whether storing the new backup is really necessary.
Changes on a sensor (apart from sensor text setting changes) are logged in a BAL (Business APplication Log) logging. Which is available from the sensor settings editor. Hence changing settings is not an anonimous matter.

Running sensor checks

Sensors are checked every few minutes - which is controlled by the sensor engine background job.
When a sensor is slow, the framework ensures it is skipped in the next run.
Thus a sensor that consumes a full hour will cause the sensor engine to run at least that hour. The engine run that follows after only a few minutes will detect that the slow sensor is still being processed and skip it. Effect: slow sensors don't impact the overall board.
There is a delay setting on the sensor. This can be used to limit the number of times a sensor is checked during the day.
There is a schedule for groups. This can be used to run the sensors on a group only during office hours.
Schedules can be customized to describe a week with working times. And in addition calendar days (dates or date ranges) can be added to define a hyper-care period or christmas.
The sensor engine can be used to slice and dice job runs. This means the job can be run every 3 minutes for high priority groups and every 15 minutes for the less important ones.

Following up

To follow up on the sensor, or resolve the issue the sensor brought to your attention, every sensor will have their own steps. The sensor tile only shows the KPI, the sensor report (click on the tile, or check your email) should explain the sensor. A brief description which refers to e.g. the transaction code to check explains what the sensor measured. Most sensors also show more detailed information, often as a table, which should clarify what objects were involved in the KPI determination.

Sensors which list specific details as a table can also disclose the information in an ALV report. This can be effected from the Sensorboard by clicking ALT+click on the required sensor. Alternatively find the sensor in Sensor Settings and select the Data preview button.

To help resolve the sensor issue a reference to documentation can be set up on the sensor. Such document can describe the known issues in more detail - if needed.

Once the issue is resolved, the sensorboard can be used to check the solution. As the sensor should become green (or yellow) again. Start ZEN, find the sensor and click on it. The check will be performed again and results should help you determine whether the applied solution was sufficient.

The sensorboard also helps determine the effectiveness of the solution.

Instantly.

Censoring sensors

The power of a good sensor is that it explains what happened in great detail. Detail that can sometimes be linked to a person or data that should not become generally available to all sensorboard users. A small feature is available on the sensorboad that will hide the detailed content of a (any) sensor.

Sensors can be sensored.

A censored sensor works like any other sensor, with KPI determination and response to warning and error levels. The only thing it will not do is show the sensor detailed report, as this will state "Sorry! The detailed content for this sensor is censored.

To censor a sensor (e.g. SUIM, just add this to the sensor longtext of the SENSOR sensor type:

	/: CENSORED
	/* SUIM
	/* SUIMHISTORY
	/* SUIMSLEEPERS

The detailed content of the SENSOR shows which sensor types have been censored.

Running the board

The sensorboard comes alive with the sensor engine, a report that needs to be scheduled in the background. The engine is the heartbeat of the sensorboard. Scheduling needs to be set up with a maximum of 5 minutes interval between jobs. 3 or 4 minutes are preferred.

In extreme cases, a single sensor could consume a lot of performance. The architecture of the sensorboard caters for this: each sensor run is locked. So even if a single sensor would consume a full hour, new next sensor engine run would do it's job and skip the slow sensor (because it would still be locked).

The selection screen of the sensor engine (ZSENSORS_ENGINE)

Without the sensor engine job, the sensorboard would be fully operational. The only thing is that sensor KPI results would not be updated and emails would not be composed. The sensorboard has a self-service sensor, which checks the state of affairs with the sensor engine job. It will present itself in the selection screen of the sensorboard - when errors occur. The details on the sensor result should explain what's missing.

The main tasks for the sensor engine

The sensor engine captures all relevant tasks in a single report. Note that not all tasks should be performed every few minutes, so it is quite normal to schedule report ZSENSORS_ENGINE several times with different variants and different periodicity. The main tasks:

Sensor check heartbeat

Sensors KPI calculations are done periodically through this step. Without it, the board will show old information (and the times of last refresh will show this).
Compose and send emails

Subscribers will receive emails on the sensors that turned red - on their groups. Unless the sensor engine is not set up to do this (checkbox on the selection screen).

The available options are
1. enable emails to subscribers when sensors are set to the error state and
2. send out all sensors for a specified group to the subscribers. With this option, the receiver is informed about sensors as "weekly KPI's" or "Last month in numbers".
Detailed logging

There is an option to capture detailed logging for sensors. Individual sensor settings need to be set to allow this function to work. As detailed logging of sensors consumes table space, it is recommended to set the periodicity for this job to no more than once every 2 hours.
Check out what this is about, sensor results from the past can be compared to the current sensor results. Or 2 logged sensors can be compared (both from the past).
Housekeeping tasks

The sensorboard can compose logging tables that will need to be cleaned up periodically. This and a few other housekeeping tools are also captured in the sensor engine, which would need to run monthly.

Feeders (FDR) and fixers (FXR)

The sensorboard is a report with mini-reports that run at very regular intervals. The only updates the board will perform are re-determination of KPI values. No changes to the system are done. No automated fixes or automated preperation steps. We do however support feeders and fixers which are explained here:

Feeders are stand-alone reports that are not part of the sensorboard framework, but it uses sensor data to perform their respective tasks. The feeder (naming convention ZSENSOR_FDR_* where the * is usually the sensor type) will target a controlling sensor and create a series of generated sensors for it. The controlling sensor would e.g. report results for all companies and the generated sensors will do the same with a sensor for each company. For the top 10 available companies. This job would typically be run once or twice a day. Sensors that were created by a feeder-job will have the "BAPI" indicator set.

The idea here is that sensors can be made available based on data, rather than a lot of manual actions. The feeder.

Fixers are also stand-alone reports that target the issue that is reported on the sensor. When issues can be repaired automatically, a fixer job (naming convention ZSENSOR_FXR_* where the * is usually the sensor type) can be scheduled to run as often as needed and this job can involve the sensor details or just the sensor settings (e.g. test-settings) to perform it's task. Clean up aged loggings. Apply a targetted fix like creating a relation or deleting one. The effect will reflect the sensor KPI in the runs to follow.

The idea here is that sensors from the board are aimed at locating issues and reporting about them. But where an automated fix is possible this should be set up - separate from the board.

Sensorboard general settings

There are 2 sensortypes that are about the sensorboard itself. The Self-service sensor (SENSOR) and the Subscription sensor (SUBSCRIBE). Ideally both sesnsors are available on the board through this is not a hard-requirement. This paragraph reveals what settings they can carry - applicable to the whole sensorboard.

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

The background image of the sensorboard, which covers the whole sensorboard (unless dark mode is selected).
The location of the manuals, which is accessible from the Sensor editor

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

The subscribers of the groups are listed on each individual group (just click on the group name from the sensorboard). However The SUBSCRIBE sensor is also available - which will reveal all subscribers for the whole board. As subscribers can only be actual system users, the email addresses of these users determine where notification emails go.

With an exception: shared inboxes. To cater for shared inbox receivers (an inbox for a department or external party) - sensor settings are applied. As these settings are user by the sensorboard for the sensorboard - it is mentioned here. General sensorboard settings: external users for shared inboxes.

More on this on the manual for SUBSCRIBE.

Internationalization

Article with free download references

The full application is set up in 2 languages, for which the I18N (Internationalization) mini-framework was used. The framework caters for setting up language elements (texts) in the language of your choice by hard-coding them into the Abap logic. All applications and all standard sensors were set up in Dutch (nl) and English (en).

The big advantage of embedding text elements into coding is making it easy to apply the coding on multiple systems (without the need for a transport mechanism). The A class with sensors is effectively a single file with class definition, methods for it's sensors and text elements within the methods.

Change existing texts

If the text that is displayed on a standard sensor does not explain the issue enough, the text can be overwritten through the I18N framework. All you would need to do is find out what textpool the sensor is using (this would typically be sensor.st22 for sensor type ST22) and add your text to the textpool table.

In steps:

Determine which textpool to use for your changes (sensor.st22).
Determine which text you want to change (INFO holds the introduction text for the sensor).
Run report ZI18N_EDITOR and fill in the textpool and text. Focus on the text.
Initially nothing will be found - as the text is available as hardcoded only. From the editor, create the text.
Supply the new text and save.
When the sensor is displayed, the hardcoded texts will be ignored and the newly supplied texts will be used.
Note that the ZI18N_EDITOR application supports NL, EN, DE, IT, FR and ES.
Note that the editor also hosts download and upload functionality (as JSON).

This technique can also be used on other components of the sensorboard framework. Just find out where the text is fed into the I18N mini framework and determine what textpool name is used.

Get your own copy here. It's just a report, a class and a table.

Download: ZCL_I18N class
The framework class.
Download: Zi18n_editor report
The editor for i18n settings. Also doubles as example report on how to use the framework.
Download: ztextpool_i18n table
The definition of the textpool(s) table.

Adding other languages

To make the application available in other languages, the framework only needs it's textpool table to be filled. All applications (and sensors) will recognise which language to use from the user logon language, so when e.g. the Italian version is available it will be used.

Like the Rosetta stone in report ZI18N_EDITOR, the text for the following languages are shown in a single screen editor: NL, EN, DE, IT, FR and ES.

Check the versions overview for available translations. At the time of writing there are only 2 languages available. If and when other languages are supported, this will be implemented through a textpool which can also be made available to you.

Framework components

The mini framework for internationalization is not specific for the sensorboard. It consists of:

Class ZCL_I18N
Table ZTEXTPOOL_I18N
Report ZI18N_EDITOR

The usage of the framework is demonstrated in it's own editor. An instance of the ZCL_I18N is created, preferrably with a pool (iv_pool). The language ID's that are needed are then added to the instance of ZCL_I18N using method FEED (single text lines) or MULTIFEED (multiple text lines). It is also possible to work with the elements that are stored on the textpool table.

Whenever a text is required in the Abap coding, the get method will provide it. Texts with &-characters can be used with (up to 3) parameters.

There are also options with e.g. the plural forms of text (texts) like Apple and Apples. And texts consisting of multiple lines are also supported. Note that the editor only handles up to 3 lines. JSON upload and download or calls to FEED have no limit to the number of lines processed.

In some cases it may be useful to use the texts from multiple text pools. This can be done with FEED, consider the example:

	* Create a text container with the texts on textpool 'sensor.general'
	data(lo_i18n) = zcl_i18n=>get_instance( 'sensor.general' ). 
	* Now feed it with the texts from another pool
	lo_i18n->multifeed( zcl_i18n=>get_instance( 'sensor.specific' )->gt_texts ).	
	lo_i18n->multifeed( zcl_i18n=>get_instance( 'sensor.evenmore' )->gt_texts ).

This will only work with the texts that are stored in the textpool table. If the textpools involved share a text ID, then the ID that was first available will be used.

oData sensor services

Sensorboards can be displayed just about anywhere, through 2 services.

The board - groups with all their sensors
Single sensor execution - where a sensor is executed and the latest details are returned.

Overview of available technical objects for this:

Root custom entity Z_Sensorship with custom entity Z_Sensorship_Sensor
Root custom entity Z_Sensorship_Sensor_Single with custom entity Z_Sensorship_Sensor_Report
Implemented by class ZCL_SENSOR_MANAGER_RAP.

To utilize the setup, simple create a Service definition like this:

@EndUserText.label: 'Sensorboard RAP services'
define service Z_sensorship {
  expose Z_Sensorship               as SensorBoard;
  expose Z_Sensorship_Sensor        as Sensor;
  expose Z_Sensorship_Sensor_Single as SingleSensor;
  expose Z_Sensorship_Sensor_Report as SingleSensorContent;
}

and create a Service binding for the service definition. All of this will off course be done when the Sensorboard product is installed.

(1) Get the (full) board with groups and sensors

As example call to get an overview of the sensorboard sensors:

https://xxxxxx.dev.xxxx.nl:8020/sap/opu/odata4/sap/z_sensorship/srvd_a2x
/sap/z_sensorship/0001/SensorBoard('NL')
/Set?$select=GroupName,Title&$expand=_Sensors($select=KPI,UoM,Title,Status)

Would produce a list of the (all) available sensors. Like so:

{
  "@odata.context" : "../$metadata#SensorBoard('NL')/Set(GroupName,Title, _Sensors(KPI,UoM,Title,Status,Sensor,ParameterValue))",
  "@odata.metadataEtag" : "W/\"20250317171116\"",
  "value" : [
    {
      "GroupName" : "CONSISTENCY",
      "Title" : "Data consistentie",
      "_Sensors" : [
        {
          "Sensor" : "BUT0ID",
          "ParameterValue" : "",
          "Status" : "",
          "KPI" : 53,
          "UoM" : "duplicaten",
          "Title" : "NXR duplicaten"
        },
        {
          "Sensor" : "BUT0ID",
          "ParameterValue" : "RELATION:Z00025",
          "Status" : "",
          "KPI" : 0,
          "UoM" : "duplicaten",
          "Title" : "CloudID duplicaten"
        },
		....

Note that this call returns only a small subset of the available data, as the $select was used to specify requested fields.

Also note that filtering is available for the relevant fields (GroupName, Priority, UserIsSubscribed, Sensor, ParameterValue, Status and LogChangedRecently).

(1) Execute a single sensor and get the details

https://xxxxxx.dev.xxxxx:44302/sap/opu/odata4
  /sap/z_sensorship/srvd_a2x/sap/z_sensorship/0001
  /SingleSensor(p_groupname='SYSTEMHEALTH',p_sensor='ST22',
  p_parametervalue='',p_language='NL')/Set
  ?$expand=_Report

Which would present something very similar to

{
  "@odata.context" : "../$metadata#SingleSensor(p_groupname='SYSTEMHEALTH',
    p_sensor='ST22',p_parametervalue='',p_language='NL')/Set(_Report())",
  "@odata.metadataEtag" : "W/\"20250317171116\"",
  "value" : [
    {
      "GroupName" : "SYSTEMHEALTH",
      "Sensor" : "ST22",
      "ParameterValue" : "",
      "Status" : "",
      "KPI" : 7,
      "UoM" : "dumps",
      "Title" : "Dumps",
      "MeasurementDate" : "2025-03-31",
      "MeasurementTime" : "22:12:41",
      "StatusDate" : "2025-01-26",
      "StatusTime" : "12:44:00",
      "SequenceOnBoard" : "0410",
      "DocumentationLink" : "",
      "WarningLimit" : 0,
      "ErrorLimit" : 0,
      "CreatedByBapi" : "",
      "TrackHistory" : "",
      "Delay" : 0,
      "LogId" : 22,
      "_Report" : [
        {
          "LineNumber" : 0,
          "lineType" : "LABEL",
          "Content" : "In status sinds: Zondag 26.01.2025 om 12:44"
        },
        {
          "LineNumber" : 1,
          "lineType" : "HISTORY",
          "Content" : "22"
        },
        {
          "LineNumber" : 2,
          "lineType" : "INFO",
          "Content" : "Dumps kunnen worden getoond via transactie ST22. Deze sensor werkt met een white list"
        },
        {
          "LineNumber" : 3,
          "lineType" : "INFO",
          "Content" : "en een black list waarin specifieke dumps kunnen worden aangegeven."
        },
        {
          "LineNumber" : 4,
          "lineType" : "INFO",
          "Content" : ""
        },
        {
          "LineNumber" : 5,
          "lineType" : "INFO",
          "Content" : "De white list is voor runtime fouten die (door de sensor) genegeerd kunnen worden. Black list dumps zijn"
        },
        {
          "LineNumber" : 6,
          "lineType" : "INFO",
          "Content" : "juist heel belangerijk, omdat ze bijvoorbeeld over memory gaan."
        },
        {
          "LineNumber" : 7,
          "lineType" : "INFO",
          "Content" : "Deze sensor is voorzien van een whitelist (niet tonen) en blacklist (met prioriteit tonen)"
        },
        {
          "LineNumber" : 8,
          "lineType" : "INFO",
          "Content" : "dump selectie die is opgenomen in de sensor-tekst."
        },
        {
          "LineNumber" : 9,
          "lineType" : "MESSAGE",
          "Content" : "Er zijn 3 white-listed en 14 black-listed dump codes."
        },
        {
          "LineNumber" : 10,
          "lineType" : "MESSAGE",
          "Content" : "Dumps selectie (zonder lock) van vandaag"
        },
        {
          "LineNumber" : 11,
          "lineType" : "SUBTITLE",
          "Content" : "Overzicht per gebruiker"
        },
        {
          "LineNumber" : 12,
          "lineType" : "TABLEHDR",
          "Content" : "Telling;Gebruiker;Dialoog gebruiker"
        },
        {
          "LineNumber" : 13,
          "lineType" : "TABLELINE",
          "Content" : "4;~G009154;Ja"
        },
        {
          "LineNumber" : 14,
          "lineType" : "TABLEEND",
          "Content" : ""
        },
        {
          "LineNumber" : 15,
          "lineType" : "SUBTITLE",
          "Content" : "Overzicht van de dumps"
        },
        {
          "LineNumber" : 16,
          "lineType" : "TABLEHDR",
          "Content" : "Telling;Mandant;Dump;Prioriteit"
        },
        {
          "LineNumber" : 17,
          "lineType" : "TABLELINE",
          "Content" : "2;~120;OBJECTS_OBJREF_NOT_ASSIGNED_NO;"
        },
        {
          "LineNumber" : 18,
          "lineType" : "TABLELINE",
          "Content" : "4;~120;SAPSQL_DATA_LOSS;"
        },
        {
          "LineNumber" : 19,
          "lineType" : "TABLELINE",
          "Content" : "1;~120;SYNTAX_ERROR;"
        },
        {
          "LineNumber" : 20,
          "lineType" : "TABLEEND",
          "Content" : ""
        },
        {
          "LineNumber" : 21,
          "lineType" : "MESSAGE",
          "Content" : "Er zijn 3 dumps onderdrukt (wegens whitelist en/of blacklist met prioriteit)"
        },
        {
          "LineNumber" : 22,
          "lineType" : "SUMMARY",
          "Content" : "<hr>"
        },
        {
          "LineNumber" : 23,
          "lineType" : "SUMMARY",
          "Content" : "<section class=footer>"
        },
        {
          "LineNumber" : 24,
          "lineType" : "SUMMARY",
          "Content" : "Algemene informatie over de sensor:"
        },
        {
          "LineNumber" : 25,
          "lineType" : "SUMMARY",
          "Content" : "waarschuwing: <i>geen waarschuwingslimiet</i>,"
        },
        {
          "LineNumber" : 26,
          "lineType" : "SUMMARY",
          "Content" : "fout: <i>geen foutenlimiet</i>,"
        },
        {
          "LineNumber" : 27,
          "lineType" : "SUMMARY",
          "Content" : "sensor naam: <i>ST22 Dumps</i>,"
        },
        {
          "LineNumber" : 28,
          "lineType" : "SUMMARY",
          "Content" : "parameter waarde: <i>(geen waarde)</i>,"
        },
        {
          "LineNumber" : 29,
          "lineType" : "SUMMARY",
          "Content" : "class/methode: <i>ZCL_SENSORS_STANDARD=>SENSOR_ST22</i>,"
        },
        {
          "LineNumber" : 30,
          "lineType" : "SUMMARY",
          "Content" : "duur: <i>46ms</i>."
        },
        {
          "LineNumber" : 31,
          "lineType" : "SUMMARY",
          "Content" : "</section>"
        }
      ]
    }
  ]
}

The important thing to note here is that the sensor was executed and its renewed KPI results were logged on the ZSENSORS table. In theory (though not very practical) some external system could control when sensors are executed (and thus updated) - using this very RAP service.

What about the details (LineType)

Each sensor is a report that was composed for the sensor. Some reveal very little information, others hold a table with the used settings and another table with detailed information in up to 9 columns. The information is made available in association _Report which is composed of a series of components or lines. Each component has a LineNumber and a LineType. Make sure they are processed in the LineNumber sequence.

An overview of the line types (LineType) and their meaning:

TITLE
The title of the sensor.
Template: |<h2>{ content }</h2>|
SUBTITLE
The subtitle of the sensor.
Template: |<h3>{ content }</h3>|
INFO
Sensor general information, explaining what the sensor does and what tools are available to follow up.
Template: |not applicable|
BUBBLE
Can be ignored.
Template: |not applicable|
MESSAGE
Show a bulleted message.
Template: |<br><b>o</b> { content }|
LABEL
Show a labeled field, with field name and field value (separated by a :).
Template: |<table><tr><td style="width:80px;"></td><td class=fieldlabel>{ field }</td><td>{ value }</td></tr></table>|
LINKLABEL
Show a labeled field, with field name and field value (separated by a :). The field value is an Url.
Template: |<table><tr><td style="width:80px;"></td><td class=fieldlabel>{ field }</td>|
<td><a href={ value } target = new>{ value }</a></td></tr></table>
TABLEHDR
A table header line, with column names. A list of names separated by a ;
Template: |<table><tr><td>{ column1 }</td><td>{ column2 }<td></tr></table>|
TABLELINE
A table header line, with column values. A list of values separated by a ;
Note that numeric fields can be displayed as character fields by preceding the value with ~.
Note that a table line without column separators (;) will occupy the whole line (colspan=10).
Template: |<table><tr><td>{ value1 }</td><td>{ value2 }<td></tr></table>|
TABLEEND
End the table (mandatory).
Template: |</table>|

Advanced topics

Logging sensor KPIs

Logging the KPI results of each sensor can be switched on (and off) any time. The logging results are held on table ZSENSORLOGS. Note that the log is designed to capture deviations only, thus when a KPI value is stable the framework will only adjust the end date and end time on the log.

When logging information is available, it will be presented as SVG graphics on the sensor tile information. It can also be viewed on the sensor settings application, as ALV report. Note that the logging details are shown up to T-30 days (up to 30 days ago). There is also a T-90 days overview. Keeping records older than 90 days is only relevant if the ALV report from sensor settings is used (or if the sensor log table itself is used). Housekeeping on logs can be done in the ZSENSORS_ENGINE report. This will effect logs from all sensors.

Detailed sensor logging

The sensorboard also hosts a more elaborate logging feature: the detailed log. This logs everything from a given measurement. Detailed logs should not be composed too often, but they can be composed ad-hoc at any moment. Ad-hoc logging can be done for any sensor, directly from the Sensorboard by selecting CTRL-Click on the required sensor. This logging is done even if logging is not switched on on the sensor. Functionality is also available from the sensor settings application or from the sensor detailed comparison report. Sensors can also be flagged for "Detailed logging" on the sensor settings. This should be arranged in combination with tne sensor engine background report. The job frequency and timing determine when sensor-detail-snapshots will be captured.

The sensor comparison report is available directly from the ZEN transaction and also from the sensor settings application. Start the report, select a record and select "Compare". The selected record will be compared with a fresh run of the sensor. It is also possible to select 2 lines with historic detail and compare them with each other.

External sensorboards

1. Disclose sensor logic to an external sensorboard
The whole concept of the sensorboard originates from network sensorboards. When systems need to be monitored a network sensorboard can be used to monitor whether systems are active and responsive. The sensorboard system would be a system on it's own and not part of the system it's monitoring. With a single service (to be added to the system) the sensors that are created on this board can be disclosed to an external board. This would take the sensor board setup to higher level, also involving other systems.

2. A sensor on another board
The sensorboard is all about what is happening on a system. But what if there are multiple systems in your landscape ? Sensor REMOTE can report on the errors from the Sensorboard setup of another system. All that would be required for that is an active RFC destination. From one of the boards, other boards can be monitored.

3. The full sensorboard as oData services
The groups and sensors on the board can also be disclosed as oData service definition to SAP gateway. A RAP service is readily available for this purpose (separate paragraph on "oData sensorboard".

Generate groups and sensors (bapi)

Some (functional) sensors can be required for functional objects such as a sales organization or maybe a project. And these objects may also have a life-cycle, e.g. projects that are no longer active will no longer require a sensor. A separate report can be set up with the task of composing a list of required sensors. And also composing a list of no longer required sensors. ZCL_SENSOR_MANAGER=>BAPI_GROUP and ZCL_SENSOR_MANAGER=>BAPI_SENSOR are available for this task. This enables the sensorboard to automatically stay up to date on the actual sensors on the board. Each of which will provide up-to-date KPI's.

Example: top 10 customers

Consider this usage-example: an analytical index sensor is in place, which compares the value of sales orders created over the past 10 days to the total value of sales orders from the period of 10 days that superceded. Thus 20 days of order value information to create an AEX-index like result "+6.355 %".

The details on this sensor report a bit more in-depth data, showing the values per customer.

A batch job is created (according to the ZSENSORS_BOARD_FEEDER example report) which will run the above sensor and derives the top 10 customers with the highest order values for the last period. The batch job will remove the sensors that were created in previous runs and add the new top-ten list to the board. As this is done only once a day, the sensor framework will start executing these sensors.

The result is that the main sensor will report overall turnover progress, where the 10 sensors next to the main sensor reveals the focus on the largest customers.

Note that sensors that were created by Bapi are flagged as such. Visible in the Sensor editor.

Sensor follow-up / automatic fixes (bapi)

Where a sensor is aimed at getting details on problems, these details can also be used to fix the problems in some automated way. Thus when a sensor reports on an issue on an order, the issue could be resolved with an order change. The framework does more than just report on the problem. It can also make the list of problems available through a BAPI: ZCL_SENSOR_MANAGER=>BAPI_EXECUTE_SENSOR will execute the sensor, compose the list of errors/issues and update the system with the newly acquired KPI results. The BAPI will also make sensor details available through it's return parameters. Parameter ET_DETAILS contains a table with sensor content elements, which can be used to find reported details. Parameters ET_ALV_HEADER and ET_ALV_DATA contain a table with column headers and actual data from the sensor. Use report ZSENSORS_REPORTER to view this data. It is extracted from the last (and main) sensor results table.

The information from the BAPI can then be used as a work-list for automatic fixes. Once the fix is applied, the sensor's next run will (should) detect it's effects, which concludes the auto-fix cycle.

The standard sensor types sometimes come with a fixer report that can automatically resolve issues (often by deleting data that has gone past it's retention period). Fixer reports have a naming convention ZSENSOR_FXR_{sensortype}. Feel free to apply this naming convention on your own fixer reports.

The sensor alias

The design of a sensor and it's sensor text settings is not ideal for sensor types that have sensor-specific settings. The setup is that a parameter-string can be set for a sensor - to control deviating behaviour. These parameters are limited in size and are always uppercased. For the SQL sensor, the long text is used to describe the selection the sensor should perform. As the sensor can be applied multiple times, sensor parameters are used to select which text-set should be used.

Class ZCL_SENSORS_ALIAS is available to make 4 sensor types available as alias. They work exactly like their originals, but they have "their own" sensor long text settings. As standard (but also as example) an alias sensor is available for SM37 batch jobs, TABLES Tables, SQL SQL selections and SQLINDX SQL Index - as these are the common candidates for an alias.

Use the ZCL_SENSORS_ALIAS class as example if you need more aliasses. The naming convention for these is _2, _3 and so on.

Sensorboard CSS settings

The sensorboard is composed with an HTML page for which CSS styling was used. The tiles for each sensor have lines, a shadow, text sizes, colors and many more very customizable settings. To make changes possible, CSS script changes can be applied to the HTML template for the sensorboard. It was already possible to set a background image and it is also possible to apply other CSS related changes.

To determine what additions to apply, a web browser with a sensorboard as HTML in it should be available. As this is not available from a SAPGUI session (the "browser" as it is displayed in SAPGUI a very limited version comparing to Explorer or Chrome), a trick needs to me done to create a stand-alone HTML sensorboard. Here's how:

Run the sensorboard.
Type MOCKUP in the command box. This will trigger some hidden functionality.
The full sensorboard content will be made available on the Windows clipboard (Ctrl-C/Ctrl-V).
Create a new Notepad file and paste the clipboard content in there. Save as a .html file.

Feed the file to a browser and you can determine what you would like to adjust (Ctrl-Shift-I in Chrome for example).

To apply your settings, the SENSOR self service sensor text setting need to be changed. Just add a block to the settings, as per example:

/: CSS
*  table.sensor tr td.since { font-size:8pt;color:gray; }

The example settings will make the "12u34m" texts on the sensor tile less prominent (smaller and lighter colored).

The system will involve your settings on the sensorboard, without changing any abap coding or risking damaging the board output (which has been a delecate part of the solution).

Sensor checking in overdrive

The sensor engine architecture does not lock a program run, but it does lock a sensor check. This means that even if the sensor engine is scheduled to run every minute and the job would be scheduled three times (simultaneously), sensors would be updated very regularly and the framework would run super fast. At a heartbeat rate of 3 times per minute.

To make this a bit more practical, a heart-beat sensor engine job could be scheduled every 3 minutes. A secondary heart-beat sensor engine job could be scheduled every minute, to operate only on a predefined set of "high-priority" groups (specified on the sensor engine selection screen). One could even consider scheduling jobs with multiple steps, to make the engine perform multiple check runs per minute.

If there is a need for this speed - the architecture will support it.

We use cookies to improve your experience. By continuing, you agree to our cookie policy.

	The sensor is listed on the board, but is it not active. It will execute when clicked on - presenting the KPI results from the moment. But the scheduled updates will ignore the sensor.
	The sensor is reporting accurate KPI details, but it has no warning limit or error limit. This sensor will thus never turn green, yellow or red. It shows accurate KPI results anyway.
	Here's a sensor (these are all the same sensor, except for the last one) which has a warning limit or error limit (or both) set up. It shows as green because the KPI of 33% is less than the warning limit (and error limit). Green Sensors can turn yellow and/or red.
	Things are getting a little more serious now. The KPI is 73% which is above the warning limit (70%). No need to panic, but maybe keep a closer watch on the board.
	The sensor KPI (97%) has exceeded the error limit that was specified on the sensor. The sensor requires attention and an email will be composed and sent out to all subscribers of the group in which the sensor sits. Note that the email is composed only when the sensor is set to the error level.
	Some sensors deliver their KPI as an analytical deviation percentage, much like the AEX-index. The percentage shown can be both positive and negative. When the warning limit and/or error limit is set on this type of sensor, it will work like regular sensors.

The always up-to-date overview for system-wide health monitoring

Welcome to the manual for

The Sensorboard

So where did you first hear about the problem ?

Welkom op het Sensorbord

Manual about sensors

What is a sensor ?

Measure the system health with sensors

What?

Where?

How?

A use case

Sales order health

Sales order health - live monitoring

What can be monitored ?

Organizing sensors

Duplicate sensors

Sensor states: warnings and errors

Overview of sensor states

Priority

Show the sensorboard

The board as oData service

Receive an email on calamities

Who can receive notifications ?

Email to SAP users only (*)

Notifications to shared inboxes

Transpacency on email receivers

Feature overview

Organize: arrange groups and sensors

Personalize: your sensorboard

Emailing and subscribers

To receive overviews at regular intervals

Keep track: sensor logging

Secure: sensor settings - backup and move

Running sensor checks

Following up

Censoring sensors

Detection

Root cause

Multiple sensors

Running the board

The main tasks for the sensor engine

Feeders (FDR) and fixers (FXR)

Sensorboard general settings

Heartbeat

Self service sensor

Subscription sensor

eMail controls

Sensor settings

Sensor

Group

Group settings

Group

Sensor

Sensor type

Subscriber

Sensor settings

Fields explained

Fun(ctionality) explained

Subscribers

Priority for groups

Schedules for groups

Working hours

International operations

Upload and download

Backups for sensor settings

A backup copy

Planned backups

Editing the download

Predefined boards

Technical matters

Sensor framework

Sensor specific coding

Embedding

The sensor framework

Used techniques

SVG images

Sensor availability

Sizes and counts

Steps: add a new sensor