The objects destination each represent exactly one execution destination or a set of execution destinations. Destination objects can be requested using the class methods from the class CL_BGRFC_DESTINATION_OUTBOUND for the outbound queue and the class CL_BGRFC_DESTINATION_INBOUND for the inbound queue. The destination for the outbound queue must be maintained in the transaction SM59 and represent an execution destination for the outbound bgRFC type t and type q. The destination for the inbound queue must be maintained in the transaction SBGRFCMAINIDST. If the destination is not valid, the exception CX_BGRFC_INVALID_DESTINATION is produced.
The destination objects are valid for the entire runtime of the program.
It was very important to automatically register destinations that had not yet been registered for the outbound queue, as an unregistered destination is always flagged as 'old'. If this unregistered destination is now filled by accident with the new API, in the event of an automatic registration, the destination must be switched to 'old' first before the system behaves again as it did previously. Switching destinations is a critical operation, especially if queues to this destination have been filled already, or if the destination is already used in an internal mode. In this case, the new bgRFC type t and type q can be activated and the new RFC protocol can be used.
Destinations NONE and SPACE are not supported. Exactly one object is created for every execution destination within an internal mode, which means, destination is a singleton for every execution destination.
The interfaces IF_BGRFC_DESTINATION_OUTBOUND and IF_BGRFC_DESTINATION_INBOUND enable access to the necessary methods for requesting new background units. The underlying classes are not relevant for the use of t/qRFC and are only shown in the following UML diagram for the sake of completeness.
You can use destination objects to control whether the background unit is to be processed in the local (inbound) or remote (outbound) system.
The difference between qRFC units of type q and bgRFC units of type t is the required quality of service (Q-o-S). For bgRFC type q, the quality of service is exactly once in order (EOIO) and for type t the quality of service is exactly once (EO). To be able to guarantee the sequence of bgRFC type q units and, at the same time, parallelize independent units, the dependencies are implemented using queues. bgRFC type t units do not belong to a queue and can therefore always be processed in parallel.
In some cases it is necessary to send a unit from various destinations. To avoid building multiple units, you can create destination groups with the method CREATE_GROUP. The specified destinations must comply with the properties that are required in the method CREATE. In addition, all destinations grouped in a destination group must use the same RFC protocol. If this is not the case, the exception CX_BGRFC_INVALID_DESTINATION is produced.