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

Summary:  Learn best practices for building SharePoint applications by creating a sample application that uses Microsoft InfoPath 2010.

Applies to: InfoPath 2010 | InfoPath Forms Services | Office 2007 | Office 2010 | SharePoint Server 2010

In this article
Building SharePoint Server 2010 Applications with InfoPath 2010
SharePoint Server 2010 Application Architecture
Best Practices for InfoPath SharePoint Applications
Conclusion
Additional Resources
About the Author

Published:  October 2010

Provided by:  David Gerhardt, 3Sharp | About the Author

Contents

  • Building SharePoint Server 2010 Applications with InfoPath 2010

  • SharePoint Server 2010 Application Architecture

  • Best Practices for InfoPath SharePoint Applications

  • Conclusion

  • Additional Resources

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

Architecture decision tree

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

Understanding the Form Structure

The structure of the InfoPath form helps determine whether you select a SharePoint list form template or SharePoint form library template. Consider the XML structure for our hardware request scenario, as shown in the following example.

<Request>
    <RequestID>f94a566d-1581-49bd-abf7-bcad68e8c0b3</RequestID>
    <RequestDate>2010-03-24</RequestDate>
    <Requestor>Karen Berg</Requestor>
    <RequestorManager>Holly Holt</RequestorManager>
    <HardwareType>Keyboard</HardwareType>
    <HardwareName>Coho Writer K9</HardwareName>
    <HardwareModel>CO K9 NOP</HardwareModel>
    <HardwareSpecs>Black, USB; Ergonomics Design; 104 Normal Keys; 9 Function Keys</HardwareSpecs>
    <HardwareCost>14.99</HardwareCost>
    <RequestStatus>New Request</RequestStatus>
    <RejectionReason></RejectionReason>
</Request>

A form that uses this schema lets users make a single hardware selection. There are no nested or repeating elements, unlike the next XML structure.

<Request>
    <RequestID>f94a566d-1581-49bd-abf7-bcad68e8c0b3</RequestID>
    <RequestDate>2010-03-24</RequestDate>
    <Requestor>
        <DisplayName>Karen Berg</DisplayName>
        <Email>karenb@contoso.com</Email>
    </Requestor>
    <RequestorManager>
        <DisplayName>Holly Holt</DisplayName>
        <Email>hollyh@contoso.com</Email>
    </RequestorManager>
    <RequestedHardware>
        <HardwareItem>
            <HardwareType>Keyboard</HardwareType>
            <HardwareName>Coho Writer K9</HardwareName>
            <HardwareModel>CO K9 NOP</HardwareModel>
            <HardwareSpecs>Black, USB; Ergonomics Design; 104 Normal Keys; 9 Function Keys</HardwareSpecs>
            <HardwareCost>14.99</HardwareCost>
        </HardwareItem>
        <HardwareItem>
            <HardwareType>External Hard Drive</HardwareType>
            <HardwareName>Proseware BigStore</HardwareName>
            <HardwareModel>PRO LA33-3321</HardwareModel>
            <HardwareSpecs>USB 2.0 Interface; 5400 RPM; 80 GB Hard Drive; 2.5-inch Form Factor; WD Synchronization and Encryption</HardwareSpecs>
            <HardwareCost>96.99</HardwareCost>
        </HardwareItem>
    </RequestedHardware>
    <TotalCost>111.98</TotalCost>
    <RequestStatus>New Request</RequestStatus>
    <RejectionReason></RejectionReason>
</Request>

If your form has a simple, flat structure, as is the case with the former XML example, then a SharePoint list template is probably sufficient. Each individual XML element maps well to a single SharePoint column. By using the latter XML example, the user can select multiple hardware items, which will likely be displayed in a repeating table control in an InfoPath form. A SharePoint list form does not support nested or repeating elements. In this case, you would select the SharePoint form library template. This enables you to build a more complex data structure in the InfoPath designer.

Understanding the Storage Model

When you create a new field in a form you are designing with an InfoPathSharePoint List form template, you are creating a column in the SharePoint list associated with that form template. The "forms" that use that template then are stored as SharePoint list items, which therefore do not have an XML representation. Conversely, a form you create using an InfoPathSharePoint Form Library template is in fact an XML file will be stored in a SharePoint form library when you publish the form template. You can still map a field in a form library template to a SharePoint column. However, you must map each field individually using property promotion.

In some ways, the differences in storage models between the two form templates are minor. By using property promotion, you can have list view filters in a SharePoint form library, build conditional workflows, or even create key performance indicators based on form file data, much as you can with SharePoint list items. For repeating data in a form library template, you can promote only aggregate values.

