sy-subrc 4 via RFC FM on simple select statement even though it tests successful

[antonette_oberholster]

Hi guys

I'm fairly new to abap and created a simple FM that should return a flag based on a value in a table.

When I test the FM in se37 it works perfectly and returns the flag, but as soon as I call it from the other system (gateway), the select returns sy-subrc 4. Any ideas why?

RFC FM code:

FUNCTION z_rfc_check_equi_warranty.

*"----------------------------------------------------------------------

*"*"Local Interface:

*"  IMPORTING

*"     VALUE(EQUI_NR) TYPE  EQUNR

*"  EXPORTING

*"     VALUE(WAR_VALID_FLAG) TYPE  FLAG

*"----------------------------------------------------------------------

  "TABLES: equi, bgmkobj.

  DATA: lv_equnr_obj TYPE j_objnr.

  DATA: ls_equi TYPE equi.

  DATA: ls_war TYPE bgmkobj.

  SELECT single * FROM equi WHERE equnr = @equi_nr  INTO @ls_equi.

    IF sy-subrc = 0. "<= Returns 4 when I call it via RFC and debug, equi_nr is passed correctly. WHY????

      SELECT SINGLE * FROM bgmkobj WHERE j_objnr = @ls_equi-objnr AND gaart = '1' INTO @ls_war.

      IF sy-subrc = 0.

        IF ls_war-gwlen > sy-datum.

          war_valid_flag = 'X'.

        ENDIF.

      ENDIF.

    ENDIF.

ENDFUNCTION.

Thanks

Antonette

[srikanthnalluri]

equi_nr will be in string format when you call FM, so it has to be converted using conversion alpha.

[fmunozb]

Hello,

You could use Exceptions, in followig link https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/abenrfc_exceptions_abexa.htm . You will find explain form this concept and examples.
Nevertheless, SAP indicate this is obsolete technic, for new developments, SAP recommends working with class-based exceptions that are independent of the function module.
In the next link you find about this.
https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/abenfunction.htm.

Regards.

[matt]

The problem is why within the code of the FM, sy-subrc is 4, when the same code with the same equipment number run non-RFC has sy-subrc 0.

[Former Member]

Hello Antonette,

one idea about this:

How does the test of the RFC call work in your scenario? If you call a remote function module, this is routed via an RFC connection. The RFC logs into another system with a set interface user, which is defined in the RFC settings (SM59). It is important that this interface user has sufficient authorizations. If the user is not authorized to select on specified tables on a remote system, this may lead to the SY-SUBRC = 4. You should check the roles of the RFC user in SU01 and then check if these roles allow table display operations (S_TABU_DIS) in the way it is needed for your scenario.

Maybe this solves your problem.

Best regards

Markus

[matt]

Unless things have changed dramatically in 7.5 onwards, I don't believe that S_TABU_DIS is even considered when doing a straight SELECT from a table.

[matt]

What exactly is the value of equi_nr as seen in the debugger when you run

1. Via SE37
2. Via the RFC

I can see only two possibilities. First: that equi_nr is a different value in 1. and 2. As S N suggested. Second: the system you're doing the SE37 on in 1, and the RFC destination you're using in 2 are not the same.

[DoanManhQuynh]

equipment number have convert routine so you may have to check your non-sap system if it sent correct value (leading zero for example).

try below function module to check the correct value:

CONVERSION_EXIT_ALPHA_INPUT
CONVERSION_EXIT_ALPHA_OUTPUT

[antonette_oberholster]

Thanks! It works! 🙂

[antonette_oberholster]

Thank you @matthew.billingham !

When I compared the 2 values from the different debugging sessions I realized the value passed for equi_nr via RFC did not have any leading zeros 🙂 so alpha conversion did the trick. wouldn't have picked that up if you hadn't told me to look closely at the values.

Antonette