Welcome to the Sensorboard

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

---

Welkom op het Sensorbord

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

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

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

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

Interactive preview of a sensorboard with it's sensors.

Normal size, 2d

Normal size, dark

Normal size, 2d and dark

Compact size

Compact size, 2d

Compact size, dark

Super compact size

Super compact size, dark

Types of sensors

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

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

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

Sensor = Sensor type + Parameters

In the paragraphs below all sensor types that are available as standard are briefly explained. Sensor types that share main subject are grouped together.

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

Batch jobs

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

What could go wrong ?

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

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

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

Quick guide to the batch job sensors

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

Summary	Applicable to	KPI	Sensor type
Is my job running as expected? Checks runtimes and/or downtimes	Single jobs	Number of issues on the batch job	SM37SINGLE
Is my job issuing a specific message Checks the batch job log for messages	Single jobs	Number of jobs (job runs)	SM37LOGS
What jobs have been cancelled ?	All jobs Can be made specific	Number of batch jobs	SM37
Batch jobs overview. Batch job step overview Report (with register) on all periodic batch jobs Use transaction ZENDOCTOR dedicated report on operational batch job health.	All jobs	Number of unregistered jobs or the number of warnings	SM37ALL
What are our combined jobs consuming ?	All jobs For 1 hour	Minutes of consumed processing time	SM37CPU
How long has the longest job been running ?	All jobs	Minutes of consumed processing time	SM37LONGEST

Batch job sensor types

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

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

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

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

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

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

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

  A refreshing view on batch jobs

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

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

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

  Job registration

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

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

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

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

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

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

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

  Parameter	Description
  AS_WARNINGS	AS_WARNINGS:Y KPI on warning messages The KPI for this sensor is defaulted to the number of batch jobs that were not registered on sensor text Settings. An alternative KPI is available as the counter of warnings.
  DETAILED	DETAILED:Y, show extra details
  NO_WARNINGS	NO_WARNINGS:Y hide warning messages To simplify the reported output of the sensor, the warnings can be switched off.
  STEPS	STEPS:Y, reporting based on steps An alternative to reporting on individual jobs, the sensor can also be set up to report on the steps on these jobs. This can be useful when guarding step-duplication.

  
  
  
  
  

Alternate KPI: warnings

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

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

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

The jobdoctor

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

They are the life-line of the system and they deserve to be monitored. There is a good reason there are 6 sensor types on the subject of batch jobs. Batch jobs are important.

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

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



The report may not be available on your system - pick up the latest version here when required.

Download: Zendoctor batchjob report




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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  
  
  
  
  

Executive summary

The Separation of Duties (SOD) sensor provides a lightweight and practical way to detect authorization conflicts in complex SAP environments. Instead of analyzing full role and profile structures, the sensor focuses on predefined groups of critical authorization checks. Each group contains multiple authorization conditions; users must not be able to fulfill all conditions at once. If they do, the system flags a SOD violation. A scheduled feeder report (ZSENSOR_FDR_SOD) performs the heavy processing by evaluating users against the defined groups and generating Business Application Logs with potential issues. The SOD sensor class then exposes these results on the Sensorboard, giving clear visibility into high-risk authorization combinations. This simplified approach works for both generic checks (e.g., sensitive transaction codes) and data-specific checks (e.g., company-dependent access), enabling organizations to detect improper authorization assignments without navigating the full complexity of SAP’s authorization model.

Seperation of duties

If you want to ensure the authorisations of users is correct, you will most likely find this is something that is very hard to establish. Authorisations with it's composite profiles, profiles, roles and individual authorisation checks are complex.

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

Check for sensitive combinations

Seperation of duties is a remarkably complex matter. Setting up user authorization is done in an incredibly detailed fashion. The approach for this sensor is downsized and simplified to the following:

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

A strongly simplified approach, that targets groups with specific authorizations. As authorization checks come in great detail - defining the checks in a group is really where the key lies. From high-over detailed level - e.g. a transaction code to ensuring no 2 users can change company specific settings, for the same company.

Feeder for the SOD sensor

The SOD sensor works with a sensor FeeDeR (FDR). This is a report that should be scheduled periodically to feed the operational sensor with information.

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

