Sharepoint and Infopath

A departure from the usual running related info.

In my real daytime job I write code. The platform for the last few years has been web related code and I'm currently writing against MOSS 2007 (Sharepoint) and Infopath. We're using Infopath as the means to access content since it's easily modifiable by customers without the need for a development environment. This implies, unfortunately, that's it's not a development environment itself.

Infopath has been around a little while, it lets users create forms for use with workflows and a way of entering metadata with documents. It's matched with Sharepoint's document modelling and they two go hand in hand. If you install Infopath 2007, you can create and modify forms for your company and they're easily deployed and maintained using Sharepoint central administration.

What it doesn't do well at all is allow designing a form in one environment and deploying it to another. As a software developer, this is what I do all the time. This is the whole gist of enterprise level development. I've been saddled with the task of wrenching what I can out of these forms for the last couple of years. If I'd known what I was getting myself into, I would have gladly handed this over to another member of our team.

Infopath is an ad-hoc tool. You have an installation already, you create and deploy forms on it for users to use. It's architected this way, this is it's basic design. In the past, Infopath forms and templates were comparable to Word documents and Excel spreadsheets in that you really need the installed client to use them, and with Infopath you don't have any other way of using them, the technology is proprietary. To ease the customer burden, Microsoft took advantage of XSLT technology as a way of being able to render form content in a web browser. The introduction of Infopath forms services grants access to forms and form content through the browser. There's some tradeoffs with this, and this is where the fun begins.

First off, once designed in the browser, more than half the functionality of Infopath disappears. Many usable controls won't work in the browser, dynamic access to the document model is suddenly restricted. HTML is stateless and therefore the dynamic interplay of form and host goes out the window.

Secondly, the introduction of forms services inherently creates it's own tier in the architecture. This brings the dreaded NTLM double-hop restriction into clear play. As most deployments of forms and forms services will be in such environments of at least 2 tiers, virtually everyone who's ever implemented Infopath through forms services has encountered this problem.

As a bonus, data connection errors in Infopath are displayed to the user as the completely useless 5566 error, which claims an error has been logged in the event viewer (which is a lie, unless you've explicitly written errors to the event viewer yourself in the web services you may be hitting, or not) and gives virutally no detail on what went wrong. To troubleshoot, you need to peruse IIS and Sharepoint logs to see what happened. This doesn't always work because sometimes the call never makes it to the actual server, so you have nothing to go by. And don't think you can just bring up native Infopath to help (as Infopath will display the actually error encountered), because almost always the problem will not occur in native Infopath with it's direct calls to the web services, thus avoiding double-hop scenarios.

To help alleviate the problems, data connection files can play the role of intermediary between Infopath, forms services and the service layers you're trying to reach. It doesn't necessarily solve them, but it at least gives you a fighting chance of getting things to work. For starters, you can add explicit credentials to the connection files (bad idea from a security standpoint, but it usually will work). Or you can leverage some back end help in the form of Single sign on, Kerberos authentication, or forms services proxy. The forms services proxy is a bit of a mystery, there's tons of info telling you how to enable it and get the forms to use it, but squat explaining what it actually does from within. Kerberos ain't all that welcome either as it and Infopath don't seem to get along very well, as we're now discovering in our rollouts. It's less about Infopath in this case and more about web services, but you have few options on how to access server content in Infopath without web services. You'll find that you'll need to go back to Visual Studio to make your web services Kerberos friendly before this option is viable.

I can only recommend to anyone out there that's planning on using these tools that they should do their homework first. There's much more information available than when I started, and I sure could have used the information in the links below when I started this. Good luck, you'll need it.

http://msdn.microsoft.com/en-us/library/ms771995.aspx
http://msdn.microsoft.com/en-us/library/cc704269.aspx
http://msdn.microsoft.com/en-us/library/ms772101.aspx
http://blogs.msdn.com/infopath/archive/2006/10/02/Data-Connections-in-Browser-Forms.aspx
http://msdn.microsoft.com/en-us/library/bb787184.aspx#ip2007AdvancedServerSideAuthentication_UsingtheSingleSignonService

http://msdn.microsoft.com/en-us/library/ms464040.aspx

http://www.thenewmossness.com/Lists/Posts/Post.aspx?ID=19