11-30-2005 1:41 PM
Hi All,
I have a issue regarding fetching internal table data from one program to another.
Actually I have <b>Main Program</b> from that through SUBMIT statement i am calling another program and executing it for every 100 records - Actually this program is having BAPI running in it, By result i will get an internal table data. Now i want to get that internal table data back into my MAIN Program so that i can use it for next process.
<b>EXPORT & IMPORT statements are working from MAIN Program to Other Program.</b>
<b>EXPORT & IMPORT statements are not working from Other Program[SUBMIT'ed Program] to MAIN Program.</b>
So can anybody tell me how can i get that data in other program into MAIN Program[Back].
Thanks in advance.
Thanks & Regards,
Rayeez.
11-30-2005 1:48 PM
SUBMIT zvtest
WITH s_vbeln = p_vbeln
WITH s_posnr = p_posnr
WITH p_create = 'X'
EXPORTING LIST TO MEMORY
AND RETURN.
perform getresults.
FORM getresults .
DATA:it_list LIKE abaplist OCCURS 0.
DATA:BEGIN OF it_asc OCCURS 0,
txt(100),
END OF it_asc.
*-Get the report output from memory
CALL FUNCTION 'LIST_FROM_MEMORY'
TABLES
listobject = it_list
EXCEPTIONS
not_found = 1
OTHERS = 2.
IF sy-subrc = 0.
*-Get the report output from memory in ascii format
CALL FUNCTION 'LIST_TO_ASCI'
TABLES
listasci = it_asc
listobject = it_list
EXCEPTIONS
empty_list = 1
list_index_invalid = 2
OTHERS = 3.
LOOP AT it_asc.
IF sy-tabix > 2.
WRITE:/ it_asc-txt.
ENDIF.
ENDLOOP.
ELSE.
WRITE:/ p_vbeln, p_posnr, 'No data found for selection'.
ENDIF.
ENDFORM. " getresults
try to do it in this way...
11-30-2005 1:48 PM
Hi Shaik,
When you are saying that you are sending the data to the submit program, store it in the main program(Without refreshing it). It will be available in the main program as long as you don't refresh it.
Is there any limitation in this approach??
Regards,
ravi
11-30-2005 1:51 PM
Hi Shaik,
you can play with shared memory, but it's dangerous,
or maybe better solution, you could create a ref the table. Look the class CL_ALV_TABLE_CREATE, that's working in this way.
Rgd
Frédéric
look the program LSKBHF06 line 55-60
Message was edited by: Frédéric Girod
11-30-2005 1:51 PM
11-30-2005 2:05 PM
You need to use Shared Memeory. This memeory is global to all processes of the system.
F1 help.
<i>
Variant 4
EXPORT obj1 ... objn TO SHARED BUFFER dbtab(ar) ID key.
Additions:
1. ... = f (for each field you want to export)
2. ... FROM f (for each field you want to export)
3. ... CLIENT g (before ID key)
4. ... FROM wa (as last addition or after dbtab(ar))
In an ABAP Objects context, a more severe syntax check is performed that in other ABAP areas. See Implicit field names not allowed in clusters and Table work areas not allowed.
Effect
Stores a data cluster in the cross-transaction application buffer.The specified objects obj1 ... objn (fields, structures, or tables) are stored as a single cluster in the buffer.
The specified table dbtab must have a standard structure.
The buffer area for the table dbtab is divided into various logically-related areas (ar, two-character ID).
You can export a collection of data objects (data cluster) to an area of the buffer under a key of your own choosing (key field).
You can import individual data objects from this collection using the IMPORT statement (as long as the data has not been deleted from the buffer).
Notes
In classes, you must always specify explicit names for the data objects. Addition 1 or addition 2 is therefore obligatory.
In classes, you must always specify the work area explicitly. Addition 4 is therefore obligatory.
The table dbtab that you specify after SHARED BUFFER must be declared under TABLES (except in addition 4).
You cannot export the header line of an internal table. If you specify the name of an internal table with a header line, the system always exports the actual table data.
You cannot export data, object, and interface references.
Please consult Data Area and Modularization Unit Organization documentation as well.
Example
Exporting two fields and an internal table to the buffer with structure INDX:
TABLES INDX.
TYPES: BEGIN OF ITAB3_TYPE,
CONT(4),
END OF ITAB3_TYPE.
DATA: INDXKEY LIKE INDX-SRTFD VALUE 'KEYVALUE',
F1(4), F2 TYPE P,
ITAB3 TYPE STANDARD TABLE OF ITAB3_TYPE WITH
NON-UNIQUE DEFAULT KEY INITIAL SIZE 2,
WA_INDX TYPE INDX.
Fill data fields before CLUSTR
before the actual export
INDX-AEDAT = SY-DATUM.
INDX-USERA = SY-UNAME.
Export data.
EXPORT F1 FROM F1
F2 FROM F2
ITAB3 FROM ITAB3
TO SHARED BUFFER INDX(ST) FROM WA_INDX ID INDXKEY.
Addition 1
... = f (for each object you want to export)
Effect
Exports the contents of the field f and stores them under the specified name.
Addition 2
... FROM f (for each field you want to export)
Effect
Exports the contents of field f and stores them under the specified name.
Addition 3
... CLIENT g (before ID key)
Effect
The data objects are stored in client g (as long as the import/export table dbtab is client-specific).
Addition 4
... FROM wa (as last addition or after dbtab(ar))
Effect
Use this addition if you want to store user data fields in the application buffer. Instead of the table work area, the system uses the specified work area wa. The specified work area must have the same structure as the table dbtab.
Example
DATA WA LIKE INDX.
DATA F1.
WA-AEDAT = SY-DATUM.
WA-USERA = SY-UNAME.
WA-PGMID = SY-REPID.
EXPORT F1 = F1 TO SHARED BUFFER INDX(AR)
CLIENT '001' ID 'TEST'
FROM WA.
Note
Catchable runtime error
EXPORT_BUFFER_NO_MEMORY: The EXPORT data cluster is too big for the application buffer. This error should not occur often, since the buffer uses a procedure similar to the LRU(Least Recently Used) procedure to monitor the buffer contents. However, if the error does occur, you can increase the profile parameter rsdb/obj/buffersize (see Profile Parameter Attributes), which may help.
</i>
Also here is the help for IMPORT
<i>
Variant 6
IMPORT obj1 ... objn FROM SHARED BUFFER dbtab(ar)ID key.
Additions:
1. ... = f (for each object you want to import)
2. ... TO f (for each object you want to import)
3. ... CLIENT g (before ID key)
4. ... TO wa (last addition or after dbtab(ar))
In an ABAP Objects context, a more severe syntaxcheck is performed that in other ABAP areas. See No implicit field names allowed inclusters and Table work areas notallowed.
Effect
Imports the data objects obj1 ... objn (fields,structures, complex structures, or tables) from thecross-transaction application buffer. Thedata objects are read from table dbtab using the ID keyfrom area ar (see EXPORT TOSHARED BUFFER).
The return code is set as follows:
SY-SUBRC = 0:
Data objects imported.
SY-SUBRC = 4:
Unable to import data objects.
You may have used an incorrect ID.
The contents of all data objects listed in the statement remainunchanged.
Example
Importing two fields and an internal table from theapplication buffer with the structure indx:
TYPES: BEGIN OF ITAB3_LINE,
CONT(4),
END OF ITAB3_LINE.
DATA: INDXKEY LIKE INDX-SRTFD VALUE 'KEYVALUE',
F1(4),
F2(8) TYPE P DECIMALS 0,
ITAB3 TYPE STANDARD TABLE OF ITAB3_LINE,
INDX_WA TYPE INDX.
Import data
IMPORT F1 = F1 F2 = F2 ITAB3 = ITAB3
FROM SHARED BUFFER INDX(ST) ID INDXKEY TO INDX_WA.
After the import, the fields before CLUSTR
(INDX-AEDAT and INDX-USERA) are filled with the
values they had before the corresponding EXPORT
statement.
Notes
The table dbtab specified after DATABASEmust be declared under TABLES (except in addition 2).
The structures of the fields, structures, and internal tables youwant to import must be the same as those fo the objects you exported.The EXPORT and IMPORT statements (unlike IMPORT FROMDATABASE statement) does not check that they are the same. If thestructures are not the same, a runtime error may occur if invalidassignments are attempted during the operation. The objects must alsobe imported using the same name as that with which they wereexported. Otherwise, nothing is imported.
Please consult Data Area and Modularization Unit Organization documentation as well.
Addition 1
... = f (for each field you want to import)
Addition 2
... TO f (for each field you want to import)
Effect
Places the object in field f.
Addition 3
... CLIENT g (before ID key)
Effect
Takes the data from client g (if theimport/(export table dbtab is client-specific).
Addition 4
... TO wa (as last addition or afterdbtab(ar))
Effect
Use this addition if the application buffer containsuser data fields that you want to read. Instead of the table work area,the system uses the specified work area wa. The target area youspecify must have the same structure as dbtab.
Example
DATA: INDX_WA TYPE INDX,
F1.
IMPORT F1 = F1 FROM SHARED BUFFER INDX(AR)
CLIENT '001' ID 'TEST'
TO INDX_WA.
WRITE: / 'AEDAT:', INDX_WA-AEDAT,
/ 'USERA:', INDX_WA-USERA,
/ 'PGMID:', INDX_WA-PGMID.
</i>
Regards,
Rich Heilman
11-30-2005 2:22 PM
Hi All,
In Main Program i have the code like below.
SELECT * FROM zppe0091_01 INTO
CORRESPONDING FIELDS OF TABLE i_temp_zppe0091_01.
LOOP AT i_temp_zppe0091_01.
APPEND i_temp_zppe0091_01 TO i_temp_zppe0091_wa.
itab_index = sy-tabix MOD 5.
IF itab_index = 0.
EXPORT i_temp_zppe0091_wa TO SHARED BUFFER indx(st) ID 'KEY'.
Get Print Parameters
CALL FUNCTION 'GET_PRINT_PARAMETERS'
EXPORTING
no_dialog = 'X'
IMPORTING
valid = l_valid
out_parameters = ls_params.
open job
l_index = l_index + 1.
l_jobname = c_zeppe0091.
CONCATENATE l_jobname c_uc l_index INTO l_jobname.
CALL FUNCTION 'JOB_OPEN'
EXPORTING
jobname = l_jobname
IMPORTING
jobcount = l_jobcount.
submit report to job
SUBMIT z_update_material_master
VIA JOB l_jobname
NUMBER l_jobcount
TO SAP-SPOOL WITHOUT SPOOL DYNPRO
SPOOL PARAMETERS ls_params
AND RETURN.
sdate = sy-datum.
stime = sy-uzeit.
schedule and close job.
CALL FUNCTION 'JOB_CLOSE'
EXPORTING
jobcount = l_jobcount
jobname = l_jobname
strtimmed = 'X'.
CLEAR i_temp_zppe0091_wa.
REFRESH i_temp_zppe0091_wa.
ENDIF.
ENDLOOP.
In the SUBMIT Program[z_update_material_master] i have the code as follows:
IMPORT i_temp_zppe0091_wa FROM SHARED BUFFER indx(st) ID 'KEY'.
DELETE FROM SHARED BUFFER indx(st) ID 'KEY'.
LOOP AT i_temp_zppe0091_wa WHERE upd = c_x.
l_tabix = sy-tabix.
l_headdata-material = i_temp_zppe0091_wa-matnr.
l_plantdata-plant = i_temp_zppe0091_wa-werks.
l_plantdata-replentime = i_temp_zppe0091_wa-wzeit.
l_plantdatax-replentime = c_x.
CALL FUNCTION 'BAPI_MATERIAL_SAVEDATA'
EXPORTING
headdata = l_headdata
plantdata = l_plantdata
plantdatax = l_plantdatax
TABLES
returnmessages = i_temp_bapi_return.
IF NOT i_temp_bapi_return[] IS INITIAL.
READ TABLE i_temp_bapi_return WITH KEY type = c_s.
IF sy-subrc EQ 0.
i_marc_rpt-matnr = i_temp_zppe0091_wa-matnr.
i_marc_rpt-werks = i_temp_zppe0091_wa-werks.
APPEND i_marc_rpt.
CLEAR i_marc_rpt.
ELSE.
i_temp_zppe0091_wa-upd = space.
MODIFY i_temp_zppe0091_wa INDEX l_tabix TRANSPORTING upd.
ENDIF.
ENDIF.
ENDLOOP.
Now what i want is when i return back to My Main Program after submitting the [z_update_material_master] i want to get <b>i_marc_rpt</b> data back into main program.
Can anybody solve my issue.
Thanks in advance.
Thanks & Reagrads,
Rayeez.
11-30-2005 2:27 PM
When you submit the program is then running in parallel with the program which submitted it. There is no mechism that you are using to stop the calling program and wait for the submitted program to finish and bring back some data. Most likly program 1 ends before program 2 is finished updating the material master. You can do this kind of thing with Function modules. You would put your call to the submitted program inside of a function module, then call that function module saying STARTING IN NEW TASK, then you can wait for it to be done and get the results using the RECIEVING statement.
Here is the F1 Help.
+
CALL FUNCTION
Variant 2
CALL FUNCTION func ...STARTING NEW TASK task name.
Additions:
1. ... DESTINATION dest
2. ... DESTINATION IN GROUP group name
3. ... DESTINATION IN GROUP DEFAULT
4. ... PERFORMING form ON END OF TASK
5. ... EXPORTING p1 = f1 ... pn = fn
6. ... TABLES p1 = itab1 ... pn = itabn
7. ... EXCEPTIONS syst_except = rc MESSAGE mess
Effect
Starts the function module func asynchronously ina new session. In contrast to normal function module calls, the callingprogram resumes processing as soon as the function module is started inthe target system. It does not wait until the function module hasfinished. Through CALL SCREEN,the called function module can, for example, display a screen and thusinteract with the user.
Notes
This variant applies only from R/3 Release 3.0, so boththe client system and the server system must have Release 3.0 orhigher.
With this variant, the called function module must also be flagged inthe Function Builder as externally callable, even if it is executedlocally (without the addition DESTINATION).
There can be no function call to the destination 'BACK' in thecalled function module (for more information about the destination 'BACK', see CALLFUNCTION func DESTINATION dest).
This variant does not support the execution of externalprograms accessible via the destination of the TCP/IP type asasynchronous calls (see the Transaction Tools ¨Administration, Administration ¨ Network ¨ RFC destinations formaintaining destinations).
You cannot display screens (screens or lists asamodal windows in RFC communication using SAP Router.
From Release 4.0, you can check the load of each RFC destination moreclosely (in the RFC destination maintenance for an R/3 connection, choose Destination -> ARFC options). This checks whetherthe target host has sufficient resources before the function module isexecuted. If the target host is overloaded, the system delays executingthe function module. The algorithm for calculating the load on thetarget host is the same one used in an asynchronous RFC call using the DESTINATION IN GROUP addition. Note that this option can only beused with target hosts running Release 3.1H or higher. Note also thatit is the default setting.
In principle, parallelization makes sense whenever applicationservers have the necessary resources. In this case, the applicationservers must be configured with at least 3 dialog work processes.
A program that is run in the background and uses RFC parallelizationrequires at least 1 dialog work process per application server becausedialog processes use parallel execution.
If the instance profile parameter 'auth/rfc_authority_check'is set (to 1), the system automatically performs an RFC authorizationcheck. The authorization check refers to the relevant function groupfor the function module to be called. If no authorization is found, aruntime error occurs. You can check the authorization in advance withthe function module AUTHORITY_CHECK_RFC. If the communication takes place in the same system with thesame user context (same client and user ID), there is no authorizationcheck. For further information, refer to the RFCAuthorization Concept.
When you are using asynchronous RFC to implement parallel windows,all these windows are closed if the caller session is the only sessionand terminates.
ABAP_ADDITION_1&
... DESTINATION dest
Effect
Executes the function module externally as a RemoteFunction Call (RFC); dest can be a literal or a variable.The R/3 System where the function module is executed depends on thespecified destination. Externally callable function modules must beflagged as such in the Function Builder (of the target system).
Note
If the destination is not explicitly specified, the systemuses the default destination 'NONE'.
Note
If, during a RemoteFunction Call, an error occurs in the target system, detailsof the error message are passed bac to the calling system in thefollowing system fields: SY-MSGNO, SY-MSGID, SY-MSGTY, SY-MSGV1,SY-MSGV2, SY-MSGV3, and SY-MSGV4. These fields areinitialized before every RFC. If a short dump or a type X messageoccurs, the short text of the dump is transferred to the caller, andthe contents of SY-MSGID, SY-MSGTY, SY-MSGNO, and SY-MSGV1 assigned by the system.
In RFC-enabled function modules, no ABAP statements are allowed thatwould end the RFC connection (for example, LEAVE, SUBMIT or the ANDRETURN addition).
Note
Note that a database commit occurs at eachRemote Function Call (RFC). Consequently, you may not use RemoteFunction Calls between pairs of statements that open and close adatabase cursor (such as SELECT ... ENDSELECT).
Addition 2
... DESTINATION IN GROUP group name
Addition 3
... DESTINATION IN GROUP DEFAULT
Effect
You use this addition to perform parallel execution offunction modules (asynchronous calls) on a predefined group of R/3System application servers.
You use addition 2 (DESTINATION IN GROUP group name) toperform parallel execution of function modules on a predefined group ofapplication servers. To maintain the RFC groups, choose Tools ¨ Administration ¨ Administration ¨ Network ¨ RFCdestinations ¨ RFC ¨ RFC groups. The application programmer isresponsible for the availability of RFC groups in the productionsystem.
You use addition 3 (DESTINATION IN GROUP DEFAULT) to performparallel execution of function modules (asynchronous calls) on all currently available R/3 System application servers. However,instead of this variant, you are recommended to use an RFC group withappropriate resources for parallel processing of asynchronous calls (atleast for performance reasons). Please note that the additionDESTINATION IN GROUP ' ' has the same effect as the additionDESTINATION IN GROUP DEFAULT.
When you first call a function module with these additions, thesystem initializes the specified RFC group (provided no explicitinitialization has already been performed).
To obtain current information about resources (that is, the number ofresources available to process function modules), you can alsoinitialize the RFC group explicitly in the program via the functionmodule SPBT_INITIALIZE. You must perform this actionbefore the first function module call.
In both cases, the system first determines the number of currentlyavailable resources (work processes) on the available applicationservers (either a group of servers or all servers). By checking thecurrent system load of each application server, the system determineshow many work processes are available to execute asynchronous calls.
After determining the available resources, the asynchronous call isexecuted at one of the destinations. If no resources are available atthat particular time, the system executes the exception routine RESOURCE_FAILURE (see the addition EXCEPTIONS). In thecase of an asynchronous function module call, this exception must be handled by the application program (see example).
Parallel processing cannot take place if any of the resourcethresholds are exceeded.
Notes
In order to be taken into consideration for RFC parallelprocessing, an application server must have at least 3 freedialog processes.
The system triggers the exception RESOURCE_FAILURE only forasynchronous RFCs with the additions DESTINATION IN GROUP groupname and DESTINATION IN GROUP DEFAULT.
At present, only one RFC group per program environment issupported for parallel execution of asynchronous calls. Using both theadditions DESTINATION IN GROUP group name and DESTINATION INGROUP DEFAULT in a program is thus not allowed.
To find out which destination was automatically selected, call thefunction module SPBT_GET_PP_DESTINATION immediately after thefunction module call with the two additions. This returns the selectedRFC destination.
If you want to delete an application server from the list of theconfigured RFC group at runtime (for example, when the applicationserver is not accessible for technical reasons), use the functionmodule SPBT_DO_NOT_USE_SERVER.
Addition 4
... PERFORMING form ON END OF TASK
While the parameters for receiving results (i.e. IMPORTING andTABLES parameters) are specified directly as additions in thecase of "conventional" function modules (see variant 2), these arelogged in the FORM routine form when making anasynchronous call (see RECEIVE).
Notes
If a function module returns no result, and you are notinterested in error messages that arise when executing the functionmodule, this addition (... PERFORMING form ON END OF TASK) canbe omitted.
If you want to handle the error messages that arise when executingthe asynchronous function module call, you must use thisaddition. Also, when receiving the results in the FORM routine(see RECEIVE), you must reactaccordingly to the system exceptions SYSTEM_FAILURE andCOMMUNICATION_FAILURE.
With asynchronous RFC, the task name uniquely identifies theasynchronous connection and thus the context called.
If several asynchronous function modules are executed consecutivelyto the same destination, you must assign a different task name to each.
A calling program that starts an asynchronous RFC with PERFORMINGform ON END OF TASK cannot switch roll areas or change to aninternal session. This is because the asynchronous function module callreply cannot be passed on to the relevant program. You can perform aroll area switch with SUBMIT or CALL TRANSACTION.
If a calling program makes asynchronous calls, finishes, and thenexpects responses, these responses cannot be delivered.
To wait for the reply to a started asynchronous function module, usethe WAIT command with the additionPERFORMING form ON END OF TASK. Here, WAIT must be in thesame program context (session).
Note that the execution of the asynchronous calls involves a changeof roll area. This means that the FORM routines for receivingthe external calls can be processed while you are making furtherexternal calls. This means that the developer must ensure thatthe FORM routines can be executed at any time. You cannotmake any assumptions about the processing sequence.
Addition 5
... EXPORTING p1 = f1 ... pn = fn
Effect
EXPORTING passes values of fields and fieldstrings from the calling program to the function module. In thefunction module, the formal parameters are defined as importparameters.
Addition 6
... TABLES p1 = itab1 ... pn = itabn
Effect
TABLES passes the contents of internal tables.
Addition 7
... EXCEPTIONS syst_except = rc MESSAGE mess
Effect
While any exceptions arising in the called functionmodule are handled by the second addition (in the FORM routine),this addition can handle two special system exceptions, as withfunction module calls with the addition DESTINATION:
SYSTEM_FAILURE
is triggered, if a system crash occurs on the receiving side.
COMMUNICATION_FAILURE
is triggered if there is a connection or communication problem.
In both cases, you can get a description of the error with theoptional addition
... MESSAGE msg
Note
In principle, you should always react to these twosystem exceptions, whether you are making an asynchronous functionmodule call or receiving results.
Examples
Asynchronous call to a transaction and display in a separate session.
DATA: MSG_TEXT(80) TYPE C. "Message text
...
Asynchronous call to Transaction SM59 -->
Create a new session
CALL FUNCTION 'ABAP4_CALL_TRANSACTION' STARTING NEW TASK 'TEST'
DESTINATION 'NONE'
EXPORTING
TCODE = 'SM59'
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG_TEXT
SYSTEM_FAILURE = 2 MESSAGE MSG_TEXT.
IF SY-SUBRC NE 0.
WRITE: MSG_TEXT.
ELSE.
WRITE: 'O.K.'.
ENDIF.
Using RFC groups to parallelize function module calls (RFC parallelprocessing)
TYPES: BEGIN OF TASKLIST_TYPE,
TASKNAME(4) TYPE C, "Task administration
RFCDEST LIKE RFCSI-RFCDEST
END OF TASKLIST_TYPE.
DATA: INFO LIKE RFCSI, C, "Message text
JOBS TYPE I VALUE 10, "Number of parallel jobs
SND_JOBS TYPE I VALUE 1, "Sent jobs
RCV_JOBS TYPE I VALUE 1, "Received replies
EXCP_FLAG(1) TYPE C, "Number of RESOURCE_FAILUREs
TASKNAME(4) TYPE N VALUE '0001', "Task name administration
TASKLIST TYPE TABLE OF TASKLIST_TYPE,
WA_TASKLIST TYPE TASKLIST_TYPE.
...
DO.
...
CALL FUNCTION 'RFC_SYSTEM_INFO'
STARTING NEW TASK TASKNAME DESTINATION IN GROUP DEFAULT
PERFORMING RETURN_INFO ON END OF TASK
EXCEPTIONS
COMMUNICATION_FAILURE = 1
SYSTEM_FAILURE = 2
RESOURCE_FAILURE = 3.
CASE SY-SUBRC.
WHEN 0.
Administration of asynchronous tasks
WA_TASKLIST-TASKNAME = TASKNAME.
CLEAR WA_TASKLIST-RFCDEST.
APPEND WA_TASKLIST TO TASKLIST.
WRITE: / 'Started task: ', WA_TASKLIST-TASKNAME COLOR 2.
TASKNAME = TASKNAME + 1.
SND_JOBS = SND_JOBS + 1.
JOBS = JOBS - 1. "Number of existing jobs
IF JOBS = 0.
EXIT. "Job processing finished
ENDIF.
WHEN 1 OR 2.
Handling of communication and system failure
...
WHEN 3. "No resources available at present
Receive reply to asynchronous RFC calls
IF EXCP_FLAG = SPACE.
EXCP_FLAG = 'X'.
First attempt for RESOURCE_FAILURE handling
WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '0.01' SECONDS.
ELSE.
Second attempt for RESOURCE_FAILURE handling
WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '0.1' SECONDS.
ENDIF.
IF SY-SUBRC = 0.
CLEAR EXCP_FLAG. "Reset flag
ELSE. "No replies
"Endless loop handling
...
ENDIF.
ENDCASE.
ENDDO.
...
Receive remaining asynchronous replies
WAIT UNTIL RCV_JOBS >= SND_JOBS.
LOOP AT TASKLIST INTO WA_TASKLIST.
WRITE:/ 'Received task:', WA_TASKLIST-TASKNAME COLOR 1,
30 'Destination: ', WA_TASKLIST-RFCDEST COLOR 1.
ENDLOOP
...
FORM RETURN_INFO USING TASKNAME.
RECEIVE RESULTS FROM FUNCTION 'RFC_SYSTEM_INFO'
IMPORTING RFCSI_EXPORT = INFO
EXCEPTIONS
COMMUNICATION_FAILURE = 1
SYSTEM_FAILURE = 2.
RCV_JOBS = RCV_JOBS + 1. "Receiving data
IF SY-SUBRC NE 0.
Handling of communication and system failure
...
ELSE.
READ TABLE TASKLIST WITH KEY TASKNAME = TASKNAME
INTO WA_TASKLIST
IF SY-SUBRC = 0. "Register data
WA_TASKLIST-RFCDEST = INFO_RFCDEST.
MODIFY TASKLIST INDEX SY-TABIX FROM WA_TASKLIST.
ENDIF.
ENDIF.
...
ENDFORM
Note
If you encounter problems, refer toTypical RFC problems and theirsolutions.
Note
Runtime errors:
Note
Runtime errors:
CALL_FUNCTION_NO_RECEIVER:
Data received for an unknown CPI-C connection.
CALL_FUNCTION_DEST_TYPE:
Destination type not allowed.
CALL_FUNCTION_NO_DEST:
Specified destination does not exist.
CALL_FUNCTION_NO_LB_DEST:
Specified destination (in load distribution mode) does not exist.
CALL_FUNCTION_TABINFO:
Data error (info internal table) in a Remote Function Call.
CALL_BACK_ENTRY_NOT_FOUND:
The called function module is not released for use in RFC.
CALL_FUNCTION_FIELD_NOT_FOUND:
The function parameter that you passed is not recognized on therecipient side.
RFC_NO_AUTHORITY:
The user does not have RFC authorization.
CALL_FUNCTION_SINGLE_LOGIN_REJ:
No authorization to log on as a trusted system. The error codeshave the following meanings:
0) Valid security key but wrong logon data 1) Calling system is not a trusted system, or security key is invalid 2) User either does not have RFC authorization (authorization object S_RFCACL), or logged on as one of the protected users 'DDIC' or 'SAP*' 3) Timestamp of the logon data is invalid
CALL_FUNCTION_DESTINATION_NO_T:
Missing communication type (I for internal connection, 3 for R/3) in anasynchronous RFC
CALL_FUNCTION_NOT_REMOTE:
The function module called is not flagged as "RFC supported"
CALL_FUNCTION_REMOTE_ERROR:
An error occurred during the Remote Function Call. This has been loggedin the target system.
CALL_FUNCTION_SIGNON_INCOMPL:
The logon data for the user is incomplete.
CALL_FUNCTION_SIGNON_INTRUDER:
You cannot log onto a target system using an internal call.
CALL_FUNCTION_SIGNON_INVALID:
External RFC without a valid user name.
CALL_FUNCTION_SIGNON_REJECTED:
Attempt to log onto a target system without a valid user name. Theerror code can have the following meanings:
1) Wrong password or invalid user ID
2) User locked
3) Too many logon attempts
4) Error in authorization buffer (internal error)
5) No external user check
6) Invalid user type
7) Validity period of user has expired
CALL_FUNCTION_SYSCALL_ONLY:
RFC without a valid user name only allowed when calling system functionmodules. For the meaning of the error codes, refer toCALL_FUNCTION_SINGLE_LOGIN_REJ.
CALL_FUNCTION_TABLE_NO_MEMORY:
No memory available for a table to be imported
CALL_FUNCTION_TASK_IN_USE:
Asynchronous RFC only: Task name already in use.
CALL_FUNCTION_TASK_YET_OPEN:
Asynchronous RFC only: The specified task is already open.
CALL_FUNCTION_SNC_ERROR:
Error reading the SNC information for the destination.
CALL_RPERF_SLOGIN_READ_ERROR:
No valid trusted system entry for the calling system.
CALL_RPERF_SLOGIN_AUTH_ERROR:
No trusted authorization for the RFC caller and trusted system.
+
Regards,
Rich Heilman