cancel
Showing results for 
Search instead for 
Did you mean: 

Invalid char in XML from inbound IDoc

Former Member
0 Kudos
438

I am trying to send a CREMDM IDoc from a 4.6C R/3 system to an XI SP09 system. The IDoc gets sent from the backend system, shows up fine in WE05, but after it gets passed to XI, I encounter a fatal error (in SXMB_MONI) that reads:

com.sap.aii.utilxi.misc.api.BaseRuntimeException: Fatal Error: com.sap.engine.lib.xml.parser.ParserException: Invalid char #0x15(:main:, row:1, col:986) at com.sap.aii.mappingtool.tf3.Transformer.checkParserException(Transformer.java:41) at com.sap.aii.mappingtool.tf3.Transformer.start(Transformer.java:66) ....

Upon checking the payload, I discover an "#" character in one of the fields (at position 986) has mysteriously been transformed to a " " character. XI does not recognize this character and the parser fails.

As I understand, the R/3 system is non-unicode, and XI being unicode could be causing the problem. However, I have no clue how to solve this issue. Deeply appreciate it if any ALE/XI experts can share any insights.

Regards,

Danny

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

It looks like there are some invalid chars in the IDOC payload. Since some invisible control chars are allowed for IDOC but not valid for XML, please have a look under W3C for XML specification. According to the stacktrace there is one invalid char for XML. Please check the raw content from the IDOC. # indicate actually invisible chars.

Hai

Answers (3)

Answers (3)

Former Member
0 Kudos

Thanks for all the response. It looks like the "#" character is in fact a control character from the R/3 system, which is a "negative acknowledge" (#0x15) character. This character is not valid for XML and hence it even fails the test tool in Integration Repository. I figured this out from your responses as well as checking the XML payload in XMLSPY (gave me a illegal char code 21 as well, which corresponds to the above hex code for the negative acknowledgement char).

It looks like we have to tackle the problem on the outbound IDoc side, which I am in the midst of figuring out how....

Former Member
0 Kudos

Hi Kwon,

Download the inbound message payload for the message from your R/3 system and test it in your mapping by putting the debug mode of the mapping test. Then you'll be able to see where the mapping is failing to create a particular table. Check for the value in that field and check with the idoc sent from R/3 system. If '#' is getting populated after the idoc creating program has created the idoc, try debugging the same and see why its getting populated when sent to XI.

Cheers

JK

stefan_grube
Active Contributor
0 Kudos

Hi Danny,

Apply the latest patch, that should help.

Regards

Stefan

Former Member
0 Kudos

Thanks for the tip... unfortunately I am working in a customer's environment and cannot apply patches as and when I like. Any other ideas?

stefan_grube
Active Contributor
0 Kudos

Tell the customer, that SAP strictly recommend to apply the lastest patches. Think about that SP9 was shipped in 2004.

You can also look out for notes concerning the IDOC adapter. There are some notes which might be related to your problem.

Regards

Stefan