1. SAP Support Portal Home
  2. Application Lifecycle Management
  3. SAP Focused Run
  4. SAP Focused Run Expert Portal
  5. Integration & Cloud Monitoring

bgRFC

bgRFC

Background RFC (bgRFC) is offered as a replacement for the classic tRFC and qRFC. It is available with SAP NetWeaver 2004s (SAP Basis 7.0). bgRFC is a superordinate term for the new version of tRFC and qRFC. A parallel run of classic tRFC/qRFC and bgRFC is possible.

The Background RFC works on the basis of units and performs better compared to the classic tRFC and qRFC versions. It comes with a new Application Programming Interface (API) and a new data model.

Terminology:

  • The term "unit" for the bgRFC can be compared with the term "Logical Unit of Work (LUW)" for classic tRFC/qRFC.
    • A unit is a recorded sequence of collected function calls to be performed remotely.
    • The recorded unit data is persisted in the database at COMMIT WORK.
    • A unit can be locked. Such a locked unit cannot be processed until it is unlocked again.
  • The term "destination" for a bgRFC unit defines either a remote system for outbound scenarios or a distinct name for an application in an inbound scenario.
    • Outbound destinations are maintained via the standard transaction SM59.
    • Inbound destinations are maintained via the specific transaction SBGRFCCONF.
 

Technical Prerequisites

The following technical prerequisites have to be met in order to use the bgRFC Monitoring:

  • The managed system is ABAP-based SAP NetWeaver system of Basis release ≥ 7.0

Advanced Integration Monitoring Setup

Please, select...

To be able to monitor interfaces of an on-premise system you first have to add it to Interface & Cloud Monitoring and select the monitoring categories you want to monitor for the system. 

  1. Open the Advanced Integration Monitoring Application by clicking on the 'Integration & Cloud Monitoring' tile in transaction FRUN
  2. Click on the pinwheel in the upper right corner of the 'Integration & Cloud Monitoring' application
  3. In the configuration panel expand the 'Technical Systems' tray and click on the pen icon in the upper right corner. This will open the 'Integration and Cloud Monitoring - Systems' view. 
  4. If your system is not on the list yet, click the 'Add' button to add it. If it is on the list, click on the system ID of the system. 

In the next step, you see all monitoring categories which are available for the system, depending on the system type and the installed software components. Some recommended standard monitoring categories are preselected.

Select the monitoring categories in scope.

Available Monitoring Categories

The available monitoring categories are:

  • bgRFC (Type Q): bgRFC of type queued
  • bgRFC (Type T): bgRFC of type transactional

To monitor bgRFC destinations and queues you can use the transactions SBGRFCMON (bgRFC Monitor), SBGRFCHIST (bgRFC Unit History), SBGRFCPERFMON (bgRFC Performance Monitor) and SLDQMON (LDQ Monitor). 

Please, select...

After selecting your monitoring categories you have to maintain filters to define what exactly you want to monitor. Some monitoring categories come with standard filters that usually just select all items of this monitoring category. SAP Focused Run can handle this high amount of monitoring data, so you can stick to this standard filters. Or you can set up filters of your own. You can create more than one filter for a monitoring category.

Available Filter Options

For bgRFC Monitoring, you can collect information on all destinations and units sent or received in the managed system. You can also use the following filter parameters, to restrict the data collection:

bgRFC (Type Q)

  • Direction: Choose I (Inbound) or O (Outbound)
  • Queue Name: Name of qRFC Queue
  • RFC Destination: RFC destination name (see SBGRFCMON → Details → Inbound/Outbound Destination Name)
  • Status Group: Choose E (Error) or L (Locked)

bgRFC (Type T)

  • Direction: Choose I (Inbound) or O (Outbound)
  • RFC Destination: RFC destination name (See SBGRFCMON → Details → Inbound/Outbound Destination Name)
  • Transaction Code: The name of the SAP transaction code with which the unit was created
  • Program: Tcode/program with which the unit was created
  • User: The name of the user under which the unit is recorded.
  • State: State of the unit (choose a state from the input help)
  • Status Group: Choose E (Error) or L (Locked)

