cancel
Showing results for 
Search instead for 
Did you mean: 

Strange problem in AFW custom module (question for gurus)

former_member184154
Active Contributor
0 Kudos

Hi there SDN'ers,

I have I very strange problem with an additional Adapter Module I developed.

My scenario is: IDOC -> JDBC (Oracle)

Well, to make a long story short, say that before the JDBC Receiver cc can write my data to the db, I have to do (inside the channel) kinda java mapping in order to produce an XML document that is acceptable for it. So in my module I manipulate the payload via DOM. No problem here.

The strange story is: at first attempt, the Adapter fails (see error below), while after 5 minutes, when automatically trying again, it succeeds.

Just because I put some stuff in the message audit log, what I can tell you is this weird thing:

1. at first, no XML document exists in the payload, but in place of it there's this string:

org.apache.crimson.tree.XmlDocument@745501c6

which seems to be a toString() of something I don't (or don't know to) use directly

2. at the second attempt, even in the audit log I can actually see the weel-formed XML document ready for the JDBC adapter, and in fact data are written to the db.

?? WHAT COULD THIS BE CAUSED BY ??

Say also that the the other way around (JDBC->IDOC) with another very similar module works perfectly.

Thanks.

Alex

<b>Delivery of the message to the application using connection AFW failed, due to: ERROR occured parsing request:com.sap.engine.lib.xml.parser.NestedSAXParserException: Fatal Error: com.sap.engine.lib.xml.parser.ParserException: XMLParser: No data allowed here: (hex) 6f, 72, 67(:main:, row:1, col:3)(:main:, row=1, col=3) -> com.sap.engine.lib.xml.parser.ParserException: XMLParser: No data allowed here: (hex) 6f, 72, 67(:main:, row:1, col:3).</b>

P.S. -> 6f, 72, 67 is "org", that is the first three letter of the weird payload I get at first attempt.

Accepted Solutions (0)

Answers (1)

Answers (1)

former_member184154
Active Contributor
0 Kudos

Ok guys, I got that workin'.

I don't know why - and don't think I'll have the time to investigate further - but it seems the implementation of DOM Document used by XI is different the first time AFW executes my module, so here my workaround.

if (docOut instanceof org.apache.crimson.tree.XmlDocument) {
   org.apache.crimson.tree.XmlDocument tmpDocOut = (org.apache.crimson.tree.XmlDocument)docOut;
   tmpDocOut.write(out);			
} else {
   out.write(docOut.toString().getBytes());
}

Regards,

Alex