How does the Document Converter deal with InfoPath XSN files

InfoPath is a complex file format misunderstood by many. Unlike ‘regular file formats’ such as MS-Word and Excel, the look and feel of the document is separated from the data, each in its own file.

When an InfoPath form is designed the Processing Logic and Visual Design are saved in a central XSN file, which is typically published in a shared location such as a UNC network path or in SharePoint.

When a user fills out an InfoPath form the XSN file is loaded from the central location and used for presentation / logic processing purposes. This XSN file is never modified by end users, instead data entered by the user is saved in an XML file that just holds data. This XML file also contains a reference to the location of the XSN file to make sure InfoPath knows how to display the XML file when it is opened.

So what does this have to do with Muhimbi’s Document Converter? Well, when the Document Converter is asked to convert an InfoPath file - by sending an XML file to it - the Document Converter looks in the header of the XML file for the location of the XSN file. The XSN file is then retrieved by the Document Converter as it is needed to determine the look and feel of the converted document.

In order for this to work the XSN file must be saved in a central location and be generally accessible by the Conversion Service. Common things that can go wrong when it comes to resolving the shared XSN file:

  1. The account the Conversion Service runs under does not have the privileges to download the XSN file from the shared location. Fix this by checking the privileges of this account in SharePoint or on the UNC path.

  2. The XSN file is not located at the location where the XML file says it is located. Perhaps the file was moved or renamed or points to a folder on a different machine.

  3. The XSN file was never published. For example the Preview function was used in InfoPath Designer to fill out the XML file. This is easy to spot by opening the XML file in notepad and looking in the header. If it points to an XSF file rather than an XSN file then the form was not filled out using a published version of the XSN.

  4. The Conversion Server cannot physically access the path of the XSN file. This can happen if the Conversion Server is firewalled off, Proxy authentication is required or if the XSN file is located on a completely different network.

The best way to troubleshoot XSN related problems is by opening the XML file in notepad and searching for ‘.xsn’ (without the quotes). This will show the full path to the XSN file. Then log in to the desktop of the conversion server using the account the Conversion Service runs under and try to open this XSN path in Internet Explorer. If you get an error, or are asked to authenticate, then that should hint at the cause of the problem.

For additional details see the InfoPath Troubleshooting Guide as well as other InfoPath related topics in our Knowledge Base.