Download: feeder report SOD

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

Download: SOD sensor class

Transaction codes

The most light-weight seperation of duties check is for transaction codes and their actions. Imagine you want to ensure developers can't do too much. They shouldn't be able to do SM31 and SE14 for some fictional reason. The settings:

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

Object S_TCODE with field TCD can be used to test the authorization for a transaction code. Make sure you play around with transaction STAUTHTRACE when diving into these checks. And don't worry too much about the enormous amount of detail - just find the bits you can use.

Companies and salesareas

The feeder report hosts selection screen variables for e.g. the company. These $BUKRS fields can be referred to in the sensor settings - which will then be applied to the group profiles. Why ? Because it makes data-specific authorisation checks possible. Not for all and everything, but for the common cases. When your case is incommon - the use of e.g. $BUKRS is not available. Back to hardcoded values then.

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

Download: sensor class ZCL_SENSORS_SEPERAT_OF_DUTIES

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

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

  
  
  
  
  

Idocs

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

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

Getting started

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

Download: idoc-sensors.json

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

The sensors

• BD21 Change pointers
  
  Checks the queue of change pointers.

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

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

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

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

  Parameter	Description
  DATING	DATING:2, the past 2 days
  MSGTYP	Specific to a message type, like MSGTYP:MATMAS
  ALL	ALL:Y to select all Idocs, not just faulty ones
  TIMING	TIMING:120, the past 2 hours

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

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

  Parameter	Description
  DATING	DATING:2, the past 2 days
  MSGTYP	Specific to a message type, like MSGTYP:MATMAS
  ALL	ALL:Y to select all Idocs, not just faulty ones
  TIMING	TIMING:120, the past 2 hours

  
  
  
  
  

Users

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

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

Emails

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

• SUIM User activity
  
  Checks the number of active users.

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

  Parameter	Description
  CLASS	CLASS:SCC-EXTERN Select only users form a group
  DIALOG	DIALOG:Y Select only dialog users

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

  Parameter	Description
  CLASS	CLASS:SCC-EXTERN Select only users form a group
  DATING	DATING:-90, up to 90 days ago This is where you decide how long it takes for a user to become historic.
  DIALOG	DIALOG:Y Select only dialog users

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

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

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

  The sensor determines up to 3 dates:

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

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

  Measure the last user activity

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

  The sensor can be provided with the following info:

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

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

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

  /: CDHDR/USERNAME/UDATE/MANDANT

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

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

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

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

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

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

  
  
  
  
  
• SOST Outbound emails
  
  The sensorboard relies on email itself as well. A mail notification should be sent out to the subscriber of a sensor group when one of it's sensors turns red. This sensor monitors failing outbound email messages.

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

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

  
  
  
  
  Transaction SOST reveals more detailed information on sending emails.

Queues

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

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

Getting started

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

Download: queue-sensors.json

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

Fixer reports

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

Download: helper class ZCL_SENSOR_FIXER

For new fixer reports, a template report is available:

Download: report ZSENSOR_FXR_TEMPLATE

• SMQ1 Outbound tRfc queue
  
  

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

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

  
  
  
  
  

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

  
  
  
• SMQ1LONGEST Outbound tRfc queue
  
  

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

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

  Parameter	Description
  DATING	DATING:2, the past 2 days
  QNAME	QNAME:BW*, focus on specific queues

  
  
  
  
  
• SMQ2 Inbound tRfc queue
  
  

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

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

  
  
  
  
  

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

  
  
  
• SMQ2LONGEST Inbound tRfc queue
  
  

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

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

  Parameter	Description
  DATING	DATING:-2, anything older than 2 days
  QNAME	QNAME:BW*, focus on specific queues

  
  
  
  
  
• SM58 Rfc queue
  
  

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

  Parameter	Description
  DATING	DATING:2, the past 2 days
  OPTION	OPTION:NOTRECORDED, focus on the errors (not status RECORDED)
  TIMING	TIMING:120, the past 2 hours

  
  
  
  
  
• SM58LONGEST Rfc queue
  
  

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

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

  Parameter	Description
  DATING	DATING:2, the past 2 days

  
  
  
  
  
