Remote enabled function modules (RFCs) can be a bit weird

Way back when, I worked on the case of the mysteriously filled parameters. Eventually I caught the culprit – when you call an RFC FM that has optional parameters, and you don’t fill those parameters, the RFC engine fills them anyway with default values.

Which means “IS SUPPLIED” doesn’t work!

But now I’ve got the opposite. I’m sending information, but only the first character is making it across.

This is highly suspicious. Is he assassinating the other characters? Is this a case of the first character across being very shady, and slicing the ropes on the string bridge once she’s on solid ground? Or is he just an innocent player in the whole game.

( Why do I get the feeling that this would be a more convincing dime detective novel style, if Paul Hardy  was writing it? Nonetheless, I’ll try to keep it going).

How to re-enact the crime scene

First take two systems. Thing1 and Thing2. This is on my mind at the moment, as when my lovely little granddaughter is in her one-piece pyjamas, she looks like Thing 1. Or possibly Thing 2.

On Thing1, create these RFC enabled function modules.

FUNCTION Z_MATT_TEST1.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"----------------------------------------------------------------------

ENDFUNCTION.

FUNCTION Z_MATT_TEST2.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     VALUE(I_REASON) TYPE  STRING
*"----------------------------------------------------------------------


ENDFUNCTION.

On Thing2, create these RFC enabled function modules

FUNCTION Z_MATT_TEST1.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"----------------------------------------------------------------------

ENDFUNCTION.

FUNCTION Z_MATT_TEST2.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     VALUE(I_REASON) TYPE  STRING
*"----------------------------------------------------------------------


  DATA x.
  WHILE x IS INITIAL.
  ENDWHILE.

ENDFUNCTION.

Create an RFC destination on Thing1 with a service user id created on Thing2. Call it CAT.

On Thing1, write this program:

REPORT ymabitest2.


CALL FUNCTION 'Z_MATT_TEST1'
  DESTINATION 'CAT'.

CALL FUNCTION 'Z_MATT_TEST2'
  DESTINATION 'CAT'
  EXPORTING
    i_reason = 'There are no reasons. Rock and Roll.'.

(You don’t have to use the object names I use, but if you do, I’m flattered).

Run this program, then shuffle across to SM50 on Thing2, select the session and debug!

The horrifying consequences

If you have the stomach for it, look at the value of i_reason.

You’ll see it contains only T.

Well, just big T.

Just when you thought it was already weird

Things get stranger. Comment out the first FM call and try again.

This time, you’ll see i_reason contains the full text!

Then it dawned on me

If I supply i_reason with a string literal or variable, it’s a million to one chance, but it just might work. (As any fan of Terry Pratchett knows, million to one chances crop up nine times out of ten. There’s actually a sound mathematical basis for this…)

And it does.

So there we are. All resolved. If you’re using a FM via RFC, make sure that any string parameters are supplied with a string. Not a character type.

But it still doesn’t explain why I only see this when I call both Functional Modules.

Edit: Super-sleuth Ulrich figured it out: https://answers.sap.com/questions/13809138/rfc-call-parameter-value-truncated.html