Several performance collectors can be customized to monitor customer-specific objects. This section describes how to adjust settings for these collectors.

To navigate to Collector settings, go to t-code /DVD/APPD_DI_CON and click the Collector settings toolbar button.

Set Up Thresholds for Long-Running Jobs

SNP CrystalBridge® Monitoring monitors delayed and running background jobs and reports those delayed or running longer than expected. By default all jobs running longer than 10 minutes or delayed for more than 1 minute are reported, but this value can be changed also for specific background job names. Collected data are replicated as custom application events of type /DVD/MON_S_BG_JOB_DETAILS and into custom analytics schema monitored-bg-jobs.

Example settings

With these settings active, the background job, ZFI_ANALYSIS_JOB, is reported as 'long-running' if the run-time exceeds 20 minutes. All jobs starting with ZMM are reported if running longer than 5 minutes.

By default, all background jobs running longer than 10 minutes or delayed for more than 1 minute will be reported to the controller even if the table is empty. If you want to only monitor selected background jobs or override the default behavior for long-running job monitoring, add a new row with the following parameters:

  • Pattern: *

  • Job Time Limit: can be customized, if you do not want to see any default long-running jobs, set the value to 9999999.

  • Delay Time Limit: can be customized, if you do not want to see any default delayed jobs, set the value to 9999999.
  • Priority: 1 (default rule has priority -1 and we need to override it).

  • Active: checked.

Functionality of this collector can be adjusted by adding custom entries the input table:

  • Pattern: background job name pattern (supports wildcard '*')

  • Job Time Limit: defines how long background job has to run to be reported (both as metric and into analytics/events). If you do not want to see any default long-running jobs, create rule with only wildcard as job pattern and set this value to 9999999.

  • Delay Time Limit: defines how long background job has to be delayed to be reported - if left empty (zero value), job delays will not be reported at all.

  • Priority: defines priority order for processing background job statuses. If background job name matches two or more patterns in rules, it will only be processed by one rule with highest priority.

  • Active: deactivates or activates the rule.

  • Persist - by default, when background job is over delay / runtime threshold, it will only be reported once into analytics/events. By ticking this option, job will be reported until its delay or runtime ends (by default every minute).

  • Persist period - defines “cooldown” period in minutes for how often should job be reported to analytics / events as long as it is over delay / runtime thresholds. If left at 0, job will be reported every collector run (by default every minute).

Set Up Custom Values from Job Variant Fields

SNP CrystalBridge® Monitoring can populate placeholder fields with values from background job report variant fields. This is possible for long-running or failed background jobs.

Example settings

With these settings, long running or failed background jobs with names that start with 'Z' will have the placeholder fields populated from non-empty variant elements like this:

  • value of variant element S_DATE will be stored in detail as Custom value (long) 1 (CUSLVAL1)
  • value of variant element S_TIME will be stored in detail as Custom value (long) 2 (CUSLVAL2)
  • value of variant element P_COUNT will be stored in detail as Custom value 1 (CUSVAL1)

Example variant

  • value of S_DATE is a range from 14th October 2019 to 25th October 2019
  • value of S_TIME is a range from 12:00:00 to 16:00:00 and less than 02:00:00
  • value of P_COUNT is 5



Processing of custom values can be adjusted further by implementing the following Business Add In (BAdI):

  • Enhancement spot name: /DVD/MON_EH_BADI_BG_JOB_DETAIL
  • BAdI interface: /DVD/MON_IC_BADI_COL_BG_JOBS
  • BAdI interface method: FILL_CUSTOM_FIELDS
    • Importing:
      • IT_VARIANT_VAL - Table of variant field values for given background job
      • IV_JOB_NAME - Background job name
      • JOBCOUNT - Backround job ID
    • Changing
      • CT_DETAIL - Table of problematic background job details (contain custom placeholder fields)

Monitoring of RFC Destinations

SNP CrystalBridge® Monitoring can be customized for monitoring availability and ping time of selected RFC destinations. Add RFC destinations that need to be monitored into the list and select the type of the test (connection, ping, authorization). Collected data are replicated as custom application events of type /DVD/MON_S_RFC_DETAILS.

Example settings

Connection test and authorization test is only relevant for ABAP (type 2 or 3) and Internal (type I) RFC Destinations.

Monitoring of qRFC Queues

It is possible to monitor the number of records in a specific qRFC queue (t-code SMQ1 and SMQ2) by maintaining qRFC collector settings. Specify queue name and direction (I - Inbound, O - Outbound, B - Both). RFC Destination name can be specified to narrow down the selection for specific destinations that use the same queue. Collected data are replicated into custom analytics schema sap_qrfc_details.

As of release 20.11.0, '*' or '%' wildcards can be used in RFC queue names and RFC destination names.

Example settings

Extracting Parameter Values From SCM qRFC Queues

This section describes how to extract values from qRFC function module parameters on the SAP SCM system. The parameter values are extracted from failed RFC calls made by the APO function modules based on the user-defined input table records. To access the input table, select qRFC SCM Monitoring.


Before setting up qRFC parameter value extraction, you must ensure to set up Monitoring of qRFC Queues by specifying the relevant queue names and RFC destinations in the qRFC input table. The extracted values are added to events and custom analytics records generated by Monitoring of qRFC Queues.


This method for extracting parameter values is only available on SAP SCM systems and only for function modules that belong to /SAPAPO/ function group. Values are currently extracted only from qRFC records that are in SYSFAIL state at the time of collector execution.

Input Table