• SWEQADM Workflow event queue
  
  

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

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

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

  
  
  
  
  

Logs

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

• SLG1 Business Application Logs
  
  

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

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

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

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

  
  
  
  
  
• SCU3 Change Documents
  
  

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

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

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

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

  Parameter	Description
  DATING	DATING:31, the past 31 days including today
  TIMING	TIMING:120, the past 2 hours (default 1 hour)
  USER	PI_REMOTE, specifically for user

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

  Parameter	Description
  AUTOFIX	AUTOFIX:Y The sensor fixer report can be used (certified)
  DATING	DATING:31, the past 31 days including today
  IF	IF:INTERFACENAME use for specific interface (wildcards allowed)
  TIMING	TIMING:120, the past 2 hours

  
  
  
  
  

  This sensor has autofix support. The sensor parameters can be used to enable the fixer functionality. Add parameter AUTOFIX to the sensor to make it fixable. The fixer report ZSENSOR_FXR_SRT_MONI should be scheduled for each fixable sensor. Download: fixer report SRT_MONI The sensor (type) settings for the sensor are used to capture what the sensor fixer (FXR) should do. Only Entries with sensor parameter value AUTOFIX:Y will be processed. The step plan to using this fixer report: The fix that is executed by the fixer report is the "resend of failed messages". The fixer report will restart all the messages that are reported on the sensor. Control the retry-frequency by scheduling the job (hourly, daily, ..) Control how log retries should be attempted by setting the DATING or TIMING parameters on the sensor. Schedule the fixer with the exact same parameter value as specified on the sensor.

Performance

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

Getting started

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

Download: systemhealth-sensors.json

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

The sensors

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

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

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

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

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

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

  For more detail - check out transaction SM50.
  
  

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

  
  
  
  
  
• SPEEDPROBE Speed probe measurement
  
  

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

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

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

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

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

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

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

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

  
  
  
  
  

Workflow

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

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

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

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

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

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

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

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

  
  
  
  
  

Files and folders

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

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

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

  For each folder several measurement points can be checked.:

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

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

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

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

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

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

  
  
  Transaction ST06 reveals more detailed information on available space.
  
  

Number ranges

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

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

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

  Parameter	Description
  OBJECT	OBJECT:FAA_AS91 for a specific object This will make the number range check specific to a number range object, e.g. for documents that are relevant for a certain department.

  
  
  
  
  Transaction SNRO reveals more detailed information on number ranges.

Printer output

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

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

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

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

  
  
  
  
  Transaction SP01 reveals more detailed information on spools.

Locks and updates

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

Getting started

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

Download: lock-sensors.json

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

The sensors

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

  Parameter	Description
  USER	USER:DDIC Show only for specific user
  AS_MAX	AS_MAX:Y Determine the maximum number of locks by 1 person This will change the sensor function from guarding the total number of locks to focussing on the top consumer.

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

  Parameter	Description
  DATING	DATING:2, the past 2 days
  TIMING	TIMING:120, the past 2 hours
  USER	USER:DDIC Show only for specific user

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

Housekeeping

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

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

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

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

Self service

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

System health

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

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

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

• SM21 System Logs
  
  

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

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

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

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

  
  
  
  
  
• ST22 Runtime errors
  
  

  Runtime errors

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

  The thing with runtime errors

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

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

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

  This sensor checks for (new) runtime errors.

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

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

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

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

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

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

  Parameter	Description
  IN_GB	IN_GB:Y In Gb (Gigabytes)

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

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

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

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

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

  
  
  
  
  

Executive summary

Fingerprint Data Comparison is a lightweight and secure framework that ensures data consistency across interconnected systems in an S/4HANA landscape. Instead of exchanging full datasets, each system converts its relevant control data into a compact MD5 “fingerprint” containing only a key and a hash. These fingerprints are uploaded to a central comparison system, where automated checks identify mismatches and missing entries. Using this approach, millions of records can be monitored efficiently without exposing sensitive information. Differences are displayed on the Sensorboard, enabling early detection of data misalignment between systems such as SSC, CDC and S/4HANA. The mechanism is generic and fully scalable: any system can produce fingerprints and any type of control data can be compared. Its purpose is detection, not correction - providing a lean, reliable safeguard to keep multi-system landscapes aligned and trustworthy.

