Characters getting lost while calling a remote function

[Former Member]

Hi there,

I've got a problem concerning a remote function call.

Situation: System A has a function module ZFM_X with one importing parameter ("text" type string).

System B calls this function module ZFM_X through a remote function call.

It passes a string (containing 521 characters) variable to the importing parameter "text".

Unfortunately, only fragments of the imported text arrive in System A.

The text arriving in System A has the following pattern: The first 256 are correct, following 256 white spaces(blanks) following the last 9 characters of the imported text.

Example:

This is sent by System B to System A through a String variable.

http://xxx.xx.xx.xx:xxxx/servlet/ContentServer?get&pVersion=0046&contRep=PG&docId=4BB4C36F5A0200B9E1008000AC101219&accessMode=r&authId=CN%3DP60&expiration=20100420112054&secKey=MIH3BgkqhkiG9w0BBwKggekwgeYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHATGBxjCBwwIBATAZMA4xDDAKBgNVBAMTA1A2MAIHIAgIKARFNDAJBgUrDgMCGgUAoF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwNDIwMDkyMDU0WjAjBgkqhkiG9w0BCQQxFgQUItgHQiYkW9BkScWnoMPkZiuCGSMwCQYHKoZIzjgEAwQuMCwCFGPGseHQSPV2%2F75OVMF2yMFzwfTLAhQgPRMvivyuii4gZ%2BJSKonPRsF1XA%3D%3D

At System A the following text arrives

http://xxx.xx.xx.xx:xxxx/servlet/ContentServer?get&pVersion=0046&contRep=PG&docId=4BB4C36F5A0200B9E1008000AC101219&accessMode=r&authId=CN%3DP60&expiration=20100420112054&secKey=MIH3BgkqhkiG9w0BBwKggekwgeYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHATGBxjCBwwIBATA                                                                                1XA%3D%3D

It definitely looks like a unicode problem. Oddly, we have another system constellation which is exactly the same as System A/B where we are doing this, and its working perfectly fine.

I hope you are not stunned by this wall of text, but any help is totally appreciated!

Edited by: Erik Nagler on Apr 20, 2010 11:54 AM

[Former Member]

I faced a same kind of problem in a custom RFC. At the destination, the text was getting modified.

In the RFC, the some parameters in EXPORT/IMPORT were defined as string. I changed it to character 255 and the problem was resolved.

You can try the same.

But I'm still looking for the reason behind that...........

[Former Member]

Thanks for your reply, but I need more than 255 characters.

It must be possible to transfer more than 255 characters in one variable through a RFC. Either the IMPORT/EXPORT Variable as a String or as a CHAR1024 for instance.

[Former Member]

Hi,

I'm not sure if this will work. But just a suggestion.

Please try checking the check box for 'Pass Value' against the importing parameter 'text'

[Former Member]

Hey,

the option "pass value" ist activated.

Parameters in an RFC enabled function module must always be enabled for "pass value". Its mandatory.

[Former Member]

Hi Erik,

you mentioned a successful running szenario with two other servers A/B.

Did you check the configuration of your rfc connection and compared especially the unicode configuration with this szenario?

And btw: a local call of your fm works?

Best regards,

CW

[Former Member]

Hi Cornelia,

the RFC destinations (Type 3 in SM59) in both scenarios are identical as far as the unicode settings are concerned.

A local call of the function module works as well.

[Former Member]

I think the problem will be resolved if a character type is used. You can create one data element as per your length requirement and use the same.

Otherwise, check the unicode tab in SM59. Perform unicode test and if the target system is unicode compliant select unicode radiobutton.

[Former Member]

Hi,

I tried it with String type and Character type (CHAR1024).

Both dont work.

As far as the unicode test is concerned:

Sysem A is a unicode System whereas System B is a non-unicode system.

I tried to change the Radiobutton to "unicode" in sm59, but I can't.

It is uneditable, even though I am in change mode.

[>>Picture<<|http://img90.imageshack.us/img90/2006/unicode.png]

[Former Member]

Hello!

As far as the Unicode problem is encountered, why don't you try to convert the transferring string into hexadecimal format inside the output FM and convert it backwards inside the input FM?

Best wishes, Eugene.