Welcome to the manual for

The Sensor Board

You've found the manual for the Sensor Board - home of sensors that keep an eye on details of your S/4 Hana system. The manual consists of 3 main subjects:

1. Introduction to the setup. What is the sensor board, what are sensors, how can the sensor board be used.
2. The sensor editor - effectively where all customizing is done.
3. The technical matters - with a step-by-step guide to adding your own sensor.

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

Welkom op het Sensor Bord

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:

1. De introductie: wat is een sensor, hoe kan het gebruikt worden en wat kun je allemaal met een sensor (bord).
2. De instellingen voor een sensor.
3. 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 Sensor board - sensors manual.

The Sensor Board 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 services (oData) - which can be used to project the board content and fresh sensor details just about anywhere.

An alternative view, where the sensors are compacted.

The product comes with a series of over 45 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.

What is a sensor ?

Everything is running smoothly and there are no known concerns. But on a the system as large and versatile as ours, we should be careful assuming everything is fine. How can we ensure operations are running smooth ? How can we create an overview of potential issues ?

If every room in the building has a smoke-sensor, we can assume nothing is on fire in the building. The basement could still be flooded though. Installing smoke sensors as digital sensors that monitor the state of the system - is not a new thing. In network maintenance quite a suite of commercial products is available for this. And to extend the reach of these products into a live SAP system, sensors from this board can be added.

So the main theme for a (any) sensor is the KPI. In most cases the KPI indicates something is wrong. A higher KPI number indicates a greater severity of the problem.

Measure the system health with sensors

Using this setup for a system, allows overall system health to be monitored. A digital panel with sensors that continuously perform checks is a continuous health insurance. Not just for storage space or a number range that is nearing it's upper limit, not just to ensure no mission critical jobs failed recently. Also for to check functional assumptions on the data that is being processed. Should a certain bit of information be set up on new projects ? Just set up a sensor on the number of projects that don't have this bit of information.

Sensors can be reported as a little red (or green or blue) icon. Or as a small stamp-sized summary with essential information.

Sensors are updated regularly and continuously, so the information on the sensor is up-to-date. The sensor board itself is also regularly refreshed (every 20 seconds) so the board itself is also up-to-date. Let the board do the actual checking for you.

A use case

The sensorboard is up and running and the obvious sensors are on there somewhere. The obvious sensors being the dump-counter or the number of batch jobs that failed recently. If something derails, the board will inform the subscribers for the "system health" sensors.

That's not the use-case we would like to emphasize here.

Sales order health

There is a job that checks and corrects sales orders. The job is called Z_SALESORDER_HEALTH runs every 30 minutes. The process is called "Sales order health" and a group with the same name is added to the board. The following sensors are added to the group - using sensor types that are already available (standard):

• To monitor the Z_SALESORDER_HEALTH job, a sensor is added (sensor SM37SINGLE available in the standard setup) to test some of the job specifications. In our example we want to make sure the job actually runs at least once every 2 hours, so the MAX_OFFLINE parameter (maximum number of seconds between runs) is checked.
  
  
• The job also throws a special message when a certain sales order could not be processed. A problem, but not a big enough problem to stop the whole job. A sensor is added to report on this message (sensor SM37LOGS). On the sensor settings, the number and id of the message is specified to make the sensor count the number of times the message is logged.
  
  
• Then another sensor is added - to ensure the job is not cancelled (sensor SM37).
  
  Thats 3 sensors on the batch job alone.
  
  
• The batch also triggers a step that creates a Business Application Log (BAL) and saves it. If there are no issues, this log is just for reference. But of there are errors on the log, our sensor monitor crew would like to be informed. A sensor is added (sensor SLG1) that will report on the logs with errors, specific to this process. The object and subobject for this will be specified on the sensor parameters.
  
  As you may notice by now - most of the standard sensor type have parameter settings that allow using them for a specific purpose.
  
  
• One of the sensors is for "Open SQL selections". It can be used to specify an SQL selection that results in a counter or in a table with entries. The KPI is set to the counter result, or to the number of entries selected (your choice). another example (sensor SQL) of a sensor that can be utilized without Abap coding. Count the number of sales orders for the day.

Sales order health - live monitoring

The board is live and the sensors are keeping a close eye on the batch job and the Application Logs. The following examples and responses indicate what can be done with live monitoring.

