‎2008 Apr 17 7:36 AM
hi,
this is my code
call function 'Z_IBD_FILL_ZINETACT'
in background task
destination 'SAPD220125'
tables
it_net1 = it_net1
it_net2 = it_net2
it_net3 = it_net3 .
when this code is executed i am not getting any data in my internal tables i.e it_net1, it_net2, and it_net3
but i changed this code see the below code
call function 'Z_IBD_FILL_ZINETACT'
in background task (THIS IS COMMENTED)
destination 'SAPD220125'
tables
it_net1 = it_net1
it_net2 = it_net2
it_net3 = it_net3 .
now i am getting data into my internal tables
can any one tell me what can be the problem and how to solve it in my case
its very urgent
‎2008 Apr 17 7:43 AM
Hi ram,
1.Actually the process of calling with destination is for RFC.
2.Suppose if you declared the function module as Remote enable then it works.
The syntax is:
CALL FUNCTION func IN BACKGROUND TASK
[DESTINATION dest]
parameter_list
[AS SEPARATE UNIT].
Regards,
Shiva Kumar(Reward if helpful).
‎2008 Apr 17 7:57 AM
hi as u said my function module is declared as remote enabled only i mean it is an RFC function module only
‎2008 Apr 17 7:47 AM
Hi,
Pls. go through the docu..
CALL FUNCTION
Variant 5
CALL FUNCTION func IN BACKGROUND TASK.
Additions:
1. ... AS SEPARATE UNIT
2. ... DESTINATION dest
3. ... EXPORTING p1 = f1 ... pn = fn
4. ... TABLES p1 = itab1 ... pn = itabn
Effect
Flags the function module func to be run asynchronously. It is not executed at once, but the data passed with EXPORTING or TABLES is placed in a database table and the next COMMIT WORK executes it in another work process.
Note
This variant applies only as of Release 3.0, so both the client system and the server system must be Release 3.0 or higher.
Note
qRFC with Outbound Queue
This is an extension of tRFC. The tRFC is serialized using queues, ensuring that the sequence of LUWs required by the application is observed when the calls are sent.
For further information about qRFC, refer to the Serialized RFC: qRFC With Outbound Queue section of the SAP Library.
Addition 1
... AS SEPARATE UNIT
Effect
Executes the function module in a separate LUW under a new transaction ID.
Addition 2
... DESTINATION dest
Effect
Executes the function module externally as a Remote Function Call (RFC); dest can be a literal or a variable.
Depending on the specified destination, the function module is executed either in another R/3 System or as a C-implemented function module. Externally callable function modules must be flagged as such in the Function Builder (of the target system).
Since each destination defines its own program context, further calls to the same or different function modules with the same destination can access the local memory (global data) of these function modules.
Note
Note that a database commit occurs at each Remote Function Call (RFC). Consequently, you may not use Remote Function Calls between pairs of statements that open and close a database cursor (such as SELECT ... ENDSELECT).
Addition 3
... EXPORTING p1 = f1 ... pn = fn
Effect
EXPORTING passes values of fields and field strings from the calling program to the function module. In the function module, formal parameters are defined as import parameters. Default values must be assigned to all import parameters of the function module in the interface definition.
Addition 4
... TABLES p1 = itab1 ... pn = itabn
Effect
TABLES passes references to internal tables. All table parameters of the function module must contain values.
Notes
If several function module calls with the same destination are specified before COMMIT WORK, these normally form an LUW in the target system. Calls with the addition 1 are an exception to this rule - they each have their own LUW.
You cannot specify type 2 destinations (R/3 - R/2 connections).
(See Technical details and Administration transaction.)
Example
REPORT RS41503F.
/* This program performs a transactional RFC.
TABLES: SCUSTOM.
SELECT-OPTIONS: CUSTID FOR SCUSTOM-ID DEFAULT 1 TO 2.
PARAMETERS: DEST LIKE RFCDES-RFCDEST DEFAULT 'NONE',
MODE DEFAULT 'N',
TIME LIKE SY-UZEIT DEFAULT SY-UZEIT.
DATA: CUSTITAB TYPE TABLE OF CUST415,
TAMESS TYPE TABLE OF T100,
WA_CUSTITAB TYPE CUST415.
SELECT ID NAME TELEPHONE INTO CORRESPONDING FIELDS OF TABLE CUSTITAB
FROM SCUSTOM WHERE ID IN CUSTID ORDER BY ID.
PERFORM READ_CUSTITAB.
EDITOR-CALL FOR CUSTITAB TITLE 'Editor for table CUSTITAB'.
PERFORM READ_CUSTITAB.
CALL FUNCTION 'TRAIN415_RFC_CALLTRANSACTION'
IN BACKGROUND TASK
DESTINATION DEST
EXPORTING
TAMODE = MODE
TABLES
CUSTTAB = CUSTITAB.
CALL FUNCTION 'START_OF_BACKGROUNDTASK'
EXPORTING
STARTDATE = SY-DATUM
STARTTIME = TIME
EXCEPTIONS
OTHERS = 1.
IF SY-SUBRC = 1.
EXIT.
ENDIF.
COMMIT WORK.
CALL TRANSACTION 'SM58'.
----
FORM READ_CUSTITAB *
----
FORM READ_CUSTITAB.
WRITE: / 'System ID:', SY-SYSID.
SKIP.
LOOP AT CUSTITAB into WA_CUSTITAB
WRITE: / WA_CUSTITAB-ID, WA_CUSTITAB-NAME,
WA_CUSTITAB-TELEPHONE.
ENDLOOP.
ULINE.
ENDFORM.
Pls. reward if useful....
‎2008 Apr 17 8:07 AM
Hi,
In background task, we cannot get the data in internal table because this FM is supposed to run in Background.
Thats why when it is not run in background u were able to see the data.
Because any FM called in background or update mode does the actual Database selects or DB updates at the next COMMIT WORK encountered.
These type of FMs are registerd in the current SAP LUW with transaction ID. Aand at the instant the COMMIT WORK is encountered all the TID's are executed together & that time u will be able to see the data.
I had also encountered the same problem what u have got.
If still not clear , lemme know...
Rewards points if found useful.
Thanks
SMS
Edited by: Sabu Samuel on Apr 17, 2008 9:09 AM
‎2008 Apr 17 9:53 AM
Hi Sabu,
Thank you for your valuable answer,
i am not so clear with what your are saying with the below lines
These type of FMs are registerd in the current SAP LUW with transaction ID. Aand at the instant the COMMIT WORK is encountered all the TID's are executed together & that time u will be able to see the data.
do u mean this
call function 'Z_IBD_FILL_ZINETACT'
in background task
destination 'SAPD220125'
tables
it_net1 = it_net1
it_net2 = it_net2
it_net3 = it_net3 .
commit work. (writing commit work extra, i did this change but no use)
if not what extra i need to write here
‎2008 Apr 24 12:17 PM
Hi Ram,
Did you find an answer to your query? am facing the same problem as yours ..
regards,
pallavika
‎2008 Apr 24 12:50 PM
i am unable to find the problem so
i have taken out this option copletely
and introduced few import parameters to this function module to restrict the data size
‎2008 Apr 24 12:54 PM
Hi ram,
1. If we use the 'background task' addition,
then we cannot get the results of the FM.
2. The reason is that such FM is
processed in separate session. Hence,
it is not like that it is processed and we get the results.
regards,
amit m.