Skip to content

ABAP Keyword Documentation →  ABAP - Reference →  Data Interfaces and Communication Interfaces →  Remote Function Call →  CALL FUNCTION - RFC →  CALL FUNCTION - IN BACKGROUND 

CALL FUNCTION - IN BACKGROUND TASK

Short Reference

Other versions: 7.31 | 7.40 | 7.54

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. You can make changes 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.

Further information

Extensive information about tRFC can be found under Transactional RFC (tRFC) in the SAP Library.

Addition

... AS SEPARATE UNIT

Effect

When using the addition AS SEPARATE UNIT, the relevant function module is executed in a separate context, a context 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 is applicable for the context of the called function modules. This means that, when using the same destination for multiple calls of function modules belonging to the same function group, the global data of this function group is accessed collectively.


Notes

  • You can use the function module ID_OF_BACKGROUNDTASK after a transactional RFC to determine the transactional ID (TID) of the current SAP LUW.
  • 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, you can call function module TRFC_SET_QUEUE_NAME before a transactional RFC.
  • If tRFC or qRFC are registered in a dialog module and are not started with COMMIT WORK, then 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, then all registration entries of the current database LUW are deleted.