• When starting up, error level was set to 1 and at the same time the complete team had subscribed to the board. Issues were looked after almost immediately, sometimes by several team members at the same time. As there were multiple errors per day, which were also resolved, the board started sending out several mails to the whole team.
  
  The sensor error level was increased to 10. This meant emails were only sent out when the number of errors crossed the 10-error boundary. As emails are only sent when the status is set to error, email traffic was reduced.
  
  The other setting that was done here is the sensor delay. This was set to 2 hours, which meant that sensor execution was running less frequent - as the problems did not need immediate attention.

  Sensor design caters for updates every few minutes. This does not mean it makes sense to update a sensor with that frequency. The delay (in seconds) can be used to slow processing down.
  
  

• 
  After a few weeks, the issues that caused errors have been identified and most of them were solved. Every now and then, a peak in errors occurs. It's not clear when the last peak was and how many errors occurred.
  
  The sensor logging "KPI graphics" is switched on, which ensures that sensor results are logged. After some time the sensor report (displayed when clicked on the sensor tile) is enriched with a graphical overview (at the end) and an overview of Average and Maximum recorded KPI values.

  This should provide insights on when measurement peaks happened before.
  
  

• 
  As the process is running quite smoothly, there are days when nothing concerning is being reported. The team sometimes forget to check the board, which shows issues for the current day only. Have we missed something ?
  
  Using a sensor parameter, the selection is changed to check SLG1 entries for yesterday and today (2 days).
  
  In addition, a new copy of the Application Log sensor is added which looks back 2 weeks, skipping the past 2 days.
  
  
• 
  Business is going so well that the team that is looking after these orders is split into 2 teams.
  
  The batch job is also split into a job for each team and the group and all it's sensors are also copied/adjusted. The only topic that could not be separated is the Business Application Logs, for which an adjustment needed to be done. Each team would get their own subobject on the report that creates the logs.
  
  
• 
  The system sent out emails to all subscribers at 2am in the morning. Team members complained.
  
  The group was assigned a schedule "Office hours only" which ensured the sensors on the group were only checked during office hours. This schedule also takes Christmas into account.

  Sensors that are not operational because of the schedule, will show a Zzz-icon to indicate they are "sleeping/pauzed".

  Schedules are available as a group feature. They describe when sensor checks are to be carried out for the (all) sensors of a group. The group execution calendar - is hidden away in the Sensor settings application.
  

• 
  A lot of changes have been done to the settings on the settingsboard. One of them even has a documentation reference set up. As a few changes to the setup are available to test - on the acceptance system - testers want to use the sensor board settings from production.
  
  The whole group (groups) are downloaded from the production system and uploaded into the acceptance system. functionality which is available from the Sensor settings application.
  
  
• 
  To get a feel of the Sales Order flow, a sensor was set up. With an open SQL selection that included a create date and create time, the number of orders were selected for the past 14 days. The sensor executes selection for the past 14 days and again for the 14 days before that, to calculate the growth/increase (or decrease) as AEX-like index. Once this was set up, the sensor settings were copied to 7 days, to perform the same measurements with a shorter period.
  
  These sensors didn't even have a warning limit or error limit. It's a sign of good health. This also started the discussion on measuring order value instead of number of orders. Which can also be captured in a ready-to-use sensor (being the SQLINDX).
  
  

These usage examples could give you an impression of the control over sensors and the insight sensors provide. With nearly 50 operational sensors "out of the box" - there are many more examples to describe. Note as well that there are 2 open SQL sensors as well (SQL and SQLINDX) - which feed on the selection of your preference (without any abap coding).

Sensor states: warnings and errors

Every sensor is displayed in a given state. The KPI indicator determines the state of the sensor. When memory usage exceeds 80%, the sensor should warn us (yellow), when it exceeds 95% the sensor should show the error state (red) and even mail us about it. But the sensor KPI does not always throw warnings or errors. Key figures can also be added just to keep in check with the overall process.

Overview of sensor states

	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 displayed information is the time of the most recent measurement (14:18) and the duration in which the sensor has been in it's current state (1w5d for 1 week and 5 days).

So it is the KPI that determines the state (and colour) of the sensor. Each sensor has their own KPI limit for the warning state and/or error state. Warning limit and error limit are not mandatory, so some sensors will never show as red/error (these are shown in white).

Priority

The group priority is shown as e.g. P1 just left of the group title (check the overview examples).

Show the sensor board

To show the sensor board use transaction ZEN.

The word zen means medidation. To practice zen has many aspects: to calm down, to (re)determine your motives, to be mindfull in daily life, to reflect on yourself. It is all connected.