Nevertheless, each template type has its own advantages. If the user has to edit many files or items, the SharePoint Datasheet View provides a quick means of modifying form data. In a SharePoint form library, you cannot edit a promoted field in the Datasheet View unless you configure the property when you publish the template. Because you must configure the property for each field that you promote, you may consider this additional step somewhat time-intensive. On the other hand, if you must send individual form data to someone outside your organization, a form file is much more portable than a SharePoint list item.

Adding Custom Code

You can extend the functionality of an InfoPath form created with the SharePoint form library template with custom code, written either in Visual Basic or C#. InfoPath 2010 includes Microsoft Visual Studio Tools for Applications, which lets you add custom event handlers and access the InfoPath object model and System.Xml with a streamlined Visual Studio IDE. Any custom code that you create is stored in a file. In turn, this file is packaged with the form template when the template is deployed. If your code does not access files and settings on the target computer, your form template can have a domain trust level. With domain-level trust, you can publish directly to a form library. However, if the custom code does have access to files and settings, the form template must be fully-trusted and uploaded to InfoPath Forms Services by a server administrator.

An InfoPath form created with the SharePoint list template does not support custom code. As a result, the more complex the SharePoint application is, the more likely that you will have to steer toward a SharePoint form library template.

Supporting an Offline Work Environment

Support for offline form data is available in two ways with InfoPath 2010. First, SharePoint lists can be taken offline with SharePoint Workspace, formerly known as Microsoft Office Groove, and then modified accordingly. InfoPath 2010 is the default editor in SharePoint Workspace for list items. Items in SharePoint Workspace can be re-synched as soon as a connection to the network is restored. For SharePoint form libraries, the user can open form files in the InfoPath filler. If the default save behavior has not been disabled in the template, the user can save form files to their computer and perform submit operations later when the network is restored.

With all considerations for selecting between a SharePoint list and form template being equal, if offline support were the only key business requirement in the SharePoint application, the correct choice might come down to whether SharePoint Workspace or the InfoPath filler is more prevalent among the users.

Ensuring Data Integrity with Digital Signatures

You can ensure the integrity of data in your SharePoint application by enabling digital signatures for one or more sections of an InfoPath form. A digital signature confirms that the form originated from the person who signed it and that the form has not since been modified. By using InfoPath digital signatures, you can decide to allow for only one signature for the form section, allow for multiple signatures that are independent of one another (co-signing), or allow for multiple signatures where each signature signs the preceding signature (counter-signing).

If your SharePoint application requires digital signatures, you must select the SharePoint form library template. SharePoint list forms do not support digital signatures.

Best Practices for InfoPath SharePoint Applications

Creating a SharePoint application that uses InfoPath 2010 involves many steps, many of which are performed in the designer. Regardless of the form template you select, you must build the main data source of the form. Additionally, depending on the scenario, you might add views for different user roles, include connections to external data sources, integrate with a SharePoint workflow, or even filter list controls that are based on certain user selections. This kind of functionality affects both the usability and performance of your form template: therefore, you should follow best practices whenever possible.

This section will provide guidance with regard to creating a SharePoint application by using InfoPath 2010. Obviously, this subject has many permutations. Therefore, this documentation cannot cover every aspect of a given scenario. Instead, this section is intended to draw attention to certain features, tips, and tricks that will optimize the SharePoint application.

Performance Considerations

As a general guideline in form template design, when you increase complexity, runtime performance may worsen. Complexity comes in different ways, such as declarative rules, conditional formatting, external data connections, and custom code. All of that logic must be processed at runtime, which affects how the form is rendered. This section offers several simple techniques that will help improve performance in your forms.

Form Views

InfoPath 2010 uses XSLT to transform the form's XML data source into editable HTML. Each form view in a template has its own associated .xsl file. From a performance perspective, it is better to have many form views (each with a small amount of business logic, such as conditional formatting) than a single view that contains all of the template's business logic. The XSLT transformation engine is taxed less if your .xsl file is not too complex.

SharePoint applications typically have multiple user roles. For example, in the hardware request scenario described in Building SharePoint Applications with InfoPath 2010 (Part 2 of 2) (MSDN refresh), any employee can start a hardware request. In turn, any approver, such as a manager, can approve or reject the request. In that scenario, there are at least two user roles: a requestor and an approver. Figure 2 shows how the form view might appear for the requestor, who can preview component information in the Hardware Information area before you add a component to the Requested Hardware repeating table. Once the requestor makes a request, the approver needs only a read-only view of the selected hardware, with an area to indicate a rejection reason, if applicable. Figure 3 shows the view for the approver.

