coercion error: com.adobe.idp.Document to type: interface org.w3c.dom.Document

[Mark_Lindberg]

Greetings All:<br />I hope you can help me overcome an issue I am having receiving XML file attachments in an e-Mail endpoint. The process should place each attachment in a folder as an XML file on the server.<br /><br />Just a note, this process was working fine - and as some content has been added to the XML file it broke the process.<br />An e-Mail is received with a file attachment.<br />The Attachment_Map is read, and the entry is selected.<br />The entry is mapped to a process variable of type XML.<br /><br />The process fails with this:<br />Caused by: ALC-DSC-119-000: com.adobe.idp.dsc.util.InvalidCoercionException: Cannot coerce object: <document state="passive" senderVersion="3" persistent="false" senderPersistent="true" passivated="true" senderPassivated="true" deserialized="true" senderHostId="127.0.0.1/192.168.50.97" callbackId="0" senderCallbackId="0" callbackRef="null" isLocalizable="true" isTransactionBound="false" defaultDisposalTimeout="600" disposalTimeout="600" maxInlineSize="65536" defaultMaxInlineSize="65536" inlineSize="17157" contentType="application/xml" length="-1"><cacheId/><localBackendId/><globalBackendId/><senderLocalBackendId/><senderGlobalBackendId/><inline>&#65279;<?xml version="1.0" encoding="UTF-8"?><NewJobOrderInfo xmlns="http://TPIWebPAS" xmlns:xsd="http:/...</inline><senderPullServantJndiName>adobe/idp/DocumentPullServant/adobejb_server1</senderPullServantJndiName><attributes wsfilename="JobOrders.xml" basename="JobOrders.xml" file="JobOrders.xml" JKFileOrder="2"/></document> of type: com.adobe.idp.Document to type: interface org.w3c.dom.Document<br /><br />If I amend the process to write a "Text" file to the server, that step works - but the next process that needs to use it as XML cannot coerce it.<br /><br />I do not understand what is causing this to fail. It seems isolated to the particular XML attachment - as previous files will still run thru the process fine. I have run the XML in various tools that say it is "well formatted", but I don't know what are the critical items for conversion to XML.<br /><br />I am looking for ideas on where to look.<br /><br />Thank You for you assistance<br />Best Regards<br />Mark

[Former Community Member]

Mark,



If you send the XML instance to stwalker.adobe@gmail.com I can take a look.



Steve

[Mark_Lindberg]

Problem Solved - Question remains.
The issue was that some tags had a blank before the end:

instead of

This change allows the file to coerce to XML, but If something like this happens in the future, I don't know how to isolate the problem.
The files I am dealing with are quite large - so side-by-side comparisons are difficult, even with some of the tools that help.

Does anyone have any tricks they use for validating XML either in Workbench, or eslewhere?

Thanks!
Mark

[Former Community Member]

Mark,



I created a process with an email endpoint that extracts the xml attachment and writes the xml out to the file system. I tested an xml document with a blank inserted before the end tag and there was no complaints from LiveCycle. In fact, in the xml written to the file system the blank has been removed.



Are you trying to map the input xml process variable to another xml process variable?



Steve

[Mark_Lindberg]

Hi Steve:
This has been a learning experience for me.
It appears that the XML editor I downloaded "Corrects" XML without telling you.
Once I noticed it was doing that, I found what it had changed.
The following is an example of the changes it made:
From:

To:


So the editor removed the trailing space, and added an end tag.
These changes made the XML valid to the LiveCycle service that tries to coerce data.

As far as the process goes, I have an E-Mail endpoint that is receiving data from another system. It reads the attachment map, expecting XML - and writes XML files to a watched folder.
The Watched Folder process parses each XML file, and acts on the data inside.

I have not found a way to test contents of a variable to determine if it is valid XML that does not blow up the process as a result of bad XML.

Thanks for your time.
Mark

[Former Community Member]

Mark,



There are several possibilities. The first is less applicable to your process.



1) If you use the Read XML operation in the File Utilities, you can catch a FileUtilsException. I can catch the exception and react accordingly.



2) I put together the following script. It works quite nicely if the XML is represented by a string. The script gets the process variable 'xmlStr' of type string, runs the XML against the DOM parser, checks for well-formedness, and reports the results in a process variable called 'resultMsg'. This could (and should) be termed into a custom component quite easily. Give it a shot.



import java.io.InputStream;

