Building SharePoint Applications with InfoPath 2010 (Part 1 of 2)

Building SharePoint Server 2010 Applications with InfoPath 2010

Microsoft InfoPath 2010 enables an organization to build robust end-to-end Microsoft SharePoint applications. When combined with InfoPath Forms Services in Microsoft SharePoint Server 2010, InfoPath 2010 empowers you to automate your own business processes that collect, manage, and share information. As an IT professional or developer, you can create a powerful business application by using declarative logic (no code) on the SharePoint platform by using InfoPath forms to interact with external data and drive workflows. This article describes best practices for building SharePoint applications by using InfoPath 2010; part two of this article contains a sample walkthrough for a hardware request scenario.

SharePoint Server 2010 Application Architecture

When building a SharePoint application, you must answer some basic questions about your end-to-end scenario. Is there a requirement for users to work while disconnected from the corporate network? How will data that is collected by forms eventually be stored? What external data sources must be pulled into the solution?
In identifying answers to these questions, you will have a better idea of what the complete application architecture will resemble. But how do you know when InfoPath 2010 is the best solution for your business problem? This section examines some other options that you might consider when you build a SharePoint application. Then, for InfoPath solutions, this section reviews the decision tree for selecting the correct form template. Figure 1 shows the architecture decision tree for a SharePoint application that uses InfoPath 2010 and serves as an overview for this section.

Figure 1. Architecture decision tree for a SharePoint application that uses InfoPath 2010

Choosing Whether to Use InfoPath 2010

As the previous figure showed, there are other technologies to consider when you implement forms in a SharePoint application. The following list describes several of these options:

• Microsoft Word 2010 documents
  
• Microsoft Access 2010 forms
  
• Microsoft ASP.NET Web Forms
  

Table 1 offers a quick comparison between InfoPath 2010 and these other options across different areas. Table 2 provides a summary analysis based on the size and complexity of a SharePoint application. The subsections that follow give more details about each application.

Table 1. Comparing InfoPath 2010 to other form applications

Question	InfoPath	Word	Access	ASP.NET
What is the technical level of the individual building the form?	Information Worker	Information Worker	Information Worker	Developer
What kinds of controls are supported?	Intermediate	Basic	Basic	Advanced
How are external data connections added?	Declaratively	Either with custom code or an embedded Document Information Panel	Declaratively	With custom code
What kind of custom code can be used?	Microsoft Visual Basic or C#	VBA or add-ins created by using Microsoft Visual Studio, which must be installed on users' computers	VBA	Any .NET or scripting language
Does the application support browser scenarios?	Yes	No	Yes	Yes
Does the application have an offline client?	Yes	Yes	Yes	No
How are printing requirements addressed?	Export to PDF or XPS, print views, or custom code to generate a document	WYSIWYG editor or export to PDF or XPS	Export to PDF or XPS	Custom code to generate a document
Is there integration with SharePoint workflow?	Yes	Yes	No	Yes
How is the form deployed?	Either as a SharePoint list, published to a form library, or published as a SharePoint content type; administrator-deployed forms are uploaded to InfoPath Forms Services	As a SharePoint content type	Published to Access Services	Through Visual Studio

Table 2. Application recommendations depending on the solution type

Solution Type	Recommendation
Simple complexity, form data that is stored as client files	Word
Simple complexity, form data that is stored as list items	InfoPath
Moderate complexity, without workflow	Access
Moderate complexity, with workflow	InfoPath
High complexity	ASP.NET

Microsoft Word 2010

With the introduction of the Microsoft OfficeOpen XML Formats in the 2007 release, Microsoft Word became a reasonable alternative for client form scenarios that collect rich content. By using the file formats, a Word document now consists of a ZIP archive, which contains several document parts. The archive can include a custom XML part that defines a specific data source. You can then add content controls to your document that are bound to nodes in the custom XML part. You can prevent the user from editing content outside these controls by grouping the document or different sections of the document. Essentially, grouping encloses selected content in a read-only content control. A grouped document acts more like a form, because the user is forced to enter data within the content controls that are bound to nodes in the custom XML part. If you create a SharePoint content type that uses a Word document template, SharePoint automatically creates the custom XML part in the archive, with the nodes bound to any site/list columns that you define for the content type. Thus, the combination of editable content controls and integration with content types enables Word to be a practical option for SharePoint applications.

Microsoft Access 2010

Microsoft Access 2010 is a relational database application that can aggregate multiple external data sources into a single location. You can connect to a SharePoint list, web service, XML file, and other sources. You can also export tabular data to a variety of formats, such as a SharePoint list, HTML document, Word document, or Microsoft Excel 2010 workbook. An Access form is a simple way to add records to database tables. You can easily create a form from an Access table, and then use layout tools to add existing table fields, controls, and conditional formatting as needed. By using a single click in Access 2010, you can also publish the database to Access Services as a SharePoint application. Publishing the database makes all tables, forms, reports, queries, and macros available in a browser, and provides storage in a central SharePoint location. Before publishing, you can run the compatibility checker in Access 2010 to ensure that items and settings in the database are supported on the web.

ASP.NET Web Forms

If you want to build a robust web application that integrates SharePoint, an ASP.NET Web Form offers the most flexibility. You create an ASP.NET Web Form as a combination of HTML and controls that execute on a web server. Working in Microsoft Visual Studio 2010, you can drop controls onto forms and then double-click those controls to write custom event handlers. Built on the Common Language Runtime (CLR), ASP.NET enables you to write code by using any supported .NET Framework language or scripting language. A developer who is building an ASP.NET Web Form has full access to the SharePoint object model and a large selection of controls.

Selecting the Right InfoPath Form Template

You basically have two options when you select an InfoPath form template to use in SharePoint applications. As was the case since InfoPath was introduced in 2003, you can design a form that is hosted in a SharePoint form library. You can publish such a form template directly to a form library or as a site content type, which lets multiple libraries within the site refer to the form. New to InfoPath 2010 is the SharePoint list form template. You can configure the default form template for any existing custom SharePoint list, or you can create a SharePoint list directly from the InfoPath designer. SharePoint list form templates use a subset of the features that are available in form library templates, but require fewer configurations with regard to deployment.
Whether to use a SharePoint form library or a list is an important architectural decision that is based on answers to some key questions. Table 3 offers a quick comparison between the two template types based on these key questions, whereas the rest of this section provides more detail with regard to differences.

Table 3. Comparing form library and list templates

Question	Form Library Template	List Template
What is the structure of the form data?	Hierarchical	Flat
How is form data stored?	XML files	List items
Is there support for custom code?	Yes	No
What offline client is available?	InfoPath filler	SharePoint Workspace
Is there support for digital signatures?	Yes	No