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>﻿<?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
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?
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?
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.
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.