A fitting name for a cockpit application on the health of the system.

The selection screen of ZEN hosts selection and display options. Try them out and find out what works for you. Once you're settled, just save the settings as a variant with your user ID as variant name. The next time you start ZEN, this variant will be used.

Once the board is shown, a dashboard like overview of sensors is displayed. Click on a sensor to get an up-to-date explanation of the KPI that was shown. Up-to-date: as a click on the sensor will immediately execute the sensor. Note that sensor logic could be slow to reproduce - thus some of these "sensor clicks" may be slow. The system will store any new results, so other sensorboard users will be presented the latest KPI results.

The board also hosts 3 other forms of viewing sensor data. Being:

• CTRL+click = Sensor settings

  For users that have access to sensor settings, CTRL+click will open the settings editor for the selected sensor. Press enter to focus on the settings and take things from there. Note that the sensorboard uses 2 authorisation levels. Authorisation for transaction code ZEN for the sensor board and ZEN_EDITOR for the sensor settings application.

• ALT+click = Sensor data report

  This will also execute the sensor and present the data that is presented on the sensor itself as an ALV report. This functionality will not be available or make sense on all possible sensors, but it can also be a good way to follow up on issues.

• CTRL+ALT+click = Save sensor history

  This will execute the selected sensor and store its results as historic sensor data. Historic sensor data can be reported in "Report historical data" where previously logged sensor data can be compared.

The board as oData service

The sensorboard can also be used through oData services, backed by a RAP application. These services provide an overview of the board as well as the immediate execution of a single sensor, revealing all it's details (effectively everything that is on the sensor detail report).

Through this channel, the complete board can be made available as Fiory app or web app.

Receive an email on calamities

The moment a sensor turns red, a calamity is assumed. Sensors that show faults should be followed up. This can be done on one of 2 ways: solve the issue or adjust the error level on the sensor (Mozes and the mountain).

The moment a calamity occurs is an important moment. An email will be composed and sent out to all group subscribers. The email will show the sensor summary along with detailed information on the sensor. Users can subscribe to a group by clicking on "Not subscribed".

An email will be composed and sent to the email address that was set up for the user (transaction SU01d). The mail contains a summary of the sensor with details on how the KPI was determined. The mail content should hold enough information to determine what happened and what can be done to solve it.

Every sensor will have it's own way to report what happened. The following information will be available on all sensor reports:

• In status since - the moment the sensor was set to the error state.
• Documentation - (optional) link to relevant documentation (e.g. Sharepoint).
• Warning - the KPI level that would make the sensor state yellow.
• Error - the KPI level that would make the sensor state red.
• Delay - (optional) the sensor delay in minutes. This is for sensors that do not need to be checked very often, e.g. sensors with a long runtime or sensors that have a very steady KPI level.
• Sensor name - the internal name of the sensor.
• Parameter value - the parameter settings for the sensor.
• Class/method - the class name and method which holds the Abap logic for the sensor.
• Duration - consumed runtime in milliseconds.
• Result KPI - the sensor outcome (KPI = Key Performance Indicator).

Feature overview

The setup of the sensor board with groups of sensors makes organizing the board possible. An overview of means to organize and work with your sensors:

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 the board

• 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 sensor board with a darkened background.
• The selection screen of the sensor board 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 sensor board pick up on user-specific settings the next time the board is started.

Emailing and subscribers

• Users can subscribe to a group (or groups).
• 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.

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 (accessible from the sensor board selection screen or the sensor settings editor) can show logged sensor results side-by-side to compare.

• Note that both these logging methods can be used on any sensor.

Sensor settings - backup and move

• The sensor settings application is equiped with download/upload functionality, which can be used to move your sensor-board 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.

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 Sensor board 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.

Receive overviews at regular intervals

The sensor board 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, a file is attached to the email.

Running the board

The sensor board comes alive with the sensor engine, a report that needs to be scheduled in the background. The engine is the heartbeat of the sensor board. 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 sensor board 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).

Without the sensor engine job, the sensor board would be fully operational. The only thing is that sensor KPI results would not be updated and emails would not be composed. The sensor board 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 sensor board - 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:

1. 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).
   
   
2. 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".
   
   
3. 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).
   
   

4. Housekeeping tasks
   
   The sensor board 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)

Feeders are stand-alone reports that are not part of the sensor board 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.

Sensor board general settings

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

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

Sensor settings

