InfoPath 2010 Online Forms and the SharePoint Records Center

In the next article in our series of building out an InfoPath 2010 solution in SharePoint, we are going to try to overcome some anomalies that are revealed when we move an InfoPath document to the SharePoint Records Center.

If you have been following along with our previous articles (see links below), you are able to create InfoPath forms, walk them through the simple approval process and have them automatically moved to a SharePoint Records Center. If you have not walked through the prior examples yet, now might be a good time to do so.

If you have walked through the examples, or if you just stumbled upon this article because you too have experienced the issues contained herein when working with InfoPath forms on the SharePoint Records Center, then you are about to replace your immense frustration with happiness…so you can do one of the favorite things we do as SharePoint developers - get to the next error.

What Happened to My Form Link?

The first thing you will notice about the Records Center version of your InfoPath form is that clicking on the name of your document does something horrible. By way of example, I have created a document for the customer Catherine Abel, approved it, and had it moved out to the Records Center by the workflow we created in our last article.

Before we click the link, let's just hover over it for a second and see what happens in our browser's status bar.

If you remember from our earlier articles, InfoPath Forms Services forms need to be loaded into the form processor ASP.NET page (FormServer.aspx) located in the _layouts folder. There are several Query String parameters that are also used with this ASP.NET page. They are:

* XmlLocation: This is the location for the filled-out instance of your form. This replaces both the "XsnLocation" and "SaveLocation" parameters for the form creation paradigm discussed in prior articles
* Source: This is the "follow-on" page that you want the user to see after viewing the form
* DefaultItemOpen: This is how the form processor knows to open the form in the browser instead of the InfoPath thick client

As you can tell from hovering over the link, we are certainly not going to be sending our browser traffic to the form processor when we click that link. Just for laughs, let's click it and see what happens.

Wow. That is not only a very unpleasant user experience, it is also downright confusing. Under normal circumstances, you would have your documents pretty well locked down by the time they get to the Records Center. But this seemingly harmless dialog appears to be saying that all you have to do is click the "Edit" radio button, security goes out the window and all bets are off. That can't really be the case can it?

Let's go ahead and follow this through to the end, just to see where it leads us, shall we?

So, what happened for you? Depending on whether or not your browser is already configured to do something with XML files, you may end up looking at the underlying XML in your browser, launching your preferred XML Editor, being prompted to download the XML file to your local hard drive (this was the option I received, as I was using a fairly pristine development VM), launching InfoPath 2010 in Designer mode, or perhaps something even worse!

So, regardless of which option you experienced, that was extremely ugly. The first thing we need to do here is change the document link to point to the form processor, along with the proper Query String fields. Incidentally, if you are presented with the "File Download" option, you might want to exercise it, as we are going to be looking at the document's XML later. In fact, even if you didn't get that option, it might be a good idea to Right-Click your document and select "Save Target As" to get your hands on a local copy.

Solution

In the interest of helping to teach as many different approaches as possible during this series or articles, and also to help us all start thinking about repeatability and predictability in our solutions, we are going to use a custom SharePoint workflow for this solution. Since we have already fiddled around with SharePoint Designer, we might as well go after the full enchilada here and fire up Visual Studio, no?

Before we do that, we have a little bit of housekeeping to take care of. If you followed the example in our earlier articles, you have the simplest of all content types housing your forms in the Records Center. There is essentially one user-exposed piece of metadata, the standard "Name" attribute that comes along with all document-based content types.

I have found over the years that messing with this attribute, other than changing the display text, is not necessarily an undertaking worth pursuing. I have often found it easier to create my own piece of metadata (list column) that I could control myself, add it to the Content Type, and then create a Custom View with the standard link column removed.

So, let's do that now. Go to your Records Library and click the "Library" tab in the ribbon. Now click the "Library Settings" icon on the far right of the ribbon, in the "Settings" section. Under the "Columns" section, click the "Create Column" link. Create a Hyperlink column named "Document", give it a nice description, and click the "OK" button.

Now, let's create a custom view based on the default view (All Items) and remove the old "Link" field. Scroll down to the bottom of the Document Library Settings page and click the "Create View" link. Click the "All Documents" link in the "Start from an existing view" section.

Give your view a name, check the box next to "Make this the default view" and remove the "Name (linked to document with edit menu)" column.

So, the more observant of you probably noticed that we have removed the field with the edit menu. In order to be able to interact with our records from the new view that we just created, we are going to have to assign the edit menu to another attribute…ideally, our new "Document" column.

Now, I know that some of you are starting to get a little anxious and very excited to launch into Visual Studio 2010. Well, you will just have to wait…because there is a very nice little trick that we are going to show in SharePoint Designer to add the Edit Menu to our view.

So, let's launch SharePoint Designer 2010 and connect to our site. Make sure you connect to the Records Center site, not the main site. Click on "Lists and Libraries" in the "Site Objects" navigation. Now, click on the name of your library.

In the upper right of the List/Library summary page, you will see the "Views" section. Click on the "Document View" view and go to "Code" view.

Find the line of code the references your newly created column. It should look something like this:

<FieldRef Name="Document" />

Change it to add the ListItemMenu attribute, set to "TRUE", like so:

<FieldRef Name="Document" ListItemMenu="TRUE" />

That's all there is to it! We will now have the Edit Menu associated with our new column. Click the Save icon and close SharePoint Designer.

OK -- we are finally ready to fire up Visual Studio 2010! Please do so, click on the "New Project" link and select the "Sequential Workflow" template under the SharePoint 2010 heading.

Give your solution an intuitive name and click the "OK" button. I am going to name my solution "RecordsCenterProcessingWF", since we are going to use it to process all new records submitted to the main repository in our Records Center.

Select a local site to use for debugging and choose to deploy your solution as a farm solution.

Click the "Next" button then name your workflow. Make sure that you set up your workflow as a list workflow, not a site workflow.

Click the "Next" button then select the appropriate document library to associate your workflow with. You can also elect to use your own custom workflow history list and/or task list if you so desire.

NOTE: If you do not already have a Workflow History list, Visual Studio will create one for you, but that is not the case for a the Task list. If you don't already have a Task list on your site, you will need to create one before you can finish the Visual Studio solution creation wizard for the workflow.

By default, the workflow will be set up to automatically launch whenever a record is created in the Records Library, as well as allowing the workflow to be kicked off manually. If you would like to change these options, click the "Next" button and make the changes. Otherwise, click the "Finish" button.

When the Workflow UI launches, drag a Code activity directly underneath the onWorkflowActivated1 activity, and name it "ChangeDocumentLink".