Character translation error in Mapping Lookup API (RFC)

[Former Member]

Dear all,

I am new to XI and got a question concerning XI Mapping Lookup API - I send an RFC Request, which comes back as RFC Response(XML), that I fill in a String to map on.

My problem is, characters such as "Ä,ä,Ü,ß" and so on come back pretty weird and I also got a lot of quotes in my String. Could somebody please give me a hint how to move on with this..

thanx in advance

P.S. Is it usefull to handle this problem using the DOM Parser instead holding the response in a string?

Info: called system is R/3 4.6b, XI runs on 6.4 SR 16

[Former Member · Accepted solution]

Hi all,

my problem is not longer the escaping of the xml chars, such as "<", ">", "/", I solved that, using classes from Apache with the following code snippet
// ioutils is an class from org.apache.commons.io, that allows you to copy InputStream to StringWriter, setting charset as shown below:

Payload resultOfCall = accessor.call(payload);
InputStream in = resultOfCall.getContent();
ioutils.copy(in,stringWriterTemp,"ISO-8859-1");
content=stringWriterTemp.toString();

- the result String looks now like this:

<rfc:Z_GETFTXC108TXTFROMFILE2.Response xmlns:rfc="urn:sap-com:document:sap:rfc:functions"><SCENOEDITXTSTRUCT><br /><MANDT>030</MANDT><SCENARIOID>TVPN</SCENARIOID><br /><FILENAME>c: est est.txt</FILENAME><br /><FILETYPE>ASC</FILETYPE><br /><TEXT1>1 Ä | ä</TEXT1> (should be Ä | ä)<br /><TEXT2>2 Ö | ö</TEXT2> (should be Ö | ö)<br /><TEXT3>3 Ãœ | ü</TEXT3> (should be Ü | ü)<br /><TEXT4>4 ß</TEXT4> (should be ß)<br /><TEXT5>5 AAAAAA</TEXT5><br /></SCENOEDITXTSTRUCT></rfc:Z_GETFTXC108TXTFROMFILE2.Response>

@ Stefan

Because I plan to write the plain texts from 1,2,3,4,5

into global container and provide later, the structure

is fine - but how can I get the 'special characters'

correct? Doesn't look like they have been escaped,right?

Or are the char's above really encrypted characters for latin charset, that can be parsed and remodeled?

Thanx in advance

rainer

[stefan_grube · Accepted solution]

Now the characters are no longer escaped, that is right.

The point now is, the string contains UTF-8 double byte characters, but it is treated like latin-1. So you see two characters instead of one.

Try changing:

ioutils.copy(in,stringWriterTemp,"ISO-8859-1");

to

ioutils.copy(in,stringWriterTemp,"UTF-8");

Regards

Stefan

[Former Member · Accepted solution]

Hello Stefan !

many thanx for your help ! problem is solved now !

Cheers Rainer

[Former Member]

Hi all

We have had the same problem yesterday.

It seems that it is only a problem by calling an RFC with mapping lookup.

By using sync Message Interface it work.

We checked the apache packed and found out that it is not necessary to use this.

Define a new String for encoding parameter and use the normal InputStreamReader(in,NEWSTRING).

This works.

Sample:

String vEncodeUTF = "UTF-8";

....

// 5. Execute lookup.

Payload result = accessor.call(payload);

InputStream in = result.getContent();