From the selection screen of transaction ZEN button "Settings" is available. Users that are authorized to edit sensor data can use "Sensor settings" functionality.

1. Create/change/delete groups (with priority and a schedule).
2. Create/change/copy/activate/deactivate/delete sensors (for a sensor type).
3. Create/delete subscribers.
4. Move groups and sensors to other systems.

Group settings

Sensors live in a group of related sensors. Whenever notification emails are sent, these are for the (all) sensors of a group. In case a user is interested in a single sensor only, just create a group with only that sensor.

The first 2 fields can be used to focus on a group - which will then be shown below. The "Details of focused group" will show details that can be changed. This setup is called a "line editor" and is used for the other tabs as well. First focus, then edit.

Available fields:

• Title: the name of the group
• Schedule: (optional) when the sensors of the group are processed, a schedule can be applied. This can e.g. be used to check sensors during work hours only.
• Sequence on board: (optional) can be used to influence the sequence in which the groups are reported.
• Priority: (optional) sensors can be prioritised via the group. Priority P1, P2, P3 and no priority at all are the possible values. Groups with priority P1 require subscribers on the group - otherwise the "Self service" sensor will trigger errors.
• Documentation: (optional) as for sensors, the group can also carry a reference to group documentation (e.g. on Sharepoint).
• Warning and error limit: (optional) The limits that are specified here will be applied to all the sensors on the group. Unless the sensor has it's own limits defined.

Sensor settings

The settings report opens focused on this tab - as it is likely to be the most commonly used one.

The sensor tab hosts a suite of functionality. Sensors can be looked up, created, changed, (de)activated, tested and copied to e.g. another group. Just make sure you save your changes. The main functionality: Search and report Click "Execute" for an overview of available sensors. The overview can also be used to edit individual sensors. Search and focus Fill in the sensor title and click "Focus". Details of the sensor are shown in the editor section (middle). Is this not the sensor you were looking for ? Then multiple sensors with the same title are available. Use 1. Create a new sensor Fill in a group and a sensor and select the "Plus" icon. Copy a sensor Copy the focussed sensor to create a sensor with new parameter settings or into another group. Click on the "Puzzle" icon.

Activate and de-activate a sensor New sensors are inactive (Off) by default. Sensors can be activated or deactivated any time. When an end user clicks on an inactive sensor - it is still executed and it will still determine its KPI. This caters for testing before activating.

Sensor texts (optional) Sensor setting scan be available in the sensor (long)text or SO10 text. The "Text" icon will take you to this text. Do note: this is a sensor-type text, not really a sensor text. Thus it is possible to find the exact same text settings on different sensors (which will have the same sensor type). The button next to the text button will show documentation on that is expected - with an example text.

Fields explained

Sensor title (optional). The title of the sensor should be unique within the group. This is not mandatory but it is confusing to assign different sensors the same name. Is your sensor specific for a company code - mention the company code. When the title is left blank, the framework will provide the title (which is language dependant).

Unit of measure (optional). The unit of measure fort he KPI is described here. What is this number ? When the KPI Unit is left blank, the framework will provide one (which is language dependant).

Parameter value (optional). The parameter value is an additional instruction for the sensor. Sensors can be made specific for e.g. a company code. Or to control for how many days the sensor should select data. Use the F4 function on the parameter value field to find out which parameters are available for the sensor.

Board tile sequence (optional). Not a very nice task (tedious actually), but this field can be used to determine in which sequence the sensors are shown on the group.

Documentation (url) (optional). Documentation on the sensor is part of the sensor, however a reference to documentation can also be set on the sensor itself. This document could sit on Sharepoint and it could describe what the sensor is for or it could be used as a documented log of followup actions. The sensor board will feature this link. And when sensor information is mailed out to subscribers, the documentation link will also be featured.

Delay (in minutes) (optional). Some sensors may run slow, which is not a problem for the framework. Every sensor check is locked, thus a follow-up run will simply ignore sensor that are still being processed. Nevertheless it may be a good idea to limit the check-sequence on performance consuming sensors - to save system resources. A delay of e.g. 120 would ensure the sensor is executed(no sooner than) every 2 hours.

Limits (optional). A sensor without limits will always be green/normal. It will still provide an up-to-date state of affairs and it can still be used to periodically update subscribers via an email. Sensors turn warning/yellow when reaching the warning limit and error/red when reaching the error limit, which will trigger an email to subscribers.

Fun(tionality) explained

