Skip to content

ABAP Keyword Documentation →  ABAP − Reference →  Obsolete Language Elements →  Obsolete Data and Communication Interfaces →  Obsolete Transactional RFC 

CALL FUNCTION - IN BACKGROUND TASK

Quick Reference

Other versions: 7.31 | 7.40 | 7.54

Obsolete Syntax

CALL FUNCTION func IN BACKGROUND TASK
                   [AS SEPARATE UNIT]
                   [DESTINATION dest]
                   parameter_list.

Addition

... AS SEPARATE UNIT

Effect

Transactional call (tRFC) of a remote-enabled function module specified in func using the RFC interface. Using the addition DESTINATION, a unique destination can be specified in dest. If the destination is not specified, the destination "NONE" is used implicitly. func and dest expect character-like data objects.

The transactional call registers the name of the called function, together with the destination and the actual parameters passed in parameter_list for the current SAP LUW in the database tables ARFCSSTATE and ARFCSDATA of the current AS ABAP under a unique transaction ID (abbreviated as TID, stored in a structure of type ARFCTID from ABAP Dictionary, viewed using transaction SM58). After registration, the calling program is continued after the statement CALL FUNCTION.

When the COMMIT WORK statement is executed, the function modules registered for the current SAP LUW are started in the order in which they were registered. The statement ROLLBACK WORK deletes all previous registrations for the current SAP LUW.

If the specified destination is not available when COMMIT WORK is executed, an executable program called RSARFCSE is started in background processing. By default, this tries to start the function modules registered for a SAP LUW in their destination every 15 minutes and up to 30 times. Changes can be made to these parameters using transaction SM59. If the destination does not become available within the defined time, it is recorded in the database table ARFCSDATA as the entry "CPICERR". By default, this entry in database table ARFCSSTATE is deleted after eight days.


Note

background RFC (bgRFC) executed with the statement CALL FUNCTION IN BACKGROUND UNIT is the enhanced successor technology of transactional RFC (tRFC) and makes this technology obsolete. It is strongly recommended to use bgRFC instead of tRFC.

More Information

More information about tRFC can be found in the RFC documentation on SAP Help Portal.

Addition

... AS SEPARATE UNIT

Effect

When using the addition AS SEPARATE UNIT, the relevant function module is executed in a separate RFC session, in which the global data of the function group is not influenced by previous calls. Each function module that is registered with the addition AS SEPARATE UNIT is given a separate transaction ID. Without the addition AS SEPARATE UNIT, the usual description applies to the RFC session of the called function modules. This means that, when using the same RFC destination for multiple calls of function modules belonging to the same function group, the global data of this function group is accessed collectively.


Notes

  • The function module ID_OF_BACKGROUNDTASK can be used after a transactional RFC to determine the transactional ID (TID) of the current SAP LUW.
  • The transactional RFC (tRFC) is suitable for realizing LUWs in distributed environments (a typical application is ALE). Note that, although the execution of the function modules within a transaction ID is specified, the order of the LUWs on the RFC servers is not necessarily the same as the order of the SAP LUWs on the RFC client. To ensure the same serialization is also used on RFC servers, the tRFC can be enhanced as (queued RFC (qRFC)). For this, the function module TRFC_SET_QUEUE_NAME can be called before a transactional RFC. More information about qRFC can be found in the RFC documentation on SAP Help Portal.
  • If tRFC or qRFC are registered in a dialog module and are not started with COMMIT WORK, they are not executed by the COMMIT WORK of the caller.
  • The new variant CALL FUNCTION IN BACKGROUND UNIT (bgRFC) includes and enhances the existing tRFC and qRFC variants. For this reason, we strongly recommend using bgRFC instead of tRFC.
  • The statements COMMIT WORK and ROLLBACK WORK must not be executed within a LUW. In addition, no implicit database commit can be triggered there.
  • When handling the registration entries in the database tables ARFCSSTATE and ARFCSDATA, note that they are subject to the regular administration rules for a database LUW. For example, the database LUW is ended by a database rollback, all registration entries of the current database LUW are deleted.