9198 Views // 0 Comments // Not Rated

InfoPathology - Part 11 - SharePoint Integration

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.

  • In the last step, when you map InfoPath form fields to SharePoint columns, the wizard doesn't actually create new columns.  For all intensive purposes, they "exist" and show up in the SharePoint views.  But while in the form library, if you click "Modify Columns and Settings," they are not listed in the columns section, which limits some of the advanced customization you can do.
  • You can only really map basic data types as well.  This pretty much forces you to create your own submission mechanisms if you want to use hyperlinks or SPUser objects, for example, in your columns.
  • There's no room for code.  There are some actions that can't yet be performed at the end of custom submission code, such as direct manipulation of the form's XML.  The next chance you have to "catch" the form before it's fully submitted would be in a custom form library event handler, when it could already be too late.  Therefore, a submission web method is the perfect place to intercept forms before SharePoint takes them over.

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..."

Form Library Event Handlers

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:

Code Listing 1

  1. using Microsoft.SharePoint;
  2. using System.Security.Principal;
  3. using System.Runtime.InteropServices;
  4. public class EventHandlers : IListEventSink
  5. {
  6. public void OnEvent(SPListEvent listEvent)
  7. {
  8. switch (listEvent.Type)
  9. {
  10. case SPListEventType.Insert:
  11. ...
  12. break;
  13. case SPListEventType.Update:
  14. ...
  15. break;
  16. case SPListEventType.Delete:
  17. ...
  18. break;
  19. }
  20. }
  21. }

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.

5 Tags

No Files

No Thoughts

Your Thoughts?

You need to login with Twitter to share a Thought on this post.