The bgRFC allows applications to record data that is received later by a called application. When the data is received, you must ensure that the data was transferred to the receiver either once only in any order ( transactional) or once only in the order of creation ( queued).
With the bgRFC, therefore, the asynchronies between the caller and the called application can result in the following advantages:
Within an SAP system (same system ID, same client).
Decoupling and (potentially) parallelization are possible. The load is spread across the available application servers for this system. This bgRFC scenario is known as an inbound procedure.
Between two remote SAP Systems
Decoupling and therefore the physical segmentation of an application or a business scenario are possible. As a result of the asynchronies, differences in the key features of the application servers for the called and calling applications can be balanced out. The recording is done in the calling system. This scenario is an outbound procedure.
Both procedures can be combined in an out-in procedure.
Here you can take advantage of all the optimization options. However, if you chose to do this, the data is recorded twice, once for the caller ( outbound processing) and once for the called application (special type of the inbound procedure). This results in additional load for the database, and for the application server as well due to the scheduler.
The bgRFC organizes the different calls using queues. A call that is placed in several queues at the same time creates a dependency between these queues. This leads to a synchronization point, which is similar to a lock.
The dependent queues can be processed until the entry for processing is at the head of the queue that defines the dependency. This entry can only then be processed if it is at the head of all the queues.
This is a very powerful function (for example, for managing documents in logistics). If used incorrectly by application development it can stop queue processing.
The bgRFC offers developers an API that can be used to define the properties of the transfer and record the data.
The recording is done by means of a call to an RFC-enabled function module. Multiple function module calls can be bundled together to form a unit. The unit is the then the unit of the transfer. It is either transferred entirely or awaits transfer.
A combined use of the bgRFC with tRFC and qRFC is not possible within a destination. However, for each destination you can define which communication type you want to use.
Applications that convert qRFC to bgRFC must support a migration scenario in which a temporary link between queues in the qRFC and queues in the bgRFC is created. In this way, the correct execution sequence is ensured, even when changing from a qRFC to a bgRFC.
Changing back from bgRFC to qRFC is not supported.
As of SAP NetWeaver Release 7.11 and higher, bgRFC can also be used with the basXML communications protocol.