Personas - webRFC - Special characters

[henrik_mortensen2]

Hey,

Anyone got experience how to handle a situation where using special characters like "ÆØÅøæåÜÖ" when using a webRFC call from Personas.

If the JSON string returned from the webRFC having 1 or more of those special characters, the call is failing in personas.

I tried to URL encode the values returned in the JSON string. This worked well, however the result inserted into a field in personas will show the URL encoding.

At the moment it shows like this:

JSON string (only a part of it) : {"key": "address", "value": "Dampf%C3%A6rgevej+17,2100"}

When pasting the result into a field in personas it shows like this:

"Dampf%C3%A6rgevej+17,2100"

Wanted result:

"Damfærgevej+17,2100"

Is it possible to have the webrfc to deliver these special characters ?

Regards

Henrik

[tamas_hoznek · Accepted solution]

You'll have to use JSON encoding for the special characters.

Take a look at this: ABAP Keyword Documentation and look for the Rules for JSON section.

In your particular scenario, the string you need to return is "Dampf\u00E6rgevej+17,2100"

[henrik_mortensen2 · Accepted solution]

Ok I now tried out to convert the value as JSON, without any luck:

In the webRFC I'm using this for escape coding the value string:

value = 'Dampfærgevej+17,2100'

result = escape( val = value format = cl_abap_format=>E_JSON_STRING  ).

after execution:

Result = 'Dampfærgevej+17,2100'.

and I still get the script error in personas, when calling the webRFC.

I checked the demo program in SAP, called DEMO_ESCAPE. and it's seems the converted value of 'æ' are soposed  to result with 'æ'

any other suggestions ?

[tamas_hoznek · Accepted solution]

The result string that your WebRFC must return is as I posted above. Your result is exactly the same as it was before (no change) so of course it will fail.

You have to incorporate logic in your WebRFC based on the DEMO_ESCAPE program which encodes any special characters. The proper encoding for æ is \u00E6 - I tested this to work fine with a WebRFC so I know it is correct.

Edit: Upon further investigation, it appears that the escape function doesn't work for JSON like the documentation would imply. So here is some quick Mickey Mouse code to perform the encoding. Never mind the not exactly sophisticated exception handling; hopefully this won't be necessary anyway.

The problematic characters for WebRFC seem to be the ones whose ASCII code is below 32 and above 126. Those have to be encoded, the ones between 32 and 126 can be passed on as they are.

txt_in is the original text, result is the encoded string to be returned by the WebRFC.

DATA: txt_in    TYPE        string VALUE 'Dampfærgevej+17,2100',
      chr       TYPE        char1,
      strlength TYPE        i,
      offset    TYPE        i,
      icode     TYPE        i,
      hcode     TYPE        syhex02,
      ccode     TYPE        char4,
      result    TYPE        string,
      gr_error  TYPE REF TO cx_root.

strlength = strlen( txt_in ).

DO strlength TIMES.

  offset = sy-index - 1.
  chr = substring( val = txt_in off = offset len = 1 ).

  TRY.
      icode = cl_abap_conv_out_ce=>uccpi( chr ).
    CATCH cx_root INTO gr_error.
      icode = 32.
  ENDTRY.

  IF icode < 32 OR icode > 126.
    ccode = hcode = icode.
    CONCATENATE result '\u' ccode INTO result.
  ELSE.
    CONCATENATE result chr INTO result.
  ENDIF.

ENDDO.

WRITE / result.

Message was edited by: Tamas Hoznek

Added ABAP code snippet

[Former Member · Accepted solution]

Hello Tamas,

thank you. I was just facing the same problem. Your code snippet helped me out.

Just one thing:

To avoid blanks getting lost in translation please add a RESPECTING BLANKS:

CONCATENATE result chr INTO result RESPECTING BLANKS.

Thank you again.

Regards

Björn

[henrik_mortensen2 · Accepted solution]

Hey Björn,

I tried the RESPECTING BLANKS, however it's not working for me here. I just end up with a complete blank output.

[Former Member · Accepted solution]

Hey Henrik,

is the output of the WebRFC really blank? RESPECTING BLANKS works fine for me.

Do you use a table with structure W3HTML as mentioned in ? Perhaps the escaped JSON string is longer than 255 characters (one row in the table)?

Regards

Björn

[henrik_mortensen2 · Accepted solution]

Hey Björn,

no not all the JSON string is blank. Only the value(part of JSON string) I convert getting blank if I'm using RESPECTING BLANKS.

I put in the code snippet into a FM, However I'm using field symbols, and it seems I'm having some issues due to that.

So it might work out for you in the way your are using it

[Former Member · Accepted solution]

Hey Henrik,

I build my JSON string using CONCATENATE like described in After the whole string is build and saved into a variable, for example lv_json_string,

the code snippet runs with

txt_in = lv_json_string.

I'm using the snippet without any changes to the variables.

I hope this helps.

Regards

Björn

[tamas_hoznek]

Thank you both for the feedback and the suggestion regarding the wrong handling of blanks.

In the meantime I figured the code can be made simpler to avoid some unnecessary type conversions, so the corrected code looks like this:

DATA: txt_in    TYPE        string VALUE 'Dampfærgevej+17,2100 ABÉÁCÖŐ',
      chr       TYPE        char1,
      strlength TYPE        i,
      offset    TYPE        i,
      hcode     TYPE        syhex02,
      ccode     TYPE        char4,
      result    TYPE        string,
      gr_error  TYPE REF TO cx_root.

strlength = strlen( txt_in ).

DO strlength TIMES.

  offset = sy-index - 1.
  chr = substring( val = txt_in off = offset len = 1 ).

  TRY.
      hcode = cl_abap_conv_out_ce=>uccp( chr ).
    CATCH cx_root INTO gr_error.
      hcode = '0020'.
  ENDTRY.

  IF hcode < '0020' OR hcode > '007E'.
    ccode = hcode.
    CONCATENATE result '\u' ccode INTO result.
  ELSE.
    CONCATENATE result chr INTO result RESPECTING BLANKS.
  ENDIF.

ENDDO.

WRITE / result.

[Former Member]

Works perfect for us!

Thanks again, Tamas!

Regards,

Gabriela

[henrik_mortensen2]

Hey Tamas,

Thanks a bunch this really did the trick, however as Björn as well figured out, some minor issues with blanks.