Execute a Fm in Background

[Former Member]

Hello experts,

please have a look at the part of the code in report below

.

.

CALL FUNCTION 'ME_PRICING_ALL'

• IN BACKGROUND TASK.

IMPORT EKOMV TO lt_KOMV FROM MEMORY ID 'RM06K010'.

loop at lt_komv.

write: / lt_komv-KWERT.

endloop.

in FM ('ME_PRICING_ALL') is syntax "EXPORT EKOMV TO MEMORY ID 'RM06K010'" and syntax with command WRITE .... ("report on the screen")

i don't want to "see" output(report) from FM ME_PRICING_ALL on the screen, so i called FM with "IN BACKGROUND TASK.", but I couldn't get the data from the FM.

When I'm running FM in foreground (without IN BACKGROUND TASK) I'm retrieving the data, but i don't want to see report in FM.

Thanks for help

Martin

[Former Member]

Hi,

Use the Commit work statement.

See the help on calling in background task...

The function modules registered for the current SAP LUW are started at the COMMIT WORK statement in the sequence, in which they were registered. The statement ROLLBACK WORK deletes all previous registrations of the current SAP LUW.

Regards,

Shiva Kumar

[Former Member]

Hi,

Check the following

Syntax

CALL FUNCTION func IN BACKGROUND TASK

DESTINATION dest

parameter list

AS SEPARATE UNIT.

Addition:

... AS SEPARATE UNIT

Effect

Transactional call of a remote-capable function module specified in func using the RFC interface. You can use the addition DESTINATION to specify an individual destination in dest. If the destination has not been specified, the destination NONE is used implicitly. Character-type data objects are expected for func and dest.

When the transactional call is made, the name of the called function, together with the destination and the actual parameters given in parameter list, are registered for the current SAP LUW in the database tables ARFCSSTATE and ARFCSDATA of the current SAP system under a unique transaction ID (abbreviated as TID, stored in a structure of type ARFCTID from the ABAP Dictionary, view using transaction SM58). Following this registration, the program making the call is continued by way of the statement CALL FUNCTION.

When executing the COMMIT WORK statement, the function modules registered for the current SAP LUW are started in the sequence in which they were registered. The statement ROLLBACK WORKdeletes all previous registrations of the current SAP LUW.

If the specified destination is not available for COMMIT WORK, an executable called RSARFCSE is started in the background. This attempts to start the functional modules registered for an SAP LUW in their destination, every 15 minutes up to a total of 30 times. You can make changes to these parameters using transaction SM59. If the destination does not become available within the given time, this is noted in the database table ARFCSDATA as a CPICERR entry. By default, this entry in database table ARFCSSTATE is deleted after 8 days.

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. What this means is 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.

You can use the function module ID_OF_BACKGROUNDTASK to define the transaction ID (TID) of the current SAP LUW, according to a transactional RFC.

The transactional RFC (tRFC) is suitable for realizing LUWs in distributed environments (a typical application is ALE). Here it must be noted that although executing the function modules within a transaction ID is predefined, the sequence of the LUWs on the RFC servers does not necessarily correspond to the sequence of SAP LUWs in the RFC client. To achieve a serialization on the RFC servers as well, the tRFC can be enhanced to queued RFC (qRFC). For this, you can call function module TRFC_SET_QUEUE_NAME before a transactional RFC.

CALL FUNCTION - IN BACKGROUND TASK parameter_list

Syntax

... http://EXPORTING p1 = a1 p2 = a2...

http://TABLES t1 = itab1 t2 = itab2 ... ... .

Effect

These additions are used to assign actual parameters to the formal parameters of the function module. The significance of the additions is the same as for synchronous RFC with the exception that no values can be copied with IMPORTING and CHANGING, and no return values can be allocated to exceptions that are not class-based.

Regards,

Raj.