try {

BufferedReader bufReader = new BufferedReader(new InputStreamReader(in,vEncodeUTF));

……

Cheers Daniel

[stefan_grube]

The RFC adapter escapes all non-ascii values with the code page value enlosed with the escaping sequence, for example: &#132;

I don't see another way as parsing the strings and deescpaping these values in your Java program.

Regards

Stefan

[Former Member]

Dear all - thanks for your very fast help but I still have problem with the wrong character...

@Michal - Using this coding (the easiest way, I found from the WebLog) to convert the Payload type to String, delivers the result I have shown at the end, so could you give me please some approach how to handle this

Payload resultOfCall = accessor.call(payload);

InputStream in = resultOfCall.getContent();

out = new ByteArrayOutputStream(1024);

byte[] buffer = new byte[1024];

for (int read = in.read(buffer); read > 0; read = in.read(buffer)) {

out.write(buffer, 0, read);

}

content = out.toString();

return content;

Result:

&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;&lt;rfc:Z_GETFTXC108TXTFROMFILE2.Response xmlns:rfc=&quot;urn:sap-com:document:sap:rfc:functions&quot;&gt;&lt;SCENOEDITXTSTRUCT&gt;&lt;MANDT&gt;030&lt;/MANDT&gt;&lt;SCENARIOID&gt;TVPN&lt;/SCENARIOID&gt;&lt;FILENAME&gt;/usr/sap/text3.txt&lt;/FILENAME&gt;&lt;FILETYPE&gt;ASC&lt;/FILETYPE&gt;&lt;TEXT1&gt;Kleines Regengesicht aaLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;Ã&#132;äÃ&#156;ü2 AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;Ã&#132;äÃ&#156;ü3 AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678906 AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;Ã&#132;äÃ&#156;ü3 AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;8 AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;Ã&#156;üÃ&#150;ö9 Ã&#132;äBbCcDdEeFfGgÃ&#150;öIxxSTRINGENDE&lt;/TEXT1&gt;&lt;TEXT2&gt;2 AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;Ã&#132;äÃ&#156;ü1234567890123456789012345678901234567890123456789012345678903 AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678902 AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;Ã&#132;äÃ&#156;ü7 Ã&#132;äBbCcDdEeFfGgHhIiJjKkLlMmNnÃ&#150;öPpQqRrSsTtÃ&#156;üVvWwXxYyZzÃ&#159;Ã&#159;Ã&#150;öÃ&#156;ü8 AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;Ã&#156;üÃ&#150;ö9 Ã&#132;äBbCcDdEeFfGgÃ&#150;öIxxSTRINGENDE&lt;/TEXT2&gt;&lt;TEXT3&gt;3 AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;Kleines Regengesicht aaLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;Ã&#132;äÃ&#156;ü3 AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678906 AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;Ã&#132;äÃ&#156;ü7 Ã&#132;äBbCcDdEeFfGgHhIiJjKkLlMmNnÃ&#150;öPpQqRrSsTtÃ&#156;üVvWwXxYyZzÃ&#159;Ã&#159;Ã&#150;öÃ&#156;ü8 AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;Ã&#156;üÃ&#150;ö9 Ã&#132;äBbCcDdEeFfGgÃ&#150;öIxxSTRINGENDE&lt;/TEXT3&gt;&lt;TEXT4&gt;7 Ã&#132;äBbCcDdEeFfGgHhIiJjKkLlMmNnÃ&#150;öPpQqRrSsTtÃ&#156;üVvWwXxYyZzÃ&#159;Ã&#159;Ã&#150;öÃ&#156;ü7 Ã&#132;äBbCcDdEeFfGgHhIiJjKkLlMmNnÃ&#150;öPpQqRrSsTtÃ&#156;üVvWwXxYyZzÃ&#159;Ã&#159;Ã&#150;öÃ&#156;ü2 AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;Ã&#132;äÃ&#156;ü123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890Kleines Regengesicht aaLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;Ã&#132;äÃ&#156;ü1234567890123456789012345678901234567890123456789012345678908 AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzÃ&#159;Ã&#159;Ã&#156;üÃ&#150;ö9 Ã&#132;äBbCcDdEeFfGgÃ&#150;öIxxSTRINGENDE&lt;/TEXT4&gt;&lt;TEXT5&gt;&lt;/TEXT5&gt;&lt;/SCENOEDITXTSTRUCT&gt;&lt;/rfc:Z_GETFTXC108TXTFROMFILE2.Response&gt;

Thnaks in advance!

[bhavesh_kantilal]

Hi rainer,

The &lt; &gt; are the XML escape sequences of the < and the > symbols.

Also, can you just execute the RFC in SE37 with the same inout and check the output. I think the Output contains special charatcters and those special characters are what you see.

Regards,

Bhavesh

[MichalKrawczyk]

hi,

put the whole response (before parsing)

into a string and output it

do you see the ? there ?

if not than you'll know it's DOM issue

if you'll see the ? then you'll need to look into some

other things

Regards,

michal

[bhavesh_kantilal]

Hi,

<i>I send an RFC Request, which comes back as RFC Response(XML), that I fill in a String to map on.</i>

Just parse the RFC response message to extract the response out of the XML payload and use it in your mapping.

You can use either a DOM or a SAX parser, but using a DOM makes it very simple.

Just check this blog on how to do the same,

/people/alessandro.guarneri/blog/2006/03/27/sap-xi-lookup-api-the-killer

Regards,

Bhavesh