Remote RFC Call conversion error <***INVALID***>

[casualCoder]

Hi, 

some of our custom remote called Function Modules are receiving corrupt data when executed.

The passed Parameters to the Function Module are created dynamically from the expected Types of the calling System, so there should be no Problem in diffferent types or lengths. 

How to reproduce:
When the Program jumps into the called System, '#' is simply inserted in some of the formerly empty fields, which shifts the whole passed Structure and then <***INVALID***> appears on other Fields.

Environnement:

The calling System is a Unicode SRM System. Caller System is a S4 System. Codepage in SRM is 4102, enforcing this Codepage in SM59 did not resolve the issue.

What Structures are called

• ITEM: BBP_PDS_SC_ITEM_ICU

Faulty Data Elements in above named Structure:

•  DUMMY_EEW_PDISS_SC (Type = 'DUMMY')

SM59 Connection:

The called System uses Codepage 4102, but enforcing this Codepage didn't work.

DATA: c_on TYPE abap_bool VALUE abap_true,
      l_changed TYPE abap_bool.
      DATA: l_it_partner TYPE STANDARD TABLE OF zmm_bbp_pds_partner .

DATA: srm_dest TYPE rfcdest VALUE 'EBE100'.
FIELD-SYMBOLS: <item> TYPE TABLE,
               <header>.

DATA(lo_items) = zcl_srqltype=>new( destination = srm_dest typekind = zif_srqltypekind=>table_type typename = 'BBP_PDS_SC_ITEM_ICU' )->get_data(  ).
DATA(lo_srm_header) = zcl_srqltype=>new( destination = srm_dest typekind = zif_srqltypekind=>structure typename = 'BBP_PDS_SC_HEADER_U' )->get_data( ).

ASSIGN lo_items->* TO <item>.
ASSIGN lo_srm_header->* TO <header>.

<item> = VALUE #( (  ) ).
CALL FUNCTION 'ZDSC_BBP_PD_SC_UPDATE' DESTINATION srm_dest
        EXPORTING
          i_header                = <header>
          i_save                  = c_on
          i_without_header_totals = c_on
          i_attach_with_doc       = c_on
          i_with_item_data        = c_on
        IMPORTING
          e_changed               = l_changed
        TABLES
          i_item                  = <item>
          i_partner               = l_it_partner
        EXCEPTIONS
          system_failure          = 4
          communication_failure   = 8
          OTHERS                  = 16.

[Sandra_Rossi]

Just to clarify, you call in this direction, S/4HANA (4103 i.e. bytes of space are 2000) ---> SRM (4102 i.e. bytes of space are 0020), right? Did you check the SAP notes? Also, see this answer by @Ulrich_Schmidt which may help: https://community.sap.com/t5/application-development-discussions/rfc-call-parameter-value-truncated/...

[Ulrich_Schmidt]

> The passed Parameters to the Function Module are created dynamically from the expected
> Types of the calling System, so there should be no Problem in diffferent types or lengths.

There must be something wrong with the algorithm that "dynamically" creates the parameters. It definitely looks like the lengths & offsets of different fields of the BBP_PDS_SC_ITEM_ICU structure do not match in the sending and receiving system.

The last four bits of a P(8) field are either 0xC (a plus sign) or a 0xD (a minus sign), but in your case the binary representation of the P(8) field looks like this, with the C being somewhere in the middle of it:

00000000000C2000

My guess: in the raw data on sending side, two alignment bytes are missing, which then shifts the field-borders of all remaining fields by two. (So the first two bytes of the P(8) field end up in the previous field, and the last two bytes of the P(8) field are taken from the following field. (Which contain a space in little-endian order (2000), that has not been shuffled around to big-endian order (0020), because the system "thinks" its part of a P(8) and not of a CHAR.))

I am not an ABAP expert, so I don't know, how field-symbols work technically, but perhaps the problem is here? When handing over the data to the RFC engine, the RFC engine does not know the correct internal alignment of the structure fields (due to it being handed over via field-symbol) and therefore it sends the data in an incorrect RFC format.

You could verify this theory by running two different calls with RFC trace turned on, and then comparing the binary data in the RFC network stream (include some "eye-catchers" in the ICC_IN_TXJCD field, so you can easily identify start- and end-offset of that field!)

• Once call an FM, that has this structure/table defined in its interface, using SE37
• And once call the same FM in your dynamic way via field-symbols

In any case, this is not a codepage problem. Codepage problems only affect CHAR fields, but not binary fields like a packed number.