Fingerprint data comparison

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

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

The concept is explained in detail - following an example.

An example business case

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

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

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

The step plan approach - for digital fingerprint checks

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

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

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

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

If the system of comparison is the S/4 Hana system (the assumption for the solution described here) - the sensorboard can be set up to inform users when differences show up. Sensors on the sensorboard can be set up with a warning level and an error level - which ensures differences are noticed when they occur. The sensor KPI represents the mismatches and/or missing data comparing source to target. Switch the source and target around to do the same in reverse.

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

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

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

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

  
  
  
  
  

The fingerprint framework

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

Data model

The fingerprint framework uses these tables.

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

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

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

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

So good to realize: nothing historic is stored here. Only the latest information processed. And also good to know: when data mismatches are detected, the mismatch will be reported with dates and times for both source and target.

Main components

zcl_fingerprint_manager - manager class.

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

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

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

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

zfingerprint_uploader - Upload report

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

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

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

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

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

zfingerprint_housekeeping - Housekeeping report

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

zfingerprint_template - Data generation report

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

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

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

FINGERPRINT Sensor type

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

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

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

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

As the sensor KPI is composed as Mismatch + Missing in target, it would make perfect sense to also add a sensor for the reverse direction. So

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

And with the available parameters on the sensor - it could even be considered to separate Mismatch and Missing:

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

The FINGERPRINT sensor type also has options for the following usage variants:

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

With the above options, several types of monitoring can be set up on the sensorboard. Not just the problems, but also the checked trhoughput itself. E.g. when the KPI is set as total matches and the DATING period is set to a month, the KPI will reveal how much is being checked. Using the ECHO sensor (sister sensor) a notification can be sent off when these numbers are too low (because no fresh fingerprints are coming in).

Open SQL selection

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

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

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

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

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

  Example 1: minimal

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

  	SELECT mandt, bukrs, butxt from t001 
  	

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

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

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

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

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

  	NAME:T001
  	

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

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

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

  Example 2: using a result counter

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

  	SELECT count( distinct tabname ) as RESULT from DBTABLOG 
  	

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

  Another example using counters:

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

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

  Example 3: involve date and time

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

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

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

  	NAME:DBTABLOG-EX3;DATING:10
  	

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

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

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

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

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

  Parameter	Description
  DATING	DATING:31, the past 31 days including today
  NAME	Specify the name of the query The sensor settings for the SQL sensor type can hold many SQL scripts and descriptions. To use one on a sensor, the NAME must be specified.
  TIMESTAMP	TIMESTAMP:Y, apply DATING as a timestamp In some tables there is no actual date or time, but a timestamp is used instead. This indicator instructs the sensor to apply the DATING setting as a timestamp.
  TIMING	TIMING:120, the past 2 hours

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

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

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

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

  Example 1: minimal

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

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

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

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

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

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

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

  	NAME:TABLOG-ACTIVITY;DAYS:10
  	

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

  Example 2: involve timing

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

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

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

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

  Example 3: add columns

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

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

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

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

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

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

  
  
  
  
  

Tables

Home of data.

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

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

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

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

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

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

  
  
  
  
  

Transports

Heart of the deployment mechanism in SAP.

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

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

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

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

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

  
  
  

  Inform subscribers for groups

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

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

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

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

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

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

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

Save space

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

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

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

Fixer reports

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

Download: helper class ZCL_SENSOR_FIXER

For new fixer reports, a template report is available:

Download: report ZSENSOR_FXR_TEMPLATE

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

Example steplist on which all required fixer jobs are defined

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

Download: saver-sensors.json

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

A clean house

House keeping tasks used to be important because it would avoid poor performance. With S/4 Hana the importance shifted to operational costs and the environment. As each system fills up with data, it is good practice to keep an eye out on retired data.

Also good for our environment

An example case: workflow. A classic workflow setup used a workflow container which held the full payload of an XML message. The table for this workflow container contained 130Gb of data. Only 1% of these workflows were still active. SAP hosts a report that removes old workflows, including their containers.