Icon 1. The sensor can be tested with the button on the far left (green hour-glass). A popup with the sensor tile details will be composed - just like the version from the sensorboard. The overview that is produced here does not have a maximum number of reported results (all will be shown, where the sensorboard will only show the first 50 entries).

Icon 2. The table-like icon can be used on any sensor (active or inactive) to report on the data that was logged on the sensor. This only works with sensors that report data in a table-format (which most sensors do).

Icon 3 and 4. These icons can be used to create a detailed log entry on the database. A detailed sensor log entry captures all the details that are listed on the sensor detail overview. The 4th Icon reports on what was logged. The report is set up to compare 2 measurement points or sensor-setail-snapshots.

Icon 5. The H-icon, which is only available when sensor logging is switched on. Logging The KPI results can be captured in a logging table. This will capture only KPI level changes (no further details). This icon will start a report (ALV) with the logged results.

Logging results are shown on sensor details in graphical representation like so:

Logging can be switched on and of any time. Do note that old logs are lost when switching logging off. The batch report for sensors also has an option to clear old data from the logs (under Housekeeping).

Subscribers

Normally the end user can arrange whether he/she is interested in the group, with a single click on the board. Alternatively the settings application also has a tab for Subscribers (in which users can be subscribed or subscriptions can be removed).

Subscriber details, which can also be used to list subscriptions (F8).

Priority for groups

Groups can also be assigned a priority, which influences the need for subscribers. A group with P1 or P2 Priority should also have at least a subscriber. The self-service sensor will report a problem on this.

Schedules for groups

Sensors are updated regularly, to keep sensor information up-to-date. When a working day is over, the sensors will keep checking and an email on something that has gone wrong in the middle of the night will be sent out to the end user. What's important during office hours, does not need to be as important outside of office hours. Solution: use a schedule.

Schedule details are captured in a text, then applied to (all the sensors in) a group. The framework will recognize which schedules are available to select for the group.

Select an existing schedule or supply a new schedule name to create one. Fill in the text as follows (example):

*	TITLE:Office hours
*	TIME:I,BT,070000,120000
*	TIME:I,BT,130000,170000
*	DAY:MONDAY
*	TIME:E,BT,090000,120000
*	DAY:TUESDAY
*	DAY:WEDNESDAY
*	DAY:THURSDAY
*	DAY:FRIDAY
*	DATE:E,EQ,20241225

Parameters explained:

• TITLE short description of the schedule
• TIME (optional) RANGE variables for start and end times. I,BT,070000, 120000 where I=Including times BeTween 070000 and 120000. Times need to be supplied as a range (from - to). When no time is supplied, there is no time restriction. When a time is supplied before the day, it is applied to all days.
• DAY indicates which days are on the schedule. A schedule without days will never be executed. MON, MONDAY, MAA, MAANDAG or 1 all refers to Monday.
• TIME (optional) can also be specified per day (underneath the day).
• DATE (optional) is a RANGE variable for dates. Use this to indicate that Christmas day should not be selected. Or use it to specify a 2 week hypercare period (extra checks).

Upload and download

Sensors are easy to create, change and remove again. They form a customizable link between the sensor board and factual data with sensor type logic in the middle. Once you're happy with the sensor board details, they can be moved to another system using upload/download functionality. Sensor settings are explicitly not transportable - as this is about transactional data that needs to be adjusted on the system it is used on.

The complete board can be downloaded to a single /JSON file. This can thus also be used as a safety backup for the board. Upload and download are great features, but there is also a risk: someone could un-intentionally whipe-out all settings. Best have a backup available.

A backup for a specific group ? A specific sensor (in a group) ? First set the focus on the group or sensor, then set the download option. There is a thin line between user-friendly and MVP, Minimal Viable Product. This setup is MVP, but gets the job done.

As the note on the screen suggests, the JSON (JavaScript Object Notation) download file can be edited in e.g. Notepad. JSON has a similar setup/function as XML without the <tags>. When the downloaded file is opened in Notepad, it will look readable but compacted. As we are dealing with JSON (which is a popular way to capture data in a file format), we can use on-line JSON validators. Search for "JSON validator" and select one, like JSON Checker - The JSON Validator and Formatter.

Copy the JSON content from the Notepad editor into a validator tool:

The same download JSON in a JSON validator (after validation).

Other than the simple fact that this is much more readable, the use of a JSON validator has another huge advantage. When you do your changes in the validator, these will also be validated (the correct syntax of JSON will be checked). The upload functionality only accepts correctly formatted JSON files.

