on 08-10-2012 9:45 AM
Hi,
We have a Proxy to SOAP scenario where some chinese characters are being passed in some of the fileds. One of the field is receiving ¶ from the source but during runtime, it is getting converted to  and thus giving error-- XMLParser : #20 not allowed in Character data sections.
I have gone through the SDM forums also, but did not get any resolution to this as yet. Please help, it is really urgent.
Thanks in advance.
Regards,
Mradul
Hi Mradul,
As far as i know this is not encoding problem because the special html entity can't be proccesed by XML parser, there is no message mapping and not xsl mapping solution for this. The only solution is to change this char for a valid char in a java mapping or work with a java mapping at byte stream level. I think the best solution is the Anupam's solution but you can change the char instead to remove it.
Regards.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Mradul,
First step is to download this hex editor
http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm
Now check exactly what is the ASCII value of the character you are having problems with.
once you you are sure of the ASCII value use a small java mapping code to remove all such characters from your input payload. Just add the code/class file below/above(depending on the error occurrence) the message mapping in the same interface mapping. In your case I think the hex code of the characters would be 0XB6. Please check and alter the code appropriately.
Here is the code for PI 7.1 and above versions.
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.OutputStream;
import java.io.OutputStreamWriter;
import java.io.Reader;
import java.io.Writer;
import com.sap.aii.mapping.api.AbstractTransformation;
import com.sap.aii.mapping.api.StreamTransformationException;
import com.sap.aii.mapping.api.TransformationInput;
import com.sap.aii.mapping.api.TransformationOutput;
public class removeSpecialCharacter extends AbstractTransformation {
/**
* @param args
*/
public void transform(TransformationInput arg0, TransformationOutput arg1)
throws StreamTransformationException {
// TODO Auto-generated method stub
this.execute(arg0.getInputPayload().getInputStream(), arg1.getOutputPayload().getOutputStream());
}
public void execute(InputStream in, OutputStream out)
throws StreamTransformationException {
try
{
Reader r=new InputStreamReader(in, "US-ASCII");
Writer w=new OutputStreamWriter(out);
int c;
int ascii_of_characters_to_remove=0Xb6;
while((c=r.read())!=-1)
{
if(c==ascii_of_characters_to_remove)
{
continue;
}
w.write(c);
}
r.close();
w.close();
}
catch(Exception e)
{
e.printStackTrace();
}
}
}
This works perfect in my system. Hope this solves your problem too.
Regards
Anupam
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Anupam,
Thanks for the solution Anoop, but going for java mapping is the last resort as this code is already live and to implement anything major wont be possible. Also, the character is not to be removed, the client needs it.
Actually this refernce has different codes like  for HTTP and 0x14 (14) for UTF-8. But what is happening is, instead of converting into UTF-8 code, we are getting HTTP code, that is why it is not able to parse the XML. Is there any encoding header for HTTP or any other possible solution for this without removing the character and java mapping ?
Regards,
Mradul Rustagi
First of all you should figure out why there are such entries in XML document. Maybe the source application has an issue and the responsible guys can fix it.
There is no difference between Ŋnd 0x14. Both values represent ASCII value 20, which is not a valid character and therefore not allowed inside an XML document. As the sender of the XML document is an ABAP proxy, it seems to be an issue in ABAP code are in ABAP table.
User | Count |
---|---|
87 | |
10 | |
10 | |
9 | |
7 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.