130Gb at 0.50 cents per Gb per month (source unconfirmed) is 65 euro per month, 780 euro per year. Storing data also consumes electricity. And all for completely unused storage space.

How can you find these examples on your systems ? SAP's DBACOCKPIT or DB02 reveals information about the largest tables on the system, the fastest growing tables and so much more. Go and investigate what is happening on your system.

So how do sensors help here ? The saver sensors each capture a topic and reveal how much of the data is retired. Retirement periods can be specified and fixer reports can execute the cleanup (through standard SAP reports). So sensors make it all visible and help execute the cleanup. Continuously.

Just in case KPI reporting in Mb's is not sufficient - these sensors can also report in Euro's.

The sensors

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

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

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

  Simply stop hanging on to aged data.

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

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

  
  
  
  
  

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

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

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

  
  
  
  
  

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

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

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

  
  
  
  
  

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

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

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

  
  
  
  
  

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

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

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

  
  
  
  
  

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

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

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

  
  
  
  
  

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

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

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

  
  
  
  
  




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

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

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

  
  
  
  
  

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

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

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

  
  
  
  
  

Sensor controls

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

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

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

The sensor general settings together with both types are considered controls for the sensor.

Executive summary

General sensor settings define the key operational and display characteristics of each sensor, such as title, unit of measure, warning/error levels, delay, sequence, documentation link and logging options. While none are mandatory, customizing them improves clarity, performance, and monitoring precision. These settings control sensor frequency, visibility, and reporting detail, ensuring efficient system operation and meaningful KPI tracking. Each setting serves a distinct purpose, allowing users to tailor sensors to their function while maintaining consistency across the sensorboard.

General settings

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

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

The general settings include details like

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

General settings - are specific to the sensor

General settings are called as such, because they are the same settings that can be applied to each and every sensor. They are very specific to the sensor though. Just like the sensor parameters (next paragraph) and unlike the sensor long text settings (which apply to all sensors with the same sensor type).

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

Executive summary

Sensor parameters are short, upper-case instructions that define how a sensor selects and processes data - for example, DATING:10 retrieves data from the past 10 days. COMPANY:2056 would select results for a specific company only. Each sensor within a group must have unique parameter settings to avoid duplication. Parameters such as DATING and TIMING control time ranges for data selection, allowing variations of the same sensor (e.g., today, yesterday, last week). Users can view available parameters via the F4 function in the Sensor Settings Editor. Proper use of parameters enables precise, flexible and efficient sensor behavior tailored to monitoring needs.

Sensor parameters

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

DATING:10

Which instructs the sensor to select data from the past 10 days. Sensors can be added to a group on the board without limits - however there is one limit: the parameter settings for a sensor should be unique within a group. Thus no 2 sensors can deliver the same information in the same group. Makes sense when you think about it.

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

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

Sensor variations

As a sensor can often be controlled with a parameter, a variation on your sensor can be introduced by simply copying a sensor with alternate parameter settings. A common example would be date-ranges. The sensor that is reporting on information from today (DATING:0), can also be set up to report on yesterday (DATING:1-1). And a third sensor could report on the week before (DATING:8-2) that.

The TIMING parameter

Some of the parameters require a bit more detailed explanation. The TIMING and DATING parameters are available for date-specific sensors. As we're not too interested in yesterday's news, these parameters allow you to control the time-frame in which the sensor should operate. When these parameters are not specified, the system will assume a sensible default.

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

TIMING:180

This means nothing older than 3 hours is selected.

TIMING:180-5

This means nothing older than 3 hours is selected and the last (most recent) 5 minutes are also not selected.

The DATING parameter

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

DATING:1

This means yesterday and today. The current day is almost always included in the selection.

For only yesterday (and not today) use this:

DATING:1-1

For older than 2 weeks, but not older than 6 weeks use this:

DATING:45-14

And if it's only today then use This

DATING:0

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

The DATING can also be used to select dates older that a given date. Some sensors work with a retention period, for which the following setup can be used:

DATING:-90

Specifies a date as 90 days or older.