With upload/download in place, board settings can be moved to other systems. And of course the other way around. When changes are done on the settings of the production system - these can be propagated back to the test environment.

Technical matters

The sensor board is set up as a framework. New sensors can be added from an existing class as part of an existing application, or as a dedicated class that has sensors as only function. The logic for a sensor is captured in a single method which requires a given naming convention (SENSOR_...) for the framework to find it. In addition the class which houses the sensor should implement interface ZIF_SENSORS. Method INTERNATIONALIZE (from the interface) should take care of sensor name and parameter descriptions. Once a new sensor is prepared, a tile can be created using the sensor settings functionality. Full step plan below.

A sensor determines a KPI value - and explains how it was determined. Value 0 means "all is well" and anything else means "something has gone wrong". Sensors can also show they couldn't do their job by returning -1 as KPI value.

So how would a sensor on daily sales work ? If the KPI would show the number of salesorders it would be accurate and valuable information - but it would not represent "a level of trouble". Consider this:

• Use a parameter or the sensor settings text to hold a base value for sales per period (hour).
• Let the sensor determine the number of created salesorder in the past period (hour).
• The KPI for this sensor can be 0,1 or 2, which is aligned with Normal/green, Warning/Yellow and Error/Red.
• When the count of salesorder is within a 20% range of the base value - KPI=0.
• When the count of salesorder is within a 50% range of the base value - KPI=1.
• And otherwise the KPI=2.
• Of course, the details on this will be available to the end user when clicking on the sensor.

Take away: the KPI's main function is to determine the state of the sensor. It does not need to be a meaningful number (though often it can be). The Unit of Measure should help understanding what the KPI is.

The sensor framework

The sensor board setup consists of a suite of components in a framework. There is a report for the sensorboard, a report for settings (and editing) and a report for the background execution of sensors (and emailing and housekeeping). Then there are several classes that capture all related functionality for the reports. All of these components can remain unchanged - when the framework is implemented.

The framework is documented using AbapDoc. Every method has was documented and Eclipse will be friendly enough to reveal this (in context).

Eclipse editor revealing method-documentation (ABAPdoc)

If there is an umbrella system available, such as PRTG or Datadog, that could consume the information from the sensors - a product-specific service could be set up to call the sensors from this framework. Thus KPI results can be disclosed to sensor boards that monitor multiple systems. A sensor can be invoked with a single call to ZCL_SENSOR_MANAGER=>EXECUTE_SENSOR(..). There is a RAP service for the board as well, ready to deliver the sensor board and sensor details as oData.

The board uses HTML to cater for it's sensor board looks. Sensor tiles are packed with details and even more detail is revealed when hovering over the fields on the tile. In addition the HTML content is also used to compose a detailed sensor report as popup or as email.

Sensors can keep track of their KPI values in a log. This will be shown on the sensor detail popup (email) as SVG image, or on the sensor settings application in ALV form.

The framework hosts exchange of sensors - between different systems. Thus a sensor that was set up for SalesOrder monitoring in company A, can be set up in a dedicated class. The (abap) coding for this class can then be implemented in company B without further actions. Sensor, descriptions, translations everything a sensor requires will be available on the coding of the class. At this point class ZCL_SENSORS_STANDARD (32 sensors) and ZCL_SENSORS_HOUSEKEEPING (10 sensors) hold the bulk of the available sensors. But there is also a "self-service" and a "Remote board" sensor available on ZCL_SENSOR_MANAGER which will check the state of affairs on the sensor board itself (like: is the background job for the sensorboard itself scheduled ?).

In addition, when the sensor framework is operational on multiple systems on your landscape, an RFC connection will bring the number of error sensors from the other system(s) right to your board as sensor KPI.

You are encouraged to add sensor(s) to your own solutions - add your tiles on the board.

Steps: add a new sensor

Before adding a sensor to the framework, make sure you look at what is already available. Try to find a sensor with logic that resembles what you want to do. Sensor logic lives in a single method and starting off with a working copy is definitely the way to go.

The next thing to take into consideration is the location you want to add your sensor. Best avoid adding to the ZCL_SENSORS_STANDARD or ZCL_SENSORS_HOUSEKEEPING classes, as they are part of the rolled out framework and should be left unchanged to support upgrades. Which leaves 2 options:

1. Custom sensor class
   Create a new class to host several sensors
2. Embedded in existing class
   Add the interface to an already existing (custom) class and run through the below steps from there. This is the preferred option if the sensor type is factually for the subject of the custom class.

