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