RFC BAPI_PBSRVAPS_GETDETAIL2 returning weird data

[jepi_flanders]

Hi Experts,

I'm on ECC6 using a remote function call towards APO with the BAPI in subject, to get details about the planning book.

The returned key_figure_value table is however containing weird data, like these:

The PERIOD_BEGIN is really weird (Chinese characters?), PERIOD_END is empty (while it should not), and VALUE is initial, while I should have values here;

Do you have any clue why this is happening?

Any help and suggestion is really appreciated;

Thanks and bye,

Jepi

P.S.: testing the FM in APO with the same parameters is returning correct results and figures

[Sandra_Rossi]

Mojibake - Wikipedia 😉

[Sandra_Rossi]

If it's standard, check the SAP notes or ask SAP Support.

[Ulrich_Schmidt · Accepted solution]

Most probably an alignment problem. This can be caused by

• Unicode/Non-Unicode mismatch:
  PERIOD_BEGIN and PERIOD_END are wo fields of type CHAR15. In a NUC-system, a CHAR15 field is 15 bytes long, while in a UC-system it is 30 bytes long.
  So if APO sends Non-Unicode data (15 bytes for PERIOD_BEGIN and 15 bytes for PERIOD_END), but ECC interprets it as Unicode data, it would fill these 15+15 bytes into the 30 bytes of the field PERIOD_BEGIN.
  This means that PERIOD_BEGIN looks like "Chinese", and PERIOD_END remains empty. (And then there is not enough total data present, so the final VALUE and FIXING_INFO fields are initialized with the default value: 0 for a FLOAT and space for a CHAR1.)
• The definition of the PBTIMESERIESITEM structure is different in APO and ECC:
  The screenshot seems to be from ECC, so the structure has 5 fields there:
  INT4, CHAR15, CHAR15, FLOAT, CHAR1
  If the structure has a different definition in APO, for example something like
  INT4, FLOAT, FLOAT, CHAR20
  then the data sent for these fields would of course end up as complete garbage in ECC...

From your screenshot it looks like the first possibility is the problem here. But I would say that with today's SAP systems, this is impossible!! The RFC protocol has a handshake built-in, where the two systems exchange their capabilities and traits (Codepage, Endianess, floating-point format, etc.), so both systems should know exactly what the other system is and can. So even if one system is Unicode and the other Non-Unicode, I would say that it is impossible, that such a mismatch can happen today! (I hope, you are not using a 25 year old 3.1I system and a 20 year old 4.6C system...? :-))

This means, if you have reasonably up-to-date systems on both sides, something must be going really really wrong here... BAPI_PBSRVAPS_GETDETAIL2 looks like a standard SAP BAPI, so I can only suggest what Sandra already recommended: open a SAP support ticket.

Ah, wait a moment, I think there is one possibility how such a mismatch can still be achieved: by forcing the RFC layer to use the wrong settings. Go to SM59 and check the definition of the RFC destination that you use in your CALL FUNCTION statement. Could it be, that you have set this destination to "Unicode", but the APO systems is in fact a Non-Unicode system? That would explain it!

[jepi_flanders · Accepted solution]

Thanks Ulrich for the hint!

indeed, I must have been accurate in the data definition for the PERIOD_% fields, now the result in ECC looks great:

thanks again and bye

[Ulrich_Schmidt · Accepted solution]

Ah yes, a Packed Number of size 8 is indeed quite different from a CHAR15 field... So what happened here is roughly: The INT4 field was transferred & recognized correctly, but the remaining 4 fields in APO (P(8), P(8), FLOAT, CHAR1) had 8+8+8+2 = 26 bytes, and these bytes were all filled into the 30 bytes of the CHAR15 field -- resulting in garbage in that CHAR15 and leaving the remaining three fields (CHAR15, FLOAT, CHAR1) empty/initial...