Figure 2. Employee view for a hardware request

Requestor view for a hardware request

 

Figure 3. Approver view for a hardware request

Hardware request form approver view

If your form has multiple views, you can add a declarative rule to the Loading event that switches views depending on the value of a specific field. When using declarative logic to switch views automatically, you might want to consider modifying properties so that views do not appear in the View menu when a user is filling out the form. This will prevent the user from manually switching to a view reserved for a different role.

To prevent a view from appearing in the View menu

  1. In the ribbon, click the Page Design tab.

  2. In the Views group, click the View list and then click the applicable view name.

  3. Click Properties.

  4. In the Views group, click the View list and then click the applicable view name.

  5. In the View Properties dialog box, clear the Show on the View menu when filling out this form check box. (By default, this check box is selected.) Figure 4 shows the check box cleared.

    Figure 4. Preventing views from appearing on the View menu

    View Properties dialog box

  6. Click OK.

Data Connections

Multiple data connection queries in the Loading event of your form can adversely affect performance. This is especially true if your application retrieves large amount of data from those external sources. By default, InfoPath sets data connections to automatically retrieve data when the user opens a form. For each connection in your scenario, you should consider whether you can delay a data query until the user executes some event by filling out the form. For example, in a hardware request scenario, there may be manufacturer information that you choose to display for certain components. If this information is optional and is meant only to refine the hardware selection process, you can add a button control to the form view that includes a declarative action to query the external data source. When you create the data connection, verify that you clear the Automatically retrieve data when form is opened check box in the Data Connection Wizard, as shown in Figure 5.

Figure 5. Disabling the option to automatically retrieve data when the form is opened

Data connection wizard dialog box

Another consideration is to convert an external connection that stores static data into an XML file. You could then include the XML file as a resource file in the form template, which avoids the need for an external query. In a hardware request scenario, if you knew that component information would not change over time, you could move that data from the SharePoint list to an XML file such as the following.

<Components>
    <Component>
        <Type>Keyboard</Type>
        <Name>Coho Writer K9</Name>
        <Model>CO K9 NOP</Model>
        <Specs>Black, USB; Ergonomics Design; 104 Normal Keys; 9 Function Keys</Hardware>
        <Cost>14.99</Cost>
    </Component>
    <Component>
        <Type>External Hard Drive</Type>
        <Name>Proseware BigStore</Name>
        <Model>PRO LA33-3321</Model>
        <Specs>USB 2.0 Interface; 5400 RPM; 80 GB Hard Drive; 2.5-inch Form Factor; WD Synchronization and Encryption</Specs>
        <Cost>96.99</Cost>
    </Component>
</Components>

Controlling Server Postbacks

Most form controls have a postback setting that determines when a post to the server will occur. As with other declarative logic, frequent server posts that occur in a form will result in poorer performance. By default, a control's postback setting is Only when necessary for correct rendering of the form. If the data that was entered for a control never must be sent to the server, you should configure the setting for that control to Never.

To update the postback settings for a control

  1. Click the text box in the form view.

  2. In the ribbon, click the Properties tab.

  3. In the Properties group, click Control Properties.

  4. In the Text Box Properties dialog box, click the Browser forms tab.

  5. Click Never and then click OK. Figure 6 shows how the Text Box Properties dialog box may appear.

    Figure 6. Changing a control's postback settings

    Text Box Properties dialog box

Enabling List Filtering

Filtering is a declarative means of limiting options that are displayed in certain controls, such as drop-down list boxes. The filtering feature in the InfoPath designer enables you to have a cascading set of drop-down list boxes. When a user selects a list option, that selection affects the options that are shown in a related drop-down list. For example, in a hardware request scenario, you could have a drop-down list for the hardware type, such as an external hard disk drive, keyboard, or mouse. A second drop-down list for models would show only the model numbers associated with the selected hardware type. Then, when a user selects a model number, you could use declarative rules to set corresponding fields in the form (for example, the hardware cost).

There are known performance issues with cascading drop-down list boxes in a repeating table control. In Building SharePoint Applications with InfoPath 2010 (Part 2 of 2) (MSDN refresh), there is a set of steps that shows how you can efficiently incorporate cascading list functionality into a form template that uses a repeating table.

Adding User Information to a Form

In the SharePoint application, if email messages are sent to a user or tasks are assigned by a SharePoint workflow, your form must include that user information.