import javax.xml.parsers.DocumentBuilderFactory;

import javax.xml.parsers.DocumentBuilder;

import org.w3c.dom.Document;

import org.xml.sax.SAXException;



String xmlStr = patExecContext.getProcessDataStringValue("/process_data/@xmlStr");

String resultMsg = "";



DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

DocumentBuilder builder = factory.newDocumentBuilder();

InputStream inputStream = new ByteArrayInputStream(xmlStr.getBytes("UTF-8"));



try {

Document document = builder.parse(inputStream);

resultMsg = "Valid XML";

}

catch (SAXException saxException) {

resultMsg = "Invalid XML";

}



patExecContext.setProcessDataStringValue("/process_data/@resultMsg",resultMsg);

[Mark_Lindberg]

Wow Steve!

Very helpful!

I can definitely use the Read XML error path. I plan to use the script you provided to validate the e-mail attachment prior to trying the Write XML to the watched folder.



Thanks so much

Mark

[Mark_Lindberg]

Steve:

One other question.

What method should I look at to take a Attachment Map Entry of type application/xml and render it to a string variable?



Thanks

Mark

[Former Community Member]

Are the attachments really in a map? Hmmm.



You will have to use the Collection functions 'get-collection-size', 'get-map-keys' and 'get-map-values'.



- initialize a process variable, say 'i', and set it to 1

- create another process variable, say 'j', and set it using 'get-collection-size' on the map variable

- create a loop using a Set Value operation and iterate over the map until 'i > j'

- get each map entry and coerce the XML to a string



See http://livedocs.adobe.com/livecycle/8.2/wb_help/000262.html



Steve

[Mark_Lindberg]

Yes, it's in a map.

It comes that way from the e-mail end-point.

I am already accessing the entry as a com.adobe.idp.Document.

When the XML is correct inside, it will coerce to org.w3c.dom.Document just fine.

I would like to take the com.adobe.idp.Document to string to pass into your script.

When I try to map com.adobe.idp.Document to string I am getting some kind of byte-array I believe.



Mark

[HowardTreisman]

This may be a dumb question, but if all you're doing is writing the XML document to the file system, then why are you bothering to map it to an XML variable at all. Just leave it as a Document variable, and write the document to the file system.

???

Howard

http://www.avoka.com

[Mark_Lindberg]

The problem started by trying prevent a "Bad" XML file from entering the process.

Bad could occur via a corrupt, incomplete, or otherwise just not XML file.

I could not find a method that would allow me to test a document variable (that contained the XML file attachment), and determine if the XML was OK.

If I set my process to move the Document variable to an XML variable, I would encounter the coercion error.

I have found that if I write the document variable to the file system as Text, and immeadiately read it back with the Read XML Service, the read service will catch and trap any errors.

The read also has an error handler built in so that I can branch accordingly.

The downstream process uses the submitted XML as input to a office automation application.

So, I do need XML as XML, but I need to eliminate bad data or the process crashes.

I did find the inital error that was causing the major issue - Byte-Order Mark.  The system that is generating the XML file was including a Byte-Order Mark in the beginning 3 bytes of the file. This was causing the coercion to fail.  Once the senders of the data eliminated this attribute life got a lot better.

Hope this helps

Thanks!

Mark

[HowardTreisman]

Thanks Mark

So a component to simply test the validity (well-formedness) of an arbitrary XML document would be helpful?

This would save you having to write the file to the file system, and read it back again.

By the way, do be careful with writing to a file and reading back. This may work doing one off testing, but you need to be careful under load, because you may get multiple process instances reading and writing the same file.

Howard

http://www.avoka.com

[Mark_Lindberg]

Hello Howard:

Thanks for your reply.

Yes, I believe a simple test would be a benefit, especially since without the ability to test in some manner, a process is destined to fail upon entry of an unacceptable file.

The scripting I tried would not seem to catch missing end tags, etc.

The Read XML service seems to have access to the correct level of parsing to determine good from bad - sadly I have not found a way to invoke it outside of the Write/Read scenario.

Based on the particulars of this application, I do not believe there will be a overrun file situation.  The process is invoked at most once every 15 minutes.

The XML file contains one to many parcels of data. If this first test validates the entire file, the next steps in the process break it down for processing.

It is a good thought to keep latency issues in mind, it is not my most favorite solution. I have the write set to overwrite.

Thanks Again.

Mark