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.

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

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)

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)

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

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