Coldfusion test client for fleXdoc web service

Oct 3, 2012 at 4:59 AM
Edited Oct 3, 2012 at 5:03 AM

I have put together a Coldfusion client to access the fleXdoc web service and this essentially works.  If anyone would like to use the code it can be found here.  

The one issue I have is that the saved docx file Word finds invalid.  However Word is able to recover the document and if then saved the resulting document is fine, so my solution is close.

The trick of changing the file extension from docx to zip to look into the file gives an invalid archive with the invalid file, but works fine after recovery.  

Suggestions as to what I might try next are welcome.

I was intending to attach an invalid file that Word can recover, but I don't see how to attach one.

Oct 3, 2012 at 5:34 PM

It's hard to say whats wrong with the document. Obviously the OOXML SDK did not detect any problems v(in your sample you have validation enabled). You can check the contents of the document yourself by opening it as a zip and inspecting the xml files inside. Another solution could be to remove the.flexdoc tags from the template one by one until generation succeeds.

Oct 9, 2012 at 7:54 AM
Edited Oct 9, 2012 at 8:03 AM

Thank you Robert for your reply.  I address the following remarks to your kind self and anyone else who may be able to assist, as I imagine the Coldfusion test client could be useful to a new audience.

I can't see that there would be anything wrong with the template Robert as it's your orderTemplate.docx that I'm using in my test.  Also, as per my original message, I have tried opening the corrupt document as a zip, but that doesn't work as the Windows 7 zipped folder utility says it's an invalid archive.  No, I think the issue is something to do with how I'm handling the response.

I have tried both MTOM and text and am still searching for precisely how I should handle either of these responses in CFML.  While not a C#/Net programmer I have looked at your code, searching for clues, but apart from a ToArray() function I can't see any explicit operation on the http response (maybe there's things going on in a layer of the software that isn't evident).  I'm imagining that the To Array() is equivalent to the toByteArray() I'm using on the fileContent element of the httpResponse (a link to my code is in the first paragraph of my original message).

I had tried to make the corrupted and recovered documents available for anyone interested and struck a problem with downloading .docx files as noted here.  This has indirectly proved useful, because I changed the file extensions to .doc.  Now the recovered file still opens in Word 2007 with no drama, while the corrupt original causes Word 2007 to offer a File Conversion dialog (if you try, careful, this dialog can open in the background and appear to freeze the machine).  In this dialog one cane see what it is that has been saved.  It starts with the '--uuid:' markers which I gather are part of MTOM.

Further, if  one saves the corrupt original then changes the extension back to .docx Word 2007 will offer the correct recovery to complete the cycle back to the recovered document.

Would really value a resolution to this (including a donation!) so that I can automate the whole process and not need to intervene in Word to recover the documents.

Really nice piece of software Robert, thank you.  Barry

Oct 9, 2012 at 9:30 AM

I checked your corrupt document. Indeed Word will not open it. When I rename it to .zip, WinRAR has not trouble opening it. Maybe you save too many bytes, making the archive officially invalid, but perfectly recoverable by WinRAR (which doesn't even display a warning) and Word.

Also: when rename the file to .ZIP, open it in WinRAR and then choose "Repair file" from the Tools-menu, it saved a slightly smaller zip-file. When I rename that back to .docx and open it in Word: no errors or warnings! I really thing too many bytes are saved. With Google I found this article:

It seems to describe exactly your problem.

Oct 19, 2012 at 4:57 AM

Hello Robert,

Thank you for the article reference above  on 'Saving binary MIME SOAP attachments'.  It's certainly talking about my problem, but the suggested workaround didn't look viable in my circumstance.  But it did set me off on a new excursion.  I now have a version of my test clint which successfully tops and tails the MTOM response and saves a valid docx file (hurrah!).  The code is here.

With the knowledge gained I also plan to re-explore the text option as I imagine when one knows what one is doing this will be simpler.  If I get a solution I will post again.



Oct 19, 2012 at 3:44 PM

Glad to be of help, Barry. The text endpoint may indeed be easier, since it simply base64 encodes the binary data to make it fit inside an xml document.

And thanks for the generous donation! The first one since 2009.



Jul 23, 2013 at 7:26 PM
Come check out the successor of fleXdoc: Docati!
It supports Word 2010 and 2013 as well and runs in the cloud.

I sure hope to welcome you as a Docati user as well! :-)