Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Regading getting data to and forth between 2 programs through SUBMIT

Former Member
0 Kudos

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.

7 REPLIES 7

former_member188685
Active Contributor
0 Kudos
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...

former_member181962
Active Contributor
0 Kudos

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

FredericGirod
Active Contributor
0 Kudos

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

Former Member
0 Kudos

Shaik,

Use SAP Memory!!!!

Thanks

Kam

0 Kudos

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

0 Kudos

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.

0 Kudos

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