Please, select...

The setup of the filters for the monitoring categories only makes sure that the data is collected, however, alerts are not created automatically. To create alerts and notifications you have to create an alert individually. If you didn't use specific filters in the setup before, but rather opted to collect all data, you have to create filters for the alerts.

  1. Click on the 'New Alert' button in the upper right corner of the alerts table. A new panel will appear below the table for you to enter the alert information
  2. Select the monitoring category
  3. Select the metric name. The available metrics depend on the monitoring category.
  4. Enter a name for the alert
  5. Enter a name for the filter

In the next sub-step, you have to maintain the filter. The filter values are the same as described above. For some metrics, you have to maintain metric parameters. Find details below in the overview of the available metrics.

In the last sub-step you have to activate the alert:

  1. Check the checkbox next to 'Active'
  2. You can adjust the calculation frequency and the severity
  3. Available threshold types depend on the metric selected. If the threshold type allows it you can adjust the threshold value which triggers the alert.
  4. Select the notification variant and the outbound connector variant from the drop-down list.

For single exceptions, the threshold type is always 'Already Rated'. This means depending on the calculation frequency the number of exceptions is checked and an alert is created if this number is bigger than 0. If you want to reduce the number of alert for these metrics, you could increase the value for the calculation frequency to increase the time between checks.

Available Metrics

For bgRFC Monitoring the following metrics are collected:

bgRFC (Type Q)

  • Number of bgRFC Type Q entries per queue group: Number of entries in the queue group(s) that fall in the selected status group
    Metric parameters:
    • STATE_GROUP = CRITICAL, INTERIM
    • OLDER_THAN_MINUTES = Only consider queues with entries older than X minutes 
  • Age of the oldest bgRFC Type Q entry per queue group: Age of the oldest entry in the queue group(s) that falls in the selected status group
    Metric parameters:
    • STATE_GROUP = CRITICAL, INTERIM
    • OLDER_THAN_MINUTES = Only consider queues with entries older than X minutes

bgRFC (Type T)

  • Number of bgRFC Type T entries: Number of bgRFC Type T entries per RFC destination and function module
    Metric parameters:
    • STATE_GROUP = CRITICAL, INTERIM
  • Age of the oldest bgRFC Type T entry: The age of the oldest bgRFC Type T entry per RFC destination and function module
    Metric parameters:
    • STATE_GROUP = CRITICAL, INTERIM

Further Information

SAP ABAP bgRFC is based on a scheduler-driven queuing framework. This means that remote function calls are recorded, and execution takes place at a later point in time, which is controlled automatically by a scheduler process. Several schedulers can be started to process bgRFC units.

It supports the following scenarios:

  • Processing on a remote system (outbound scenario)
    • Use case: Asynchronous transactional processing of function calls in a remote system; processing is controlled by the caller system (inter-system communication for SAP to SAP and SAP to non-SAP)
  • Processing remotely by the inbound scheduler (outbound-inbound scenario)
    • Use case: Asynchronous transactional processing of function calls in a remote system; processing is controlled by the receiver system (inter-system communication for SAP to SAP)
  • Processing on the same system (inbound scenario)
    • Use case: Asynchronous transactional processing of function calls in the same system (intra-system communication = same system and same client)
  • No-Send scenario
    • Use case: Successor to the qRFC's "No-Send" scenario, where outbound calls are recorded, but not sent by the outbound scheduler (pull principle). Instead, the receiving system is supposed to fetch its RFC records itself. In the bgRFC context, this is called Local Data Queue (LDQ).

The bgRFC provides two qualities of service (QoS) for remote function calls, offering an asynchronous transactional system-to-system communication:

  • exactly once (EO) => transactional units (like the classic tRFC): Each unit is an independent thread
  • exactly once in order (EOIO) => queue units (like the classic qRFC): Units with sequence dependencies

Quality of Service Outbound Inbound-Outbound Inbound No-Send
tRFC (EO) x - x -
qRFC(EOIO) x x x x