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:
Decoupling and (potentially) parallelization
are possible. The load is spread across the available application servers for
This bgRFC scenario is known as an inbound procedure.
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.
Here you can take advantage of all the optimization options. If you choose this option, however, 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 both database and for the application server 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 them. 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.
Combined use of the bgRFC with tRFC and qRFC in a single destination is not possible. 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. This ensures a correct execution sequence, even when changing from a qRFC to a bgRFC.
Changing back from bgRFC to qRFC is not supported.
For more information about managing and programming the bgRFC, see: