How does Document Converter handle 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 Universal Naming Convention (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. The XSN file is never modified by end users, instead data entered by users is saved in an XML file that just holds data. The 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 Nutrient’s Document Converter? When the Document Converter is instructed 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.

The XSN file must be saved in a central location and be accessible by the Conversion Service. Common things that can go wrong when it comes to resolving the shared XSN file are:

  1. The account the Conversion Service runs under does not have the privileges to download the XSN file from the shared location. Fix it by checking the privileges of the 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, 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 restricted by a firewall, requires proxy authentication, or if the XSN file is located on a 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. Once you locate the full path of the XSN file, log in to the desktop of the Conversion Server using the account the Conversion Service runs under and try to open the XSN path in Internet Explorer. If you encounter an error or a request for authentication, it likely indicates the underlying cause of the issue.

For additional details, see the InfoPath Troubleshooting Guide as well as other InfoPath related topics in our knowledge base.