Find sensor parameters

Use the F4 function on the parameters field on the sensor (first focus on the sensor in the settings editor). This will show the possible parameters that can be used for the sensor (differs for each sensor type).

Executive summary

The sensor long text defines shared settings for all sensors of the same type, ensuring consistency and easier maintenance. These settings, which support lowercase values, can include configuration values, whitelists or blacklists that guide sensor behavior (e.g. which errors to ignore or prioritize). Each sensor links to its corresponding long text via an ID or NAME specified in its parameters, to make general settings specific to a sensor. Documentation for these long texts is available (in English) through the Sensor Settings Editor.

Sensor long text

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

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

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

Here's how that looks:

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

The (prehistoric) long text editor

The sensor type long text utilizes SO10 texts in the English language. As the actual contents of the settings is up to the sensor type logic, the sensor long text is the standard for these settings. Each text line is preceded with a line type, which is either /: or * . The /: for upper-cased values, everything else for regular text.

Executive summary

The Versions feature tracks updates and improvements to the sensorboard and its sensors. As new customer requirements lead to new sensor types or enhancements, these are documented in a release overview that summarizes recent changes. Users can view the current version and perform a version check. A brief logging of changes per version is available - showing the continuous improvement efforts. This system ensures transparency and easy management of ongoing product evolution.

Versions

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

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

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

Two ways to do the check:

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

Version check fails ? No drama ! Just a little extra checking when performing an upgrade.

Version check

A version number was passed, which is now checked to determine which current version is being used.The check code that was passed is "64074FD397090615EC43BB15200518B8A33188D0", which is also displayed on the VERSION sensor.

The check code was incorrect.

What does this mean ?

If the check was done directly from the sensorboard (SAPGUI, transaction ZEN) then the coding of the sensorboard framework has been changed (is no longer original). There may be good reason for the changes, but an upgrade will overwrite custom changes.

The self-service sensor from the board will report this and the actual altered component is listed on the sensor.

Version overview

