Get Example source ABAP code based on a different SAP table
CALL FUNCTION - IN BACKGROUND TASK
Short Reference > • IN BACKGROUND TASK CALL FUNCTION • DESTINATION CALL FUNCTION IN BACKGROUND TASK
ABAP Syntax CALL FUNCTION func IN BACKGROUND TASK> [AS SEPARATE UNIT]> [DESTINATION dest]> parameter_list>>.
ABAP Addition ... AS SEPARATE UNIT>
What does it do? Transactional call (tRFC>) of aremote-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.
More Information> Extensive information about tRFC> can be found under Transactional RFC (tRFC> )> in the SAP Library. • AS SEPARATE UNIT CALL FUNCTION IN BACKGROUND TASK
ABAP Addition
What does it do? 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.
Latest 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>>. Transactional RFC (tRFC>) is suitable for realizing LUW>s 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 LUW>s 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. 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.