cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

CALL_FUNCTION_REMOTE_ERROR - Error in HTTP receive in query more method

0 Likes
1,070

Hello Experts,

I have a custom program which is calling RFC using dynamic Function module. When the program is getting executed in foreground or background, program is terminated resulting to dump.

"Error in HTTP receive in query more method"

Full Error is attached herewith.

Looking forward towards reply. Thanks in advance!

http-error-updated.txt

Accepted Solutions (0)

Answers (1)

Answers (1)

Ulrich_Schmidt1
Product and Topic Expert
Product and Topic Expert

It looks like your program (ZHR_RC_STI_FY20) is calling function module Z_EXTRACT_STI in "parallel RFC" in a second work process on the same appserver (10.66.34.66). This function module is apparently performing some HTTP communication and is running into a problem while receiving the response from the HTTP server. The function module is then trying to report an error message back to your program, but your program is not catching any exceptions! That's why it dumps...

So there are actually two problems that need to be looked at:

1. Program ZHR_RC_STI_FY20 needs to be fixed to catch any exceptions that may occur in the function module and exit gracefully with proper error handling, instead of just dumping.

The mistake is in form F_CALL_BACK:

| 1684|FORM f_call_back  USING gv_taskname.
| 1685|
| 1686| DATA: lv_total(10) TYPE c.
| 1687| DATA: lt_result_table TYPE STANDARD TABLE OF ZHR_STI_RESULT.
| 1688| gv_recieve_jobs = gv_recieve_jobs + 1 .
| 1689| gv_jobs = gv_send_jobs - gv_recieve_jobs.
| 1690|
| 1691| FREE lt_result_table.
| 1692| CLEAR lv_total.
| 1693|
|>>>>>| RECEIVE RESULTS FROM FUNCTION 'Z_EXTRACT_STI'
| 1695| TABLES
| 1696| ex_result_table = lt_result_table.
| 1697| CASE sy-subrc.
| 1698| WHEN 0.
| 1699| APPEND LINES OF lt_result_table TO result_table.
| 1700| gv_pp_running = gv_pp_running - 1.
| 1701| WHEN OTHERS.
| 1702|
| 1703| ENDCASE.
| 1704|
| 1705|ENDFORM.

As we can see, the RECEIVE command does not have an EXCEPTIONS clause! (But then it is checking sy-subrc, which doesn't make any sense...?!) To fix this, you need to fix the following exceptions:

  • all exceptions that Z_EXTRACT_STI might throw.
    (Check this function module in SE37 to see, what exceptions it defines.)
  • COMMUNICATION_FAILURE
    (This is thrown when the network connection between the work process, where your main program is running, and the work process where Z_EXTRACT_STI is running, breaks down.)
  • SYSTEM_FAILURE
    (This is thrown, when the work process on the other side aborts/dumps)

So let's assume for simplicity that Z_EXTRACT_STI throws one exception named HTTP_ERROR. Then form Z_CALL_BACK would have to be fixed like this:

FORM f_call_back  USING gv_taskname.

DATA: lv_total(10) TYPE c.
DATA: lt_result_table TYPE STANDARD TABLE OF ZHR_STI_RESULT.
DATA: error_message(128) TYPE c.
gv_recieve_jobs = gv_recieve_jobs + 1 .
gv_jobs = gv_send_jobs - gv_recieve_jobs.

FREE lt_result_table.
CLEAR lv_total.
RECEIVE RESULTS FROM FUNCTION 'Z_EXTRACT_STI'
TABLES
ex_result_table = lt_result_table.
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE error_message
SYSTEM_FAILURE = 2 MESSAGE error_message
HTTP_ERROR = 3
OTHERS = 4.
CASE sy-subrc.
WHEN 0.
APPEND LINES OF lt_result_table TO result_table.
gv_pp_running = gv_pp_running - 1.
WHEN 1.
* Network communication to parallel work process failed.
* Exact error message from operating system is given in variable error_message.
WHEN 2.
* Work process on the other side dumped.
* The error message from the dump is given in variable error_message.
WHEN 3.
* HTTP communication to external system failed.
WHEN OTHERS.
* Now it's time to panic...
ENDCASE.

ENDFORM.


The point where your program executes CALL FUNCTION 'Z_EXTRACT_STI' is unfortunately not shown in the attached document, but I presume that this code also needs a little fix: make sure that in this CALL FUNCTION statement you catch the RESOURCE_FAILURE exception. This exception is thrown, when there is currently no free work process to perform the execution of the parallel RFC. (See also the ABAP documentation of CALL FUNCTION and RECEIVE RESULTS for more information on how to correctly and robustly use parallel RFC.)

2. All the above prevents your program from dumping, when anything in the remote FM goes wrong, but it doesn't tell us, what went wrong in Z_EXTRACT_STI in the first place... About this we don't have much information. Only the short error message that was reported back from Z_EXTRACT_STI to your main program (and which caused your program to dump...):
"Error in HTTP receive in query more method"

In order to find out, what that means, you will have to investigate Z_EXTRACT_STI, check what exactly it does and what might fail there...