InfoPath Performance for SharePoint Data Connections - SharePoint Development & Administration + InfoPath

Saturday, August 1, 2009

InfoPath Performance for SharePoint Data Connections

When an InfoPath form has a large number of SharePoint data connections, the time it takes to open a the form will increase resulting in slow loading time when the form is being opened. To reduce the loading time of the InfoPath form, SharePoint list/library Views with filter criteria can be used to minimise the number of results, while ensuring that all required items that are displayed in the result set.

InfoPath Data Connections to a SharePoint list retrieve items from the list's default view. This can lead to the data connection not returning the required result from the SharePoint list if items are filtered or limited. See InfoPath data connection not returning all results from a SharePoint list for details.

For instructions in how to create and set up InfoPath data connections to retrieve data from SharePoint lists, see Using Secondary InfoPath Data Connections to retrieve data from a SharePoint List or Library.

The challenge when creating views to ignore irrelevant items is determining the filter criteria required that will display the smallest number of results possible, while at the same time ensuring that all required results are displayed. For Example, a data connection to a task list may only need to retrieve data from completed tasks, so the default view can be set to only display completed tasks, or the data connection can be linked to a specific view in the list (not the default) which displays the require completed items.

In most cases, recently created or modified items will be the most relevant.I commonly use SharePoint list view sorted by the Item ID in descending and limit the number of results to the required amount order limited to a specific number such as 100 or 200, which will return the items most recently added to the list. To ensure the InfoPath data connection retrieves the 200 most recently modified items, the filter criteria for the view should be set to sort by the Modified date in descending order, and the number of results limited to 200. Using either or a combination of the above two methods will ensure that any item or document/form recently created or modified will be available in the data connection's data source from the InfoPath form. This method will be most effective when the SharePoint lists used in the form as secondary data sources have a large number of items as well as there being data connections to multiple SharePoint lists. I have found that once there are 3 or 4 data connections or more retrieving data from SharePoint the loading time starts to slow when opening a new form.

List View Sort and Filter Criteria Examples:

The image below shows the sorting criteria required to display items in Modified date order, with the most recently modified file at the top.

The image below shows the sorting criteria required to display items in the order of creation, with the most recently added file at the top. This can also be achieved using the Created date column/field in the SharePoint list.

The Image below shows the required setting to limit the number of results in the SharePoint list view to 100. Set this value to a number which is large enough to return all required items in the InfoPath data connection, but not too large as this has an impact the forms performance when loading
data from data sources.

As the limit is reduced performance will increase, but risks not displaying all required results from the SharePoint list.
Share this article:
Stumble This Delicious
submit to reddit


Anonymous said...

I'm trying to create a data connection to "retrieve items from a specific view by entering the full URL" as specified in your article. I want different views of the same list with different sort orders for different but filtered drop downs in InfoPath. The connection still is only to the default view, not the URL of each view. Any suggestions? Also, performance with large lists is greatly improved if you use a Datasheet View instead of a Standard view.

DanielS said...

When entering the url to the SharePoint site and/or list, the second example URL suggests to enter the full url to the list and view aspx file. I have just tried this and it does only retrieve results from the default view. I have now corrected this statement in the article.

You could try by creating a data connection to the Lists Web Service on the site which contains the list you are connecting to.
The GetListItems method allows the GUID of a specific view to be specified as a parameter. Details of the GetListItems method:

Jeff said...

Thanks for the super quick response! Hadn't thought about using the Web Service. I'll try that out. Don't forget to give using a Datasheet view a try. It's MUCH faster. Thanks again.

DanielS said...

Hi Jeff,

Thanks for the Datasheet tip, as I was not aware of that. It does make sense that the Datasheet view is tweaked for performance otherwise it probably wouldn't be much use at all.
Let me know how you go with the web service. I have had problems in the past getting the Web Service method to take all parameters as it is quite "touchy" in that all required parameters must be complete and correct.
I have written an article which uses the UpdateListItems method of the same Lists Web Service. The article demonstrates how to create the CAML query and other components required as parameters by the UpdateListItems method (Update SharePoint List Items Programmatically from InfoPath). I'm not sure if it will help or not as I found the UpdateListItems method much easier to get working than the GetListItems method having less parameters required. I will have more articles posted on this blog providing examples of some other Lists Web Service methods shortly. The articles will all relate to InfoPath integration with SharePoint.



DanielS said...

I found the following blog post by Hilary Stoupa relating to performance for InfoPath Forms with Secondary data connections.

Sloooooooooooowwwwww Form (InfoPath)

Hilary found that in many cases where secondary data sources are being used to populate dropdown list box controls on a form template, the forms performance can be significantly reduced if the "Show only entries with unique display names" option is selected in the properties of a dropdown list control. Deselecting this option resulted in a significant imrpovement in performance.

As there are a number of factors that can affect the performance of InfoPath forms, the solution found by Hillary may not help in all cases. If an InfoPath form still has performance issues after deselecting the "Show only entries with unique display names" option, the following page contains more information about the possible causes of a slow InfoPath form, as well as some suggestions for how to resolve the issues.

See Improving the Performance of InfoPath 2007 Forms for details.



Post a Comment