Whether you are trying to determine the form initiator or gather information about approvers, reviewers, or other roles for your scenario, InfoPath 2010 offers two common approaches for adding user profile data into a form:

  • Person/group picker control

  • User Profile Service

Person/Group Picker Control

The easiest way to put user information into your form is to use the person/group picker input control. For a form template that is published to a SharePoint Server, this control lets a user select any authenticated user. When you add the control to a form view, the data source will include a nested structure for identifying the display name, account ID, and account type of the user, as shown in Figure 7.

Figure 7. Data source for the person/group picker control

Data source for the person/group picker control

The DisplayName field stores the name that is shown within the control when the user clicks the Check names icon. The AccountID field stores the account name (domain and user name) of the selected user (for example, CONTOSO\brads). If your form template integrates with a workflow, you can promote the AccountID field as a SharePoint column and use AccountID for routing tasks or email messages. Meanwhile, the AccountType field identifies whether the user selected an individual or group account. AccountType is User when an individual is selected, and is SecurityGroup when a group is selected.

User Profile Service

Office SharePoint Server 2010 includes the User Profile Service, a web service that contains several operations for integrating with your organization's Active Directory service. One operation in particular, GetUserProfileByName(String), enables you to pass an account name parameter to retrieve corresponding profile information. If you leave GetUserProfileByName blank when you make a query, the web service returns profile information for the current user. The default location for the web service is http://Web application/_vti_bin/userprofileservice.asmx. Figure 8 shows the URL being entered in the Data Connection Wizard.

Figure 8. Entering the User Profile Service URL in the Data Connection Wizard

Data Connection Wizard

When you query the User Profile Service, the service returns profile information in repeating PropertyData nodes in the secondary data source. The nested Name field stores the name of the property. The corresponding value is contained in the Value field, located within the ValueData node, a child of the Values node. Figure 9 shows the secondary data source associated with the User Profile Service.

Figure 9. Data source for the User Profile Service

Data source for the User Profile Service

Once you make a query, you can use a declarative rule to set user fields in the main data source of the form, based on the returned property values. You could bind the user field to a person/group picker, text box, or some other control. Typically, the most common properties that you would use in a SharePoint application are as follows:

  • PreferredName — Display name of the user

  • AccountName — Account name of the user

  • WorkEmail — Email address of the user

  • Manager — Account name of the user's manager

In Building SharePoint Applications with InfoPath 2010 (Part 2 of 2) (MSDN refresh), there are steps that show how to retrieve current user and manager profile information from the User Profile Service.

Workflow Considerations

When you design a SharePoint list template, all fields in the form are SharePoint columns. Therefore, the columns are available to external processes such as workflows. By default, a field in a SharePoint form library template is not available as a SharePoint column. Any fields in a library template that your workflow evaluates must be promoted as a SharePoint column. When you publish the form template, SharePoint will create a SharePoint column for each field that you promote. If you publish the form template as a site content type, SharePoint will make the promoted fields available within reusable workflows. In Building SharePoint Applications with InfoPath 2010 (Part 2 of 2) (MSDN refresh), there are steps that show how to build a reusable SharePoint Designer workflow for a form template that was published as a site content type.

To promote a field in a SharePoint form library template

  1. In the ribbon, click the File tab.

  2. In the Info area, click Form Options.

  3. In the Form Options dialog box, click the Property Promotion category.

  4. In the Column Name area, click Add.

  5. In the Select a Field or Group dialog box, click a node.

  6. In the Column name box, set the name of the SharePoint column for the selected field. Figure 10 shows an example of a field being promoted.

    Figure 10. Promoting fields as SharePoint columns

    Select a Field or Group dialog box

  7. Click OK.

  8. In the Form Options dialog box, click OK.

Any repeating node in the form template that is promoted as a SharePoint column has aggregate functions associated with it. For example, in the hardware request scenario, if you were to promote the HardwareCost node that is nested in the repeating HardwareItem group, you could use one of the following functions:

  • First — Promotes the first occurrence of the node

  • Last — Promotes the last occurrence of the node

  • Count — Promotes the total number of the nodes

  • Merge — Promotes a concatenation of all the node values

Note

A promoted column is, by default, read-only to external processes such as a workflow. To enable editing for a promoted column, you must configure the column properties at the time that you publish the form template.

Security and Trust

Every InfoPath form library template has a security level, which essentially defines the level of trust granted to certain features and any code running in the form. The security trust levels are as follows:

  • Restricted — The form cannot access content outside the form. Any data connections used must be embedded as resource files in the template.

  • Domain — The form can access content from the domain in which the form is located. The form can use custom code as long as the code does not access files and settings on a user's computer.

  • Full Trust — The form has access to files and settings on the computer. For a fully-trusted form to run in the InfoPath filler, you must install or digitally sign the form with a certificate.

By default, the InfoPath designer will automatically determine the security level of the form template. In most cases, the security level is either domain or full trust. (Restricted trust is used when forms are published by email.) If your form template contains code that performs actions such as reading a registry key entry, the template will require the full trust security level. Additionally, external connections that retrieve data directly from a SQL Server database, or from sources that are located in a different SharePoint site collection or a file share, will result in the form template having a full trust security level.

Try to keep the security level of your template at the domain level. Having domain-level security will make the solution more user-friendly and ease maintenance for the form developer. Certainly, you may not be able to avoid needing full trust, especially if the form requires custom code that accesses user settings,. However, you can convert an external connection that retrieves data from outside the domain (such as a database) into a Universal Data Connection (UDC) file, which stores connection information. You can then store the UDC file in a data connection library that resides in the same domain in which you publish form template. You can then access the UDC file exactly like any other data connection. But because the UDC file is in a trusted location, you have changed the form template's security to the domain level.

To convert a data connection into a UDC file and then add it to an existing data connection library

  1. In the ribbon, click the Data tab.

  2. In the Get External Data group, click Data Connections.

  3. In the Data Connections dialog box, click the applicable data connection and then click Convert to Connection File.

  4. In the Convert Data Connection dialog box, specify the URL for the new UDC file (a .udcx file), which will be stored in an existing data connection library. Figure 11 shows a sample URL for a new UDC file.

    Figure 11. Converting a data connection to a UDC file

    Convert Data Connection dialog box

  5. Click OK.

  6. In the Data Connections dialog box, click Close.

    Note

    By default, UDC files that are created from the InfoPath designer will have an Approval Status set to Pending in the data connection library. To use these data connections within forms, the files in the data connection library must be approved.

Form Submission

To let a user submit form a file to a library, web service, or some other location, you must enable the submit functionality in the form template. On the Data tab in the ribbon, you can click Submit Options to enable submit operations. You can also define the submit data connection that the form template will use. When creating the data connection, you must define the naming convention for form files in the Data Connection Wizard. Typically, you would concatenate form fields and possibly include a time stamp in your naming convention. If your solution includes a SharePoint workflow, you can have your workflow define the naming convention by using the Document ID Service. The Document ID Service, which is enabled at the site collection level, assigns unique IDs to items in lists and libraries throughout the site collection. Building SharePoint Applications with InfoPath 2010 (Part 2 of 2) (MSDN refresh) describes how to include logic in a workflow that sets a file name based on a generated document ID.

To enable the Document ID Service

  1. In the browser, browse to the SharePoint Site Settings page.

  2. In the Site Collection Administration area, click Site collection features.

  3. Check the Status value for the Document ID Service. If the value does not equal Active, click Activate. Figure 12 shows the service that is running.

    Figure 12. Checking the status of the Document ID Service

    Site collection features area

    Note

    You can schedule a timer job to assign IDs to items already in the site collection. You can also configure document ID settings from the Site Collection Administration area of the Site Settings page by clicking Document ID settings.

Conclusion

Part one of this article described some best practices for building a SharePoint application by using InfoPath 2010. In part two of this article, you will walk through building a sample hardware request scenario. The InfoPath designer provides most of the functionality that you can use in a form template without the need for custom code. Such functionality includes connections to external data sources, list filtering, submit operations, and more. You can also extend form functionality with custom code written in Visual Basic or C# by using Visual Studio Tools for Applications, which is included with InfoPath 2010. You can combine an InfoPath form template with a SharePoint Designer workflow, which uses conditional actions to perform operations such as assigning tasks, sending email messages, setting form field values, and much more. By using InfoPath 2010 and SharePoint Designer together offers lots of declarative logic that lets you build rich SharePoint applications.

Additional Resources

For more information, see the following resources:

About the Author

David Gerhardt manages a team at 3Sharp that develops solutions for clients using Microsoft SharePoint offerings and Office client applications. David has consulted with customers since the mid-‘90s and especially enjoys XML-related technologies. Since 2003, he has done lots of work with Microsoft InfoPath and authored the Developing InfoPath 2007 Managed-Code Solutions and Best Practices for Deploying InfoPath 2007 Form Templates to a Production Environment white papers. He also co-authored the book Building Content Type Solutions in SharePoint 2007 and has a blog site at http://blogs.3sharp.com/davidg.