InfoPath, SharePoint and Outlook woes
InfoPath is a great tool already provided in the office suite since the 2003 edition. It allows you to relatively easily create data entry forms. They can be created from scratch, derived from a database or web service, they can be sent via email, published to SharePoint, used as a browser based form amongst many other possibilities in between. It would be a good tool to consider whenever you are using data entry forms in a workflow because it provides the tools needed to keep track of all the data collected and provides the avenues in which to propagate the Forms and then record the collected data for later use. In my brief experience with InfoPath I have run into a few quirks that it embodies and I wanted to share them so that others can learn from what I have discovered.
First a little background for those who are unfamiliar with InfoPath. InfoPath is comprised of two main entities, the Form Template and the Form. The Template is the file that contains all the information about the layout of the Form, the controls and data sources that it uses and it is saved as a ‘.xsn’ file. It is basically a blank data entry form that needs to be filled out, and it is what ‘Forms’ are created from. A Form is an xml file which contains all the data that has been entered into the Form Template. It has ‘href’ and ‘name’ attributes containing knowledge of the location, current version and unique Id of its parent Template amongst other things. Info path uses these two files to display a data form and its contents to you. One thing to keep in mind is that when you open a Form, InfoPath expects to be able to locate its Template so that the data can be displayed correctly. One neat thing about InfoPath and Outlook is that Outlook has the ability to recognize an InfoPath email and allows a user to edit the Form in Outlook and send it back without having to save the attachments anywhere. Alright so now that you are an expert with InfoPath I will talk about the problems I encountered and some observations I made along the way to solving those problems.
The general work flow was as follows. There were Forms created and published to SharePoint so that they are easily available. These Forms would then be sent to employees from a manager. The manager could do this by opening a new Form, filling out some information and then clicking a button which would then cause both the Template and the Form to be emailed to the chosen employee so they could fill the rest of the Form out and send it back. Both the Template and the Form have to be sent in the email so that InfoPath has the correct Template at hand when trying to open the Form. When testing the Template from the computer where the Form was created (before publishing it to SharePoint), everything worked as expected, I could create a new Form, send it to a client computer, open it in outlook for editing and chose to send it back. But as soon as I published the Template to SharePoint, when I tired opening the email on the client computer, I would get an error message saying “The Form Template associated with this Form cannot be found. It is not on your computer and the Form does not specify a location from which to retrieve it. To fix the problem, ask the Form author to provide the location of the Form Template or update the Form.” Even though the Template was clearly attached to the email as it was in the previous test. The Template could be manually opened from the attachment, and then the Form would discover it, but outlook/infopath wouldn’t automatically match the two as it had done in the previous test. After a lot of testing I narrowed it down to one difference between the Form’s xml. In the example that worked the href attribute (which contains the url or file path location of the parent Form) started with ‘file:’ because the Templates origin was from on the local computer, but in the example that didn’t work the href attribute started with ‘http:’ because the Template originated from the SharePoint server. In both cases when the Form arrives at the client computer the Forms href attribute still points to its original location from wherever it came from whether it be a file path or url, this does not seem to be a problem. So what is causing the problem? For some reason when Outlook (and InfoPath) sees that the href attribute is a file path it saves both the Template and Form to a temporary directory, ‘….Temporary Internet Files\Content.MSO\*random alphanumeric*.tmp’ and then InfoPath opens the Form using the temporarily saved Template, but this does not occur when the href attribute contains a url.
So it seemed that in the process of publishing the Template to the SharePoint server through InfoPath, something is changed causing the resulting href attribute in the Forms created from that Template to reflect the SharePoint server. So to solve this issue, instead of publishing the Template to SharePoint I directly placed a copy of the Template onto the server. The href attribute in the Forms resulting from this copied Template still contained that file path of the local computer from which the Template was developed on instead of the SharePoint server in which it currently resided, so it solves the problem of editing the Form in Outlook. There may be a better solution, but I am unaware of it at this point and could not find any write-ups about this problem on-line.
Along the way I discovered a few other little tidbits that might be nice to know about InfoPath. As I had said previously when sending an email from SharePoint, InfoPath couldn’t match the Form to its Template. But after you opened the attached Template once, InfoPath had no problem opening the Form. I believe this is because once you open a Template, InfoPath saves some information about that Template, including but not limited to its location, and its unique id. Also mentioned previously there is a name attribute in the Form xml which contains the unique id of its parent Template. I believe when you try to open a Form InfoPath first tries to open it based off of its href attribute, but if it cannot find that Template it will look at its cached Templates and try to match unique ids and open the Template this way. This conclusion is based purely off of observation and hasn’t been concretely proven the process in which InfoPath opens Templates. These cached Templates can be removed by navigating to the ‘getting started’ window (which can be found by clicking file > Fill out a Form…) then going under Form categories clicking All Forms and selecting a Form and clicking ‘Remove this Form’.
Some other observations worth noting is that the directory in which a Template is published to on SharePoint has a direct effect on the resulting Forms name attribute. Although I don’t think this caused me any problems it may be something worth keeping in the back of your mind. Also if there are multiple versions of a single Template, and you chose to open a ‘recently used template’ from within InfoPath, it will use the template version that was last opened which may not necessarily be the newest version.
So if you ever have to work with InfoPath, SharePoint and Outlook together, keep these observations in mind if you run into any quirky problems.