The Edge [of all] Journeys

[migrated from http://edgedev.blogspot.com]:

It seemed simple enough at first. All I wanted was a way to dynamically pull data from Lists and Document Libaries into InfoPath. Oh, but did I forget to mentioned that I also wanted the data filtered BEFORE it hit InfoPath because the Lists and Libraries might be massive (go figure). Trying several things, it became obvious that I needed a faster/better/easier method than any of the following:

1. Using a baked-in InfoPath data connection to a List is easy, but it retrieves ALL List items and leaves filtering to the controls. This is obviously a horrible method when working with large data sets.
2. Using custom code-behind on the InfoPath form to query SharePoint via the object model is perhaps the cleanest method, but adds code-bloat, is not very modular, and requires extra maintenance.
3. Using a web service data connection from InfoPath to SharePoint web services (like http://[site]/_vti_bin/lists.asmx?op=GetListItem) would be perfect, except that InfoPath does not form the xml in the SOAP request correctly (i.e. the way that SharePoint is expecting) and returns an error. Actually, this boggles my mind. Somebody please correct me if I’m wrong here and/or if there is a clever workaround that I couldn’t find / figure out. This seems like an incredible oversight on Microsoft’s part for 2 products that are supposedly designed to play nice together.
4. Since I’m in a K2 blackpearl environment, I also thought about using a SmartObject, which rivals option #2 for cleanest method, but it also adds an additional maintenance tail outside of InfoPath and requires additional wiring inside the form.

Looking for a solution, I stumbled on this article – http://blogs.msdn.com/infopath/archive/2007/01/15/populating-form-data-from-sharepoint-list-views.aspx – at the InfoPath Team blog which formed the basis for a new idea:

To summarize – if you don’t want to have to read through the whole article yourself: This little known feature allows you to pass GUIDs for Lists and Views, along with filter parameters, in the URL querystring to owssvr.dll and dynamically retrieve an XML “results” file. Furthermore, the URL itself can be used as the file location for an “XML Document” data connection in InfoPath.

The main hurdle is that, once the data connection is created, it doesn’t seem on the surface like there’s a way to dynamically update this file location to retrieve a different XML Results Document from a List or Library based on related fields in a form that has been opened. Well, it turns out that the InfoPath object model exposes this property and lets us manually execute the query.

In my particular scenario I wanted to retrieve a group of documents (metadata) from a massive Document Library where a DocumentColumn matched a particular FieldValue in the form opened. Here’s what I did:

1. [Optional] Create a View of the List or Doc Lib that contains the specific fields you want retrieved into the Form
2. In the Form, add a new Receive > XML Document data connection
3. For the “location of the XML data file…” in the wizard use:
   http://[server]/[site]/[list]/_vti_bin/owssvr.dll?Cmd=Display&List={LIST_GUID}&XMLDATA=TRUE
4. [Optional] Include &View={VIEW_GUID} if you want to pull data and columns from a specific view that already exists or was created in step 1.
5. Note: the GUIDs in the querystring parameters can be in either format:
   a. “{xxxxx-xxxxx-xxxx-…}”
   b. “%7BF498875E%2D5A645B%2D…” (as copied directly from SharePoint generated URLs)
6. Complete the data connection wizard – this will add the unfiltered data connection results schema to the Form (you do want the unfiltered schema). Make sure the following settings are set as you complete the wizard:
   a. “Access the data from the specified location”
   b. [UNcheck] “Automatically retrieve data when form is opened”
7. To add the repeating table that will hold the query results, find the xml/rs:data/z:row repeating group in the new data connection and drag it onto the form
8. To complete the solution, a little code-behind is necessary (but it’s minimal and a LOT less code than method #2 mentioned at the top). There are probably several ways to do this (like wiring the code to a button or another event), but here’s my basic approach:
9. Since the ID will already be stored in the form data by the time the user opens it (in the context of a K2 workflow), I use the form’s Loading event to modify the connection URL and execute the connection.
   a. In InfoPath Designer: Tools > Programming > Loading Event
   b. In Visual Studio Tools for Office: Insert > Loading Event
10. The following code will append – at run time – the filter parameter and value from a field in the form to the XML Data Connection location URL and execute the data connection to retrieve the hits:

// we need to instantiate a typed data connection object
// to modify the query and execute the results
FileQueryConnection dc = (FileQueryConnection)(this.DataConnections
[“NameOfXmlDataConnectionCreatedThroughWizard”]);
// next, we append the filtering values from the form field(s)
// to the existing URL already stored in the data connection
// –see notes for description of readNode()
dc.FileLocation += “&FilterField1=DocumentColumnName&FilterValue1=” +
readNode(“/my:myFields/my:FieldInForm”);
//finally, we execute the data connection to return the results
dc.Execute();

Notes:

• readNode is a little helper function I add to all my InfoPath forms so that I can quickly retrieve the value of a node without having to jump through navigator objects every time I want to get something. It looks like this:
  public string readNode(string xpath)
  {
  return MainDataSource.CreateNavigator().SelectSingleNode(xpath,
  NamespaceManager).InnerXml.ToString();
  }
• I think the SharePoint URL trick supports multiple FilterFieldX and FilterValueX parameters, so in theory, you could build pretty sufficient queries using the querystring alone. For example:
  “&FilterField1=ColumnName1&FilterValue1=Value1&FilterField2=ColumnName2&FilterValue2=Value2”
  This trick might also be leveraged throughout other events in K2 workflows since it returns standard XML and the query results are stored in /xml/rs:data/z:row.

Use this knowledge wisely. And have fun.