CALL_FUNCTION_REMOTE_ERROR
I’m building a program that will call an asynchronous RFC repeatedly, for downloading files from a DMS document server to a local directory on the presentation server.
In order to do this, I am calling the function a number of times in parallel (based on number of available processes). However, I keep getting dumps of type CALL_FUNCTION_REMOTE_ERROR, due to problems in the form defined as «on end of task». Here’s my sample code:
call function ‘ZCA_MY_DOWNLOAD_RFC’
starting new task taskname
destination in group default
performing reduce_process_counter on end of task
In the «reduce_process_counter» form, the following code is executed:
receive results from function ‘ZCA_MY_DOWNLOAD3_RFC’
changing ch_taskname = lv_taskname.
Note that the «changing» parameter is defined in the function module and is working OK in most cases.
Now, the issue is the following: In most cases, the logic functions. I have a parameter in the calling program, allowing me to specify how many RFC calls I should run in parallell (based on available processes in the app servers). However, every once in a while — and especially if I run more than 2 or 3 calls in parallel, I get the CALL_FUNCTION_REMOTE_ERROR. This occurs on the «receive results» statement, with the dump reading «ThISend: bad tm type / connection closed (no data)».
It seems to me that my RFC’s are «running wild» once I allow more than 2 or 3 of them to run in parallel. Again, there is no consistent behaviour here — some times, I can launch 5 in parallel; 8 will terminate properly, but the 9th will crash with the above error. I have implemented logging fuinctionality using a specific Z-table, so I can monitor the behaviour of bot the main program and the RFC’s. Also, by checking SM66, I see my 5 processes running peacefully in parallel, until one suddenly «explodes».
CALL_FUNCTION_REMOTE_ERROR
We are receiving dumps — CALL_FUNCTION_REMOTE_ERROR for a single user.
«call to messaging system failed:
Error in the ABAP Application Program
The current ABAP program «/SIE/SAPLMED_SM_LIC_CMDBTRANS» had to be terminated
come across a statement that unfortunately cannot be executed.
The error occurred during an RFC call to another system.
In the target system, a short dump has been written as well.
More detailed information on the error cause can be found there.
An error occurred when executing a REMOTE FUNCTION CALL.
It was logged under the name «RFC_EXTERNAL_ABORT»
on the called page.
How to correct the error
Please refer to the notes described in the
Operating system. «Linux»
Hardware type. «x86_64»
Character length. 8 Bits
Pointer length. 64 Bits
Work process number.. 26
Shortdump setting. «full»
What can you do?
Note down which actions and inputs caused the error.
To process the problem further, contact you SAP system
Using Transaction ST22 for ABAP Dump Analysis, you can look
at and manage termination messages, and you can also
keep them for a long time.
An error occurred when executing a REMOTE FUNCTION CALL.
It was logged under the name «RFC_EXTERNAL_ABORT»
on the called page.
Database type. «ORACLE»
Database user ID.. «SAPSR3»
create on. «Linux GNU SLES-9 x86_64 cc4.1.2 «
Database version. «OCI_102, 11.2.0.2.0, V1, default»
Patch level. 500
Database. «ORACLE 10.1.0.*.*, ORACLE 10.2.0.*.*, ORACLE 11.2.*.*.*»
SAP database version. 720
Operating system. «Linux 2.6, Linux 3»
MM Used. 1131744
Transactions ID. «210a0096db0d11e3c3a300001844cfe4»
Screen. «SAPMSSY1 3004»
Information on caller of Remote Function Call (RFC):
Database Release. 700
Kernel Release. 720
Connection Type. 3 (2=R/2, 3=ABAP System, E=Ext., R=Reg. Ext.)
Call Type. «synchronous and transactional type T (emode 0, imode 0)»
Inbound Queue Name. » «
Outbound TID. «9DA3889564635372D4940242»
Outbound Queue Name..» «
Call Program. «SAPLERFC»
Function Module. «ARFC_DEST_SHIP»
Call Destination. «NONE»
Source Server. «_00»
Source IP Address. «157.163.136.149»
Additional information on RFC logon:
Logon Return Code. 0
Trusted Return Code. 0
Transactions ID. «210a0096db0d11e3c3a300001844cfe4»
Screen. «SAPMSSY1 3004»
Information on caller of Remote Function Call (RFC):
Database Release. 700
Kernel Release. 720
Connection Type. 3 (2=R/2, 3=ABAP System, E=Ext., R=Reg. Ext.)
Call Type. «synchronous and transactional type T (emode 0, imode 0)»
RECEIVE
Basic form
RECEIVE RESULTS FROM FUNCTION func.
Extras:
Effect
Receives the results returned by a function module called asynchronously ( CALL FUNCTION func STARTING NEW TASK taskname ). This ABAP statement is used within a FORM routine. The form routine must have a place holder for passing the task name (for example, USING taskname — see example), and it can only be used to receive and execute simple ABAP statements. It cannot contain any statements that interrupt the program execution (such as CALL SCREEN , CALL DIALOG , CALL TRANSACTION , SUBMIT , COMMIT WORK , WAIT , Remote Function CAlls, CPIC calls), or any warning or information messages that use the MESSAGE statement.
Notes
This statement is only used in conjunction with a function module call of the form CALL FUNCTION func STARTING NEW TASK taskname . If the function module does not return any values, you do not need to define this part.
The FORM routine must contain the statement RECEIVE RESULTS FROM FUNCTION func , otherwise it cannot recieve the results, and the remote context (remote tasks ) is not concluded. This eventually leads to the application server being overloaded.
This statement has only existed since R/3 Release 3.0. Therefore, both partner systems (client and server) must have Release 3.0 of the system or higher.
You can wait for the response from an asynchronous function call ( PERFORMING form ON END OF TASK ) using the WAIT statement. WAIT must appear in the same program context.
You can collect the results of an asynchronous call in dialog mode when the roll area changes or by using WAIT (both dialog and background processing).
If the calling program ends without receiving the reply from the asynchronous function module, the values cannot be delivered.
The FORM routine in which you evaluate the relevant tasks should only be used to receive the results of the asynchronous tasks. If you use WRITE statements in the form routine, the list output is suppressed.
Note that the asynchronous task is not necessarily terminated if the calling program terminates.
Since the FORM routine runs in the same program context as the main program, they should not both use the same global data structures.
Addition 1
Effect
This addition stops the asynchronous connection from being terminated once the results have been received. Instead, the remote context (roll area) is retained until the calling program ends. This allows you to re-address and use the same context (and roll area) under the same name.
Notes
Only use this addition if you want to reuse the remote context in a later asynchronous call. Otherwise, the context is retained until the calling program ends, leading to increased memory requirements and impaired performance in the remote system.
If the remote function module contains user dialogs (lists or screens), the screen output remains active until the calling program ends. If the asynchronous call is made in debugging mode, the remote debugging dialog remains visible until the end of the caller’s dialog.
Addition 2
. IMPORTING p1 = f1 . pn = fn
Effect
IMPORTING returns values from fields and structures in the function module to the calling progam. In the function module, the corresonding parameters are defined as export parameters. You can pass any number of these parameters.
Addition 3
. TABLES p1 = itab1 . pn = itabn
Effect
TABLES passes the contents of internal tables.
Addition 4
. EXCEPTIONS except1 = rc1 . exceptn = rcn
Effect
Besides the exceptions generated by the function module called, you should also handle two special system exceptions here (as when you call function modules using the DESTINATION addition):
SYSTEM_FAILURE
is triggered if the receiving system crashes.
COMMUNICATION_FAILURE
is triggered if the connection cannot be established or the communication fails.
In either case, you can use the optional addition
to receive a description of the error.
You should always handle these two system exceptions both in the asynchronous function call and when you receive the results.
Example
DATA: INFO LIKE RFCSI,
* Result of the RFC_SYSTEM_INFO function
MSG(80) VALUE SPACE,
* Exception handling
RET_SUBRC like SY-SUBRC.
* SY-SUBRC handling
CALL FUNCTION ‘RFC_SYSTEM_INFO’
STARTING NEW TASK ‘INFO’
PERFORMING RETURN_INFO ON END OF TASK
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG
SYSTEM_FAILURE = 2 MESSAGE MSG.
IF SY-SUBRC = 0.
WRITE: ‘Wait for response’.
ELSE.
WRITE MSG.
ENDIF.
.
AT USER-COMMAND.
* Return from the form routine RETURN_INFO using SET USER-COMMAND
IF SY-UCOMM = ‘OKCD’.
IF RET_SUBRC = 0.
WRITE: ‘Destination =’, INFO-RFCDEST.
ELSE.
WRITE MSG.
ENDIF.
ENDIF.
.
FORM RETURN_INFO USING TASKNAME.
RECEIVE RESULTS FROM FUNCTION ‘RFC_SYSTEM_INFO’
IMPORTING RFCSI_EXPORT = INFO
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG
SYSTEM_FAILURE = 2 MESSAGE MSG.
RET_SUBRC = SY-SUBRC. «Setn RET_SUBRC
SET USER-COMMAND ‘OKCD’. «Set OK_CODE
ENDFORM.
Wie das obige Beispiel zeigt, kann man in der FORM -Routine, in der die Auswertung des betreffenden Tasks vorgenommen wird, mit Hilfe der Anweisung SET USER-COMMAND ein Listen-Ereignis ausgelöst werden. Dieses kann dann im Rahmenprogramm im AT USER-COMMAND -Zeitpunkt (z. B. zweck Administration der asynchronen Aufrufe) verarbeitet werden. Hierbei wird nicht immer gewährleistet, daß nach jedem SET USER-COMMAND der AT USER-COMMAND ausgeführt wird.
The SET USER-COMMAND statement in screen processing in this case causes the last PAI module of the preceding screen to be processed with the specified user command as its OK_CODE . This does not ensure that the user command processing is executed after each SET USER-COMMAND statement. In debugging mode, for example, the statement is ineffective (the SET USER-COMMAND event is not processed).
For the purpose of adminstration of asynchronous function module calls (especially in background mode), you can use the WAIT statement. The above example, using the WAIT statement instead of SET USER-COMMAND , would then look like this:
Example
DATA: INFO LIKE RFCSI,
* Results of RFC_SYSTEM_INFO function
MSG(80) VALUE SPACE,
* Exception handling
RET_SUBRC like SY-SUBRC,
* SY-SUBRC handling
SEMAPHORE(1) TYPE C VALUE SPACE.
* Flag for receiving asynchronous results
CALL FUNCTION ‘RFC_SYSTEM_INFO’
STARTING NEW TASK ‘INFO’
PERFORMING RETURN_INFO ON END OF TASK
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG
SYSTEM_FAILURE = 2 MESSAGE MSG.
IF SY-SUBRC = 0.
WRITE: ‘Wait for the answer’.
ELSE.
WRITE MSG.
ENDIF.
.
CLEAR SEMAPHORE.
WAIT UNTIL SEMAPHORE = ‘X’.
* Return from the form routine RETURN_INFO
IF RET_SUBRC = 0.
WRITE: ‘Destination =’, INFO-RFCDEST.
ELSE.
WRITE MSG.
ENDIF.
.
FORM RETURN_INFO USING TASKNAME.
RECEIVE RESULTS FROM FUNCTION ‘RFC_SYSTEM_INFO’
IMPORTING RFCSI_EXPORT = INFO
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG
SYSTEM_FAILURE = 2 MESSAGE MSG.
RET_SUBRC = SY-SUBRC. «Set RET_SUBRC
SEMAPHORE = ‘X’. «Set semaphore
ENDFORM.
Non-Catchable Exceptions
- CALL_FUNCTION_NO_RECEIVER : Data received for unknown CPIC connection. Error triggered because an answer to an asynchronous function call has been received by CPIC protocol that could not be forwarded to the correct program context. This situation occurs when you use a SUBMIT or CALL TRANSACTION statement after the PERFORMING form ON END OF TASK statement. The SUBMIT statement generates a new internal session that can prevent the results from the function call being forwarded to the internal session from which the function module was called.
Exceptions for RFC
Non-Catchable Exceptions
- Cause: The called function module has not been released for RFC.
Runtime Error: CALL_BACK_ENTRY_NOT_FOUND - Cause: Destination type is not allowed.
Runtime Error: CALL_FUNCTION_DEST_TYPE - Cause: Missing communication type (I for internal connection, 3 for R/3) when calling an asynchronous RFC
Runtime Error: CALL_FUNCTION_DESTINATION_NO_T - Cause: The destination entered does not exist.
Runtime Error: CALL_FUNCTION_NO_DEST - Cause: The destination entered (in load distribution mode) does not exist.
Runtime Error: CALL_FUNCTION_NO_LB_DEST - Cause: Data received for unknown CPI-C connection.
Runtime Error: CALL_FUNCTION_NO_RECEIVER - Cause: The function module you tried to call is flagged as one that cannot be called remotely.
Runtime Error: CALL_FUNCTION_NOT_REMOTE - Cause: An error occurred when calling the function remotely. This error is logged in the calling system.
Runtime Error: CALL_FUNCTION_REMOTE_ERROR - Cause: The logon data for the user is not complete.
Runtime Error: CALL_FUNCTION_SIGNON_INCOMPL - Cause: The attempt to log on in the form of an internal call to a target system is not valid.
Runtime Error: CALL_FUNCTION_SIGNON_INTRUDER - Cause: RFC from an external program without a valid user ID.
Runtime Error: CALL_FUNCTION_SIGNON_INVALID - Cause: The user tried to log onto the target system without a valid user ID.
Runtime Error: CALL_FUNCTION_SIGNON_REJECTED
The error code signifies the following:
1) Incorrect password or invalid user ID
2) User locked
3) Too many logon attempts
5) Error in authorization buffer (internal error)
6) No external user check
7) Invalid user type
8) User’s validity interval has been exceeded - Cause: No authorization for logon as a t rusted system .
Runtime Error: CALL_FUNCTION_SINGLE_LOGIN_REJ
The error code signifies the following:
0) Incorrect logon data with a valid security key.
1) Either the calling system is not a trusted t rusted system , or the security key is invalid.
2) Either the user has no RFC authorization (authorization object S_RFCACL ) or else someone tried to log on using a protected user, ‘DDIC’ or ‘SAP*’ .
3) The timestamp for the logon data is invalid. - Cause: An RFC without a valid user ID is only allowed for a system function module. The meaning of the error code is the same as for CALL_FUNCTION_SINGLE_LOGIN_REJ .
Runtime Error: CALL_FUNCTION_SYSCALL_ONLY - Cause: Data error (internal table info) when calling a function remotely
Runtime Error: CALL_FUNCTION_TABINFO
- Cause: No memory available for the table to be imported
Runtime Error: CALL_FUNCTION_TABLE_NO_MEMORY
Cause: Only applies to asynchronous RFC: Task name is already being used
Runtime Error: CALL_FUNCTION_TASK_IN_USE
Cause: Only applies to asynchronous RFC: The specified task is already open
Runtime Error: CALL_FUNCTION_TASK_YET_OPEN
- Cause: No trusted authorization for the RFC call and trusted system
Runtime Error: CALL_RPERF_SLOGIN_AUTH_ERROR - Cause: No valid trusted entry for the calling system
Runtime Error: CALL_RPERF_SLOGIN_READ_ERROR - Cause: No RFC authorization for the user
Runtime Error: RFC_NO_AUTHORITY