Version	Added features
2025-??	...
2025-11	Improvements on the I18N internationalization editor. Enable translations of just about any text - 6 languages. Technical depth review: the open SQL sensors are moved to their own class. Html for emails is limited - where the inline-css plays an important role. The HTML for notifications is completely revisited. Deep dives on small errors. Making the product better by detailed focus testing. Added sensor FOOTPRINT to keep a health tab on the data that is consumed by the sensorboard framework itself. The Check and logic were already available on the SENSOR logic, where it consumed too much performance (hence the separation). Documentation pages: added the "Executive summaries" to cater for pre-reading paragraphs. Added batch job event support (transaction SM62 and SM64) - for sensor fixer reports. This allows triggering a fixer report immediately (as opposed to time-periodically). Added fixer for sensor SRT_MONI - which can reprocess failed entries. Added sensor SEARCH a sensor for the below function. Added sensorboard logic: search words. List shortened versions of sensor reports, based on your search word. Added sensorboard history for - latest results -. Whenever a sensor runs, it's results are now stored as KPI and also as content. Whenever a sensor on the board was clicked, the results were determined immediately, which turns out to be a performance issue on slow performers. The board now presents results almost immediately (with an indication on how okd the resuts are). Use SHIFT+sensor click to trigger a fresh sensor report. Added sensors SM37CLEANUP to monitor forgotten batch job clearance (was already part of SYSTEM housekeeping) Added sensors DBUSRMEMORY for the top n memoru consumers (users) and SM35 to capture an often forgotten space consumer: Batch Input recordings and logs. Fix for schema usage on the 750 version (worked on version 758). Fixed sensor SXI_MONITOR for messages, as it was not selecting properly. Added sensor DBSTATEMENT for the most expensive statements from the HANA COCKPIT. Added sensor SCU3 for specfic changes on change documents. Added sensor ECHO to cater for more acurate KPI monitoring. A sister sensor (sits next to it's source sensor) Started the LinkedIn campaign
2025-08	Added automatic fixer reports to sensors SMQ1 and SMQ2. Added sensor SRT_MONI to monitor another of SAP's monitors. Added sensor SM37CPU to monitor batch processing times. An indication of how occupied the system is and useable as early warning mechanism. CSS backdoor for the sensorboard. Enables CSS (html) changes to make the board specific for a customer. Some sensors reveal a lot of detailed information - that can also be used for other things. A list of active users could be used to check whether someone is on the system - as example. Sensors censoring - supresses detailed output but keeps the KPI determination in tact. Sensor STMS for transport imports was already available, but not yet documented. It was altered to also cater for a daily overview of new imports - for our (functional) end user to keep an eye on progress. New sensors: SPEEDPROBE which measures the system performance based on sensor execution times, INDEXER which can transform any sensor measurement results into a trend (like the AEX-index) and ST06UPTIME which shows information about the last time the system was restarted (for "No accidents the past n days"). Texts that were cut-off: the explanations on sensors contained too long lines - resulting in cut-off texts. Resolved, along with other small findings on the standard sensors. Birth of the sensorboard.pro website. Calculation of the TABLES sensor results for table size - was an estimate, now shows the actual consumed memory space like DBACOCKPIT. Change log functionality for sensor details. Links to the editor, for group (ctrl+click on the group name) and schedule (ctrl+click on the schedule). Information on the group - availalable when clicking on the group. This also shows all subscribers to make it easy to determine who is handling/owning the group. Video on internationalization (I18N) - added to the manuals. 2d display option: for users that dislike the number of lines on the sensorboard. A quieter board. Shared inbox subscriptions: cater for email receivers for which there are no SAP user ID's Subscriber clarity: sensor that checks for groups without subscribers and provides an overview of all subscribers (purpose: clarity on who is receiving emails from the sensorboard). Product installer reports (2) to make initial installation easier.
2025-06	Product roll-out to a lower version of the system, which makes the sensorboard framework available from version 750. Trial rounds on letting ChatGPT assist in translating the application. Turns out that ChatGPT successfully supplied the missing 4 languages and applied it directly in JSON. The JSON results could then be uploaded. Editor functionality for translations (internationalization). The editor also includes JSON upload and download functionality. Backup for sensor settings, for groups, for the whole board and automatic (into a table) Alias support, where an alias of a sensor type can be made available in about 12 lines of coding. Introduction of the GRIP ON SPACE sensors, which calculate the Mb's that can be freed up based on supplied retention periods. A main sensor plus 4 detailed sensors (Business Application logging, Idocs, Change documents and DBTABLOG logging). Introduction of the FXR autofix reports for BAL, Idocs, change documents and DBTABLOG logging. Introduction of BEL - Business Event Logging - initial version. Sensor(s) to be added later. Licence checker sensor SUIMSLEEPERS was enhanced. It can now monitor user activity on tables of your choice and KPI can also be reported in Euro. Introduction of "The Zone", a documentation tool for re-useable (custom) system components. The Zone is now part of the sensorboard framework and thus explains it's coded components. The manuals are being enriched with Camtasia instruction videos.
2025-01	As preperation for the first main go-live with the sensorboard - lots of effort was put into delivering a good solid product. The available documentation made available as website (sensorboard framework and individual sensors) Internationalization: addition to the translation setup, which now involves a translation table. Translating existing texts or adding new texts in NL, EN, DE, IT, FR and ES. Next release will also contain an editor. A boardfeeder example program for creating a series of sensors through Bapi. Trial rounds on Bapi-sensors. Support for indexed data for sensors (like the AEX index, a deviation percentage measured over a period of time) Content of the sensor report (as displayed in a popup and sent out to email receivers) was redesigned. The board was operational and active search on problems was done. Numerous minor details were addressed. Added click functionality on the board. With ALT-click, the sensor main data is displayed as an ALV report. Using CTRL+click on a sensor will open the sensor editor. In addition CTRL+ALT+click will log sensor details so comparison to earlier saved logs can be done. General-use sensor for indexed data (as above, but in free-style sql definitions - no Abap) Sensor for Remote access to the boards from other systems. This sensor type uses the errors from another board as it's KPI.
2024-11	After full design and development rounds, the framework was applied to a new system where it was demonstrated to the customer. Installation time under 2 hours. First version-managed release.