For this step-plan, we are adding a sensor that determines the number of outbound Idocs with a given status.

1. Choose a good spot
   And a good (new) name. The name of the sensor type needs to be unique and since you are adding one, it is your responsibility to check this. Create a (dedicated) class or use one that is already available on the subject. Our example class is dedicated and is called ZCL_SENSORS_PLAYGROUND ($TMP).
   
   
2. Add interface ZIF_SENSORS to your class.

     PUBLIC SECTION.
         INTERFACES zif_sensors .
   

   This will make the framework recognize the classes with sensor logic (decorator design pattern).
   
   
3. Method ZIF_SENSORS~INTERNATIONALIZE will have appeared on your class, when the interface was added. This method needs to be implemented. Internationalize means "make available in different languages" - and we will do so in English only.

     METHOD zif_sensors~internationalize.
   
       ro_i18n = zcl_i18n=>get_instance(  ).
   	ro_i18n->feed( VALUE #(
         ( id = 'SENSOR:MYIDOCS:TITLE' en = VALUE #( ( |My Idocs (outbound)| ) ) )
         ( id = 'SENSOR:MYIDOCS:UOM' en = VALUE #( ( |idoc| ) ) )
         ( id = 'SENSOR:MYIDOCS:SUMMARY' en = VALUE #( ( |Playground sensor| ) ) ) )
       ).
   
     ENDMETHOD.
   

   Note that the get_instance method can also take a parameter value for the pool. When supplied, the texts can be "overwritten" and more translations can be added using report ZI18N_EDITOR.

4. The sensor is called MYIDOCS and it now has a name, uom for the KPI and a summary. The framework will use this on the planning board and for F4 functions.

   Now create a method for the MYIDOCS sensor. Name it SENSOR_MYIDOCS, add the following parameters:

       CLASS-METHODS sensor_myidocs
         IMPORTING iv_parvalue             TYPE zsensors-parvalue OPTIONAL
         CHANGING  co_log                  TYPE REF TO zcl_sensor_manager_log
         RETURNING VALUE(rv_resultcounter) TYPE int4.
   
   

5. Create the new method and set the returning parameter to -1. This is a way to let the framework know that no actual KPI measurement is in place (yet).

     METHOD sensor_myidocs.
       rv_resultcounter = -1.
     ENDMETHOD.
   

   With these steps, your sensor will be available. It can be added to a group and displayed on the sensor board. Start transaction ZEN and go to Settings (or use transaction ZENEDIT). Click F4 on the Sensor type field:

   
   The new sensor is available and can be added to a group (F4 on Sensor type)

   Put the sensor on a board, run the board and click on it:

   
   The new sensor as shown on the sensor board (transaction ZEN).

   The sensor is in place, but it has no sensor logic.

   At this point - your sensor is operational and can be placed on the sensor board.

6. Now all we need is determine a KPI value and explain it to the end user. Our playground example focusses on Idocs that were not processed correctly. Steps continued:

   Every sensor is set up with a brief explanation on what it does. We will supply this here, using attribute CO_LOG - logging.

     METHOD sensor_myidocs.
   
       co_log->add_info( ' Transaction WE05 can be used to find the ' ).
       co_log->add_info( 'faulty Idocs reported here.' ).
       co_log->add_info( 'Note the direction = 1 (outbound). ' ).
   
       rv_resultcounter = -1.
   
     ENDMETHOD. 
   

   
   The sensor now shows a sensor description.

   Note that the sensor description can also be supplied in different languages. Check out the sensors in ZCL_SENSORS_STANDARD for examples. Also: as all texts of the framework and all texts on individual sensors are made available through the Internationalization mini-framework, they can be adjusted and even translated to other languages (see Internationalization).

7. Next the KPI value is determined, by selecting on EDIDC (control records for Idocs). We'll use method ADD_MESSAGE to reveal information on this selection.

       co_log->add_message( 'Selection on all outbound Idocs status <> 03' ).
       SELECT COUNT( * ) FROM edidc INTO @rv_resultcounter
         WHERE direct = '1' AND status <> '03'.
   

   
   Example now shows KPI count and logging/explanation

   Clear and precise explanations are important. When a user subscribes to your sensor, these are the texts that are emailed. It should explain what is happening and what can be done about it.

   Need to show details as a table ? Methods add_tableheader, add_tableline and add_tablefooter are available for this on co_log. Add_tableheader uses a ;-seperated list of colomn headers, add_tableline uses a ;-separated list of values. Call add_tableline with a single value, than it will consume the full table line. No more than 50 lines will be shown in a table (unless the sensor is triggered from the settings editor).

Parameters and sensor text settings

Sensors work with parameters and also host settings as text. Nearly all sensors use this setup and can be "parameterized". The most commonly used parameter settings control date and time:

• TIMING: the Timing parameter determines a start time and an end time to be applied on the current day. TIMING:120 means a start time of 2 hours ago and an end time of "now" or "the moment the sensor check logic is called. The sensor logic will use this for its selection logic. So no information older than 2 hours is selected/involved. TIMING:70-10 will start 70 minutes ago and end 10 minutes ago. Use method zcl_sensor_manager=>get_timing for this.
• DATING: the dating parameter works like the de timing parameter, for dates. DATING:8-1 means everything for the past 7 days. zcl_sensor_manager=>get_dating.
• Other parameters, use method zcl_sensor_manager=>get_parameter.

Using parameters can make the sensor specific for a company code or Idoc type. Sensors can be used for a specific group or purpose or subject, pinpointing problems. The sensor for batch job monitoring can now monitor that specific job that is relevant for a given group.

When using parameters, it is important to log what parameters were used and which value they had. This should be part of the sensor details. In addition to that, the used parameters should be documented on method zif_sensors~internationalize. The Settings report will use this for F4 functionality on the sensor - which gives the user of the settings report the chance to see what parameters are supported (and what they do).

Example of 2 parameter definitions TIMING and OPTION.

Click F4 on the Parameter value field to reveal available options.

For sensors that require more setting information that can be captured in parameters, the sensor settings text can be used. This is a standard SO10 long text that is made available in sensor logic itself and it can contain anything the sensor requires. Use zcl_sensor_manager=>get_longtext to fetch this text. Like with parameter settings, it is good practice to document the settings on the sensor itself. As example a sensor settings text on AL11 folders is shown, where for a folder (or any unique code) settings are available.

Example of a sensor settings text - for the FILES sensor.

This information is grouped per ID, a freely assignable (but uppercased) code. For the example these codes are also used in AL11. Furthermore in this example there are several parameter settings for each ID, FOLDER, MAXTOTALSIZE and MAXFILESIZE can be set up to supply the sensor with details on determining a KPI. On this example, the KPI is the number of issues found.

The sensor should be set up to show the settings from the setting text, for the above example this shows as:

Example output for the FILES sensor - settings are shown as table.

The sensor settings text can be edited in the Settings application (report). Note that the report has a button for the "Example settings text" which is linked to a special coding block on the sensor logic. Consider the example below:

Coding snippet from the FILES sensor.

Which will show as:

Popup from the Settings application - button "Example settings text".

One additional remark on the use of parameters and the sensor settings text. Alternate parameters is the way to differentiate sensors in sensor logic. This means a parameter for a company code will make the sensor logic do something specific company code selection. The settings text is one and the same text for all sensors of the same type. Combine parameters with settings text content if you need to work with multiple parameters. The system has several examples where this is done, like the above FILES sensor.

Consider using the SKIP parameter when the same sensor type is used multiple times. There are several examples available for this (like the above FILES example). The idea behind SKIP is as follows: the sensor longtext is in fact a sensor-type longtext, which is applicable to all sensors of the same type. Using SKIP is the way to inform the sensor that the settings should be ignored for sensors without parameters. Why ? Because a sensor with a parameter specific for these settings will be available. In the above screen-print example: a sensor with parameter FOLDER:DIR_GLOBAL will use the presented settings. The sensor without parameters will ignore these settings (and list all settings without SKIP parameter). Now multiple sensors on the same subject can be aligned to each report their own focus area.

Internationalization

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

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 sensor board. 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 ).	
	

oData sensor services

Sensor boards can be displayed just about anywhere, through 2 services.

1. The board - groups with all their sensors
2. 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.

@EndUserText.label: 'Sensor board 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;
}

(1) Get the (full) board with groups and 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)

{
  "@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

{
  "@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 sensor board 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 Sensor board 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 sensor boards

1. Disclose sensor logic to an external sensorboard
The whole concept of the sensor board originates from network sensor boards. When systems need to be monitored a network sensor board can be used to monitor whether systems are active and responsive. The sensor board 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 sensor board 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 Sensor Board 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 sensor board".

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 sensor board 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 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.

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

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