As mentioned in a pervious posting, SharePoint Form Libraries are a natural home for InfoPath forms to live in. If you are creating basic forms that will be filled out by multiple users and all stored in the same place, then out-of-the-box SharePoint and InfoPath functionality take care of over half of the system development for you.
However, and inevitably, when we need to step off the beaten track, (in other words, do something other than simply fill out a form and submit it as a SharePoint List Item) it's time to get into some SharePoint code and work our magic. Almost all of this code is executed in SharePoint Web Services that are tailor-made to work with providing data to and receiving data from InfoPath forms. This is particularly useful if you want to work without code-behind, as a lot of this "managed" functionality can be leveraged in a web service rather than the form.
The most common task here is form submission to a SharePoint Form Library. Like I said, the out-of-the-box functionality can do a lot of the work for us; the Form Publishing Wizard is one of the nicest features of InfoPath. There are some aspects of this wizard that don't quite get the job done, however.
So here are some InfoPath bridges I've crossed over SharePoint's at times treacherous waters. It's always a good idea to read up on SharePoint in MSDN, especially in the realm of code access security. Many times have I found myself muttering out load, "But...it worked on my machine..."
We now have code running behind our InfoPath form and in the web service that it is submitted to. After the submission web method is complete, a file will be added to the form library, and a list item to the corresponding list. There is one last place where code can be executed before this form's submission is complete: inside a SharePoint Form Library Event Handler.
The way these work is that basically one method is created within a class that implements Microsoft.SharePoint.IListEventSink. This library is then deployed to the SharePoint server's GAC. Finally, in the form library's advanced settings, the library is referenced via its fully qualified name. Note that event handlers must be globally enabled in SharePoint's central administration.
Here is what a watered-down example of this code will look like:
From within the above Select statement, you can react to different actions that take place in the form library as files are changed. A useful example of this is if you are mirroring the SharePoint form library with a SQL Server database table. Whenever a new file is inserted, you can get the URL of the form from the SPListEvent, open it up as raw XML, extract data from the fields, and create rows in the database.
Likewise, when a file is deleted, the corresponding rows in the table can be removed. From this table, you can create very useful monitoring and aggregation tools for your form library using Microsoft SQL Server Reporting Services that can be used to combat some of the limitations of views within a SharePoint form library.