Every field of the input table has an F4 help. Wildcard characters are supported for the Queue Name and RFC Destination columns. Parameters in the Parameter Path column must be specified fully and the Custom Field column only allows certain values (CUSVAL<x>/CUSLVAL<x>). That means that for every qRFC queue row matched by the wildcard, the collector will try to extract the parameter value if the parameter exists for the function module in the said RFC call.

  1. Queue Name - the name of the RFC queue where parameter values should be extracted. Press F4 to get a list of all currently active (Inbound/Outbound) queues.
  2. RFC Destination 

    1. Outbound RFC queue - each outbound queue can contain multiple RFC destinations. Press F4 to get a list of RFC destinations that are associated with the defined queue name.

    2. Inbound RFC queue - leave this field empty.

  3. Parameter Path - path to a function module parameter where value will be extracted. Press F4 to get a list of all combinations of parameters that are available for the defined queue name and RFC destination. Use '*' wildcard to narrow down the list of parameters displayed in the F4 help. 
    There are three types of parameters:

    1. Single parameter - extracting the single value of the parameter. Example parameter path: IV_PARAMETER.

    2. Struct parameter - extracting field value from a struct. Example parameter path: IS_STRUCT-FIELD

    3. Table parameter - extracting field value from a table. Example parameter path: IT_TABLE-FIELD

  4. Custom field - defines where the parameter value will be stored in the existing detail table Erroneous queues Details. F4 help is enabled.

    1. CUSVAL1 - CUSVAL6 - suitable for single short parameter or structure parameter values.

    2. CUSLVAL1 - CUSLVAL2 - intended for longer values, or for storing table field parameters. The table field values are represented in a single field as VALUE1;VALUE2;VALUE3;VALUE4 (when a table has multiple rows, values are separated by “;” in one field).

Example Settings

Monitor IDoc Values

It is possible to monitor values of specific IDoc Segments using the new IDoc content collector added in release 20.11.0. Users can specify IDoc Type, Segment, and Fieldname of the said segment that should be monitored. To configure IDoc value monitoring, select IDoc Field Values under settings on the left side of the screen.

Input table contains the following fields:

  • IDoc Type - After selecting IDoc type, all IDocs that are of this type will then be selected in detail table.
  • Segment - Specify segment of IDoc type, which contains the value you want to monitor.

    As of release 22.8.0, it is possible to use EDIDC as a segment type to be able to extract fields of relevant IDoc header EDIDC records.

  • Fieldname - Name of field you want to monitor.
  • Numeric function - (Optional) If monitored value is of numeric type, you can chose to apply numeric function (aggregation) to it such as (Average, Min, Max, Sum). That means if specific IDoc has multiple segments with same name that hold this value, numeric function will be applied and it will be displayed as one row in result table.

IDoc type, segment and fieldname fields support F4 help. Enter values with wildcards and press F4 to display list of relevant records. The F4 help pop-up also contains IDoc and segment description texts (when available) and supports multi-selection. Selecting multiple rows and confirming the selection automatically adds the selected row to the input table.

Wildcard character '*' is only supported by the F4 help logic. The IDoc content collector requires fully specified and valid IDoc type, segment and fieldname values without wildcards.

Example settings

Collected data are replicated into custom analytics schema idoc_values_detail_table (legacy connector) or sap_idoc_data where sapSchema = idoc_values_detail_table (harmonized connector).

Monitor SSL Certificates

All STRUST SSL identities are automatically monitored when the SSL Certificate Monitoring table is empty. If you want to monitor only specific SSL identities, maintain the list of identities (PSE Contexts). See also Collector for Expiring SSL Certificates.

Monitor Number Ranges

SNP CrystalBridge® Monitoring can monitor number range usage that exceeds usage thresholds. By default, number ranges are not monitored. Maintain records in the Number Range Monitoring table to add specific number ranges or number range groups (using * wildcards) into the scope of the number range collector and set speed, difference, and free (%) thresholds. Also, see Collector for Number Ranges.

Monitor Cross-system RFC Locks

As of release 22.8.0, it is possible to monitor cross-system locks using a remote token manager system. The input table reflects select options in transaction code SMCL. Remote Token Manager system and Token Manager Number support F4 help and must be provided, other fields support wildcards.

By default (if the input table is empty), all cross-system RFC locks are monitored by getting the default token manager (if it exists) through the function module CSLTM_GETTOKENMANAGER.

It is possible to use the collector to automatically release all locks. There is an enhancement spot with BAdI /DVD/MON_BAD_RFC_LOCKS, with an interface that contains the method RELEASE_LOCKS.

In created implementation call function module CSLAR_TKCHANGE with parameters already provided through the interface:

FM Parameter





SY_UNAME (or any name you wish to release locks under)







This function module will automatically release all RFC locks collected by the collector. You can also implement additional functionality in this implementation (logging, another action that needs to be done after lock release, etc.) if you wish.

Locks are collected by default for the past 24 hours (collector runs once per day), but this option can be parameterized. For more information, see Collector for cross-system RFC locks.

Monitor SLT Replication

If your system includes an SLT replication plugin and it serves as a replication server, you can monitor the statuses of currently replicated tables as of release 23.2.0. You can specify which tables you wish to monitor, whose status will be reported to analytics (schema sap_log_data) and to the dashboard assigned to this section (SLT Replication).

Input Table

Mass Transfer ID, Schema Name, and Table name fields support F4 help. Enter values with wildcards and press F4 to display a list of relevant records. The F4 help pop-up also contains schema name description texts (when available) and supports multi-selection. Selecting multiple rows and confirming the selection automatically adds the selected row to the input table. The selection reflects options in transaction LTRC.

Example Settings