An issue caused by implicit conversion during RFC call

[JerryWang]

• Where does this magic number '3473457' come from


• Summary

Just would like to share with you how I struggle with a bug recently. These days I am supporting a customer project which would go live very soon. We find a severe performance problem in a scenario. After fighting it for sometime, we locate the possible cause into the FM call below.

This is a RFC call from CRM to ERP system with expectation that at maximum 15 records are returned.

Much to our surprise, far more than 15 records are returned, finally leads to the performance issue.

Then I go to the responsible colleague for FM SLS_LORD_GET_VALUES_SAREA saying "Hey man, there is something wrong with the max entry filtering logic in your FM. Customer will go live soon and could you please help as soon as possible". My colleague soon replied to me "just checked from my side, this FM works pretty good".

Then I have to look into this issue once again. When debugging inside this FM, I found the importing parameter is not 15, but becomes a big number 3473457, so the max record filter logic absolutely does not work in such case.

I checked the signature of this FM, and found out we should pass into it with a integer, not a char ( '15' in this example ) .

Where does this magic number '3473457' come from

I write a small report to explore it. I deliberately pass char value ( from 1 to 15 ) to an importing parameter with INT type.

DATA: lv_num_c TYPE char2.



START-OF-SELECTION.

DO 15 TIMES.

 lv_num_c = sy-index.

 TRY.

    CALL FUNCTION 'ZTEST'

      EXPORTING

        iv_in_rfc = abap_false

        iv_num = lv_num_c.

 CATCH cx_root INTO DATA(cx_root).

     WRITE: / cx_root->get_text( ).

     EXIT.

 ENDTRY.

ENDDO.



DO 15 TIMES.

  lv_num_c = sy-index.

  CALL FUNCTION 'ZTEST' DESTINATION 'NONE'

    EXPORTING

      iv_in_rfc = abap_true

      iv_num = lv_num_c.

ENDDO.

The FM ZTEST just insert what has passed in to a DB table:

FUNCTION ZTEST.

 ls_rfc-in_rfc = iv_in_rfc.

 ls_rfc-num = iv_num.

 INSERT zrfc_Test FROM ls_rfc.

ENDFUNCTION.​

Execute result:

The first normal FM call failed with exception:

The function call of ZTEST failed; a field may have been assigned to the parameter IV_NUM whose type is not compatible with this parameter

The second round RFC call does succeed, and check what has been written into the DB:

why we passed a '1' into the FM and it has been interpreted as 2097201??

in our report, we have passed '1' ( an variable with type CHAR2 ), whose Hex value is 31002000. And when it is passed into this remote-enabled FM, since the importing parameter is defined as INT in signature, the framework tries to interpret this Hex value back to an Integer, which is 2097201, since this Integer has the very Hex value 31002000.

This operation could simply be simulated to the lines below:

Summary

In normal function call, the ABAP runtime environment could help us identify some misuse on FM call, for example the non-compatible parameter type just as the first example in this blog. However when dealing with remote function call, such misuse would not lead to runtime exception, the application could keep running but not in accordance with what we expect, and sometimes it is difficult to identify in which step the deviation occurs. So we must strictly adhere to the development guideline to avoid such implicit conversion.