ABAP Dump due to RFC Function module call in another thread

[Former Member]

Hi,

I am facing some problem since yesterday. In one of my executable program I am calling a RFC fm as below mentioned

REPORT ZREPORT.

CALL FUNCTION 'Z_XXXXXXXXX'

STARTING NEW TASK L_NAME

DESTINATION IN GROUP 'TASK'

PERFORMING RETURN_INFO ON END OF TASK

EXPORTING

P_exp1 = l_emp

TABLES

R_VBELN = r_it_vbeln

EXCEPTIONS

NO_DATA_TO_PROCESS = 1

OTHERS = 2.

wait until v_task = 1.

update ztable.

Due to some data inconsistence one of the SAP function

module which I am calling in my function module Z_XXXXXXXXX

is generating dump with message type X. Since there is data inconsistence it is generating dump that's OK.

But the problem i am getting is, report ZREPORT is generating dump at WAIT statement saying illegal statement even though I am calling that function module

Z_XXXXXXXXX as a separate new task.

Can somebody help me.

Thanks,

Amara.

[RichHeilman]

What is the system exception? Can it be caught using TRY...ENTRY or CATCH...ENDCATCH?

Check the dump. The exception will be at the top of the abap dump. Then do F1 help on CATCH, in the help there should be a link to system exceptions. Check to see if your exception can be caught.

REgards,

Rich Heilman

[Former Member]

hi, Amara

I agree with Rich said, and do a simulate test in my server, here is the analysis.

Assume we have a RFC, like this:

FUNCTION ZGZL_DUMPTEST.
*"----------------------------------------------------------------------
*"*"Local interface:
*"  EXPORTING
*"     VALUE(OUT) TYPE  I
*"  EXCEPTIONS
*"      CONVERT_FAIL
*"----------------------------------------------------------------------

  data:a  type  i.
  a = 'A'.

ENDFUNCTION.

And call this RFC like you way:

REPORT ZGZL_DUMPTEST .
DATA:
  SEMAPHORE(1) VALUE SPACE,
  LC_OUT       TYPE  I.

CALL FUNCTION 'ZGZL_DUMPTEST'
STARTING NEW TASK 'DUMP'
PERFORMING RETURN_INFO ON END OF TASK.

WAIT UNTIL SEMAPHORE = 'X'.
WRITE: 'OVER'.

FORM RETURN_INFO USING TASKNAME.
  RECEIVE RESULTS FROM FUNCTION 'ZGZL_DUMPTEST'
          IMPORTING  OUT = LC_OUT.

  SEMAPHORE = 'X'.
ENDFORM.                    " RETURN_INFO

if we run the RFC in se37 directly, obviously it will occur a rumtime error CONVT_NO_NUMBER, and dump.

But if we run the above application to call the RFC, we will get a different runtime error CALL_FUNCTION_REMOTE_ERROR.

Error Analysis in ST22 like this:

An error occurred when executing a REMOTE FUNCTION CALL.

It was logged under the name "CONVT_NO_NUMBER"

on the called page.

I think that means the application receive the runtime error from RFC when call <b>RECEIVE RESULTS</b>.

In normal CALL FUNCTION, the external application will accept the rumetime error throw from FM, that's correct, because it let the caller can handle these runtime errors.

In you case, you said RFC run in a new task, yes, that's true, so you can call the RFC like this:

CALL FUNCTION 'ZGZL_DUMPTEST'
STARTING NEW TASK 'DUMP'
PERFORMING RETURN_INFO ON END OF TASK.

WAIT UNTIL SEMAPHORE = 'X'.
WRITE: 'OVER'.

FORM RETURN_INFO USING TASKNAME.
  SEMAPHORE = 'X'.
ENDFORM.                    " RETURN_INFO

It will goes well, no dump. Why? because we don't use RECEIVE RESULT. RECEIVE RESULT will bring the result from FM, also bring the runtime error from FM.

So if you want to call the FM and receive the result, handle the runtime error in FM inside at first.

like this:

  
  CATCH SYSTEM-EXCEPTIONS CONVT_NO_NUMBER = 1.
    a = 'A'.
  ENDCATCH.
  IF SY-SUBRC = 1.
    RAISE CONVERT_FAIL.
  ENDIF.

And then you call FM like this:

CALL FUNCTION 'ZGZL_DUMPTEST'
STARTING NEW TASK 'DUMP'
PERFORMING RETURN_INFO ON END OF TASK.

WAIT UNTIL SEMAPHORE = 'X'.
WRITE: 'OVER'.


FORM RETURN_INFO USING TASKNAME.
  RECEIVE RESULTS FROM FUNCTION 'ZGZL_DUMPTEST'
          IMPORTING  OUT = LC_OUT
          EXCEPTIONS CONVERT_FAIL = 1.

  SEMAPHORE = 'X'.
ENDFORM.                    " RETURN_INFO

That's will be ok for your scenario.

Hope my reply is useful.

thanks

[Former Member]

Hi zhenglin gu,

Thanks for your time.I though the EXCEPTIONS keyword in call function statement should take what you have suggested. Anyway I will tomorrow as you suggested.

Thanks,

Amara.