Escape special characters for OData response

[former_member183924]

Hi all,

I'm facing a problem on HTTP response when some special characters are in my entity fields.

For example I've got a Edm.String field which has characters like ###, ", < (two number signs ## are ok, but three invoke an error)

When I set output format to xml via URI parameter $format=xml, I get following error:

<message xml:lang="en">In the context of Data Services an unknown internal server error occured</message>

Exception /IWCOR/CX_DS_INTERNAL_ERROR in class /IWCOR/CL_DS_EP_WRITER_OUTPUT method /IWCOR/IF_DS_EP_WRITER_OUTPUT~WRITE and Line 39

If I use JSON as output format, HTTP response code is 200!!, but payload just ends on the character which cannot be interpreted:

(ABAP)-JSON generator can handle double quotes much better than XML format:

How can I escape these output strings, without adding chars which will appear in response payload?

Thanks,

Steffen

[UweFetzer_se38 · Accepted solution]

Hi Steffen,

I think the ### are just placeholders for binary data. Unfortunately the screenshot of the debugger doesn't show the right part, where we could see the real content.

[Former Member · Accepted solution]

Hi Steffen,

As Uwe pointed out, this is binary data and given the way it presents itself, it is probably not correct data. Rather than trying to look at how to escape this (bad?) data, shouldn't you be looking at the cause of the data being in this state on the server? It would seem that you should be getting  the string "bcoadm", so my guess is that the origin is corrupted or it is happening during some data transformation.

regards

Ron.

[former_member183924 · Accepted solution]

Hi Uwe & Ron,

thanks for your ideas, but maybe we're not talking about binary data?! This field is an example from TADIR table.

OData entity definition for this field:

Versid

Edm.String

0

0

20

ABAP field definition:

Data Type        CHAR  -  Character String

No. Characters       20

Decimal Places        0

Output Length        20

Convers. Routine    <empty>

Uwe did you mean another debugger view?

SE16 output for this line:

What if I want to store and receive data with these special chars like ####, ", <, >,... in a ABAP char field (respective OData Edm.String)?

Thanks,

Steffen

[UweFetzer_se38 · Accepted solution]

Hi Steffen,

as you can see in your debugger screenshot, the field VERSID not only contains "bcoadm" but was filled with x0000 (hex 0) at the end, not spaces (in our system, too).

You have to output this as binary data or get rid of this.

[Former Member · Accepted solution]

Steffen,

The binary content of the "string" which contains 'bcoadm' is not correct. In a normal SAP char field, the trailing part is not all null binary. It should be a repeated binary representation of 'space'.

The string does not actually contain '#' or any such characters, these are debugging placeholders to signify 'unexpected data'. Therefore the question about escaping them is moot, since they don't exist here

You should be seeing repeated pattern like '2000200020002000', not  '00000000000'.

Your data is corrupted before it gets to the entity.

Regards

Ron.

[former_member183924 · Accepted solution]

Hi Uwe,

alright just saw it shortly before I read your answer 🙂

Now it works fine.

Thanks,

Steffen

[former_member183924 · Accepted solution]

I just want to mention that there is another trap, if you have to use double quotes in the request URI (e.g. as a key parameter for one entity). Request URI: /sap/opu/odata/sap/zsf_test/Entity('Key"Value')

Response body want to give the request URI back, but then the XML cannot be generated.

You'll have to use URL encoding (HTML URL Encoding Reference) before sending the request.

/sap/opu/odata/sap/zsf_test/Entity('Key%22Value')

For JSON it works fine without URL encoding before the request:

{
"d":{
"results":[{
"__metadata":{
"uri":"https://server:port/sap/opu/odata/sap/zsf_test/('Key%22Value')","type":"zsf_test"},"property1":"value","property2":"Key\"Value"}

--

Steffen

[Former Member · Accepted solution]

Hi Steffen,

Yes that's true. As a lot of unit testing is done in the GW client or browser tools, we forget about escaping as 99% of the time non-escaped data works. In general, any "programmatic" consumer client should escape the request URI and the body (this is another possible fault when posting/putting from a browser test case, e.g. ampersand in a body text that is not escaped ).

The entity feeds from the OData parser are escaped as part of the process so it's not really necessary to have to escape anything on the application level.

Cheers

Ron.