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

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

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.

XML

    f94a566d-1581-49bd-abf7-bcad68e8c0b3
    2010-03-24
    Karen Berg
    Holly Holt
    Keyboard
    Coho Writer K9
    CO K9 NOP
    Black, USB; Ergonomics Design; 104 Normal Keys; 9 Function Keys
    14.99
    New 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.

XML

    f94a566d-1581-49bd-abf7-bcad68e8c0b3
    2010-03-24
    
        Karen Berg
        karenb@contoso.com
    
    
        Holly Holt
        hollyh@contoso.com
    
    
        
            Keyboard
            Coho Writer K9
            CO K9 NOP
            Black, USB; Ergonomics Design; 104 Normal Keys; 9 Function Keys
            14.99
        
        
            External Hard Drive
            Proseware BigStore
            PRO LA33-3321
            USB 2.0 Interface; 5400 RPM; 80 GB Hard Drive; 2.5-inch Form Factor; WD Synchronization and Encryption
            96.99
        
    
    111.98
    New 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

Figure 3. Approver view for a hardware request

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
   
   
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

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.

XML

    
        Keyboard
        Coho Writer K9
        CO K9 NOP
        Black, USB; Ergonomics Design; 104 Normal Keys; 9 Function Keys

14.99 External Hard Drive Proseware BigStore PRO LA33-3321 USB 2.0 Interface; 5400 RPM; 80 GB Hard Drive; 2.5-inch Form Factor; WD Synchronization and Encryption 96.99

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
   
   

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

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

When you query the User Profile Service, the service returns profile information in repeating PropertyData nodes in the secondary data source. The nested Namefield 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

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
   
   
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
   
   
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
   
   

   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.

SharePoint Application Walkthrough
Conclusion
Additional Resources
About the Author 

Published:  October 2010 | Updated:  September 2011

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

Contents

• SharePoint Application Walkthrough
• Conclusion
• Additional Resources

   Download code

SharePoint Application Walkthrough

Now that you are familiar with some best practices in creating a SharePoint application that uses InfoPath 2010, it is time to apply what you have learned. This section is a walkthrough for a simple hardware request solution. In this scenario, the user fills out a request for one or more hardware components. The form template that is used identifies the requestor and an approver. By default, the approver is the requestor's manager. However, the requestor can select a different approver if they know that the manager will be unavailable. The requestor submits the form, which then triggers a workflow. In turn, the workflow notifies the approver that a new hardware request was submitted. For this walkthrough, you will design a form template, publish the template to a SharePoint Server, and then build a SharePoint Designer workflow that notifies the approver accordingly.

Important
The SharePoint application and code described in this article will not work if SharePoint is configured for forms-based authentication. To work correctly, the web application that hosts this SharePoint application must be configured to use classic-mode authentication. For more information about configuring SharePoint authentication, see Plan authentication methods (SharePoint Server 2010).

Designing a Form Template

Because the form allows the user to select multiple hardware components, and because you will use custom code, this example will show you the design of a SharePoint form library template. In the interest of time, you start with an existing form template named Hardware Request.xsn. This template already includes some controls, declarative rules, data connections, form views, and other functionality. Having this functionality to start with allows you to focus on some design techniques from the previous section. All code samples shown in this section will be created in C#.

Including User Information

A form template deployed to Office SharePoint Server 2010 can use the built-in User Profile Service, a web service that reads profile information from Active Directory. In the hardware request scenario, the form template will identify user information for the requestor and the approver. By default, the approver is the requestor's manager. You will create a connection to the web service to retrieve user profile information.

To include a connection for this web service in your form template

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 Add.
4. In the Data Connection Wizard, click Create a new connection to, click Receive data, and then click Next.
5. In the next page of the wizard, click SOAP web service and then click Next.
6. In the next page, type the location of the User Profile Service and then click Next. The default location for the web service is http://Web application/_vti_bin/userprofileservice.asmx.
7. In the next page, click the GetUserProfileByName operation and then click Next. Figure 1 shows the operation selected in the wizard.
   Figure 1. Selecting the GetUserProfileByName operation in the wizard
   
   
8. In the next page, click Next.
9. In the next page, click Next.
10. In the last page, clear the Automatically retrieve data when form is opened check box and then click Finish.
11. In the Data Connections dialog box, click Close.

Adding the User Profile Service as an external connection to the form template pulls user information into a secondary data source. The next step is to add logic that populates the requestor and requestor manager nodes in the main data source of the form. Adding this logic allows a SharePoint workflow to send notification messages accordingly. This logic can be addressed declaratively in the E:Microsoft.Office.InfoPath.FormEvents.Loading event of the form. First, you must add the profile information for the requestor. Be aware that the form file will be opened by multiple users. Therefore, you do not want the requestor nodes updated every time a user opens the form. You can add conditional logic that sets the requestor nodes only if they are already blank. In this scenario, if the nodes are blank, you can assume that the user is starting a new request.

To set the conditional logic for the user information

1. In the ribbon, click the Data tab.
2. In the Rules group, click Form Load.
3. In the Rules task pane, click the New list and then click Action.
4. Below the Condition header, click None - Rule runs when form is opened.
5. In the Condition dialog box, click the first list and then click Select a field or group.
6. In the Select a Field or Group dialog box, expand the Requestor group node and then the pc:Person group node, as shown in Figure 2.
   Figure 2. Locating the requestor nodes in the data source
   
   
7. Click the AccountId node and then click OK.
8. In the Condition dialog box, click the second list and then click is blank. The Condition dialog box appears as shown in Figure 3.
   Figure 3. Setting conditional logic for the user information
   
   
9. Click OK.

Once you have created the condition, you can now start adding declarative actions for your rule. If you recall when you created the connection to the User Profile Service, you cleared the Automatically retrieve data when form is opened check box. So, the first action that you will create is a query for that connection. If you do not pass a parameter to the User Profile Service, the profile information that is returned is for the current user, which is the outcome that you want for a new request.

To create an action that queries the User Profile Service

1. In the Rules task pane, click the Add list and then click Query for data.
2. In the Rule Details dialog box, click the Data connection list and then click GetUserProfileByName, as shown in Figure 4.
   Figure 4. Querying the User Profile Service
   
   
3. Click OK.

To get the account name and display name of the current user, you will have to dig into the GetUserProfileByName secondary data source. In this case, the nested property values are named AccountName and PreferredName. You will grab the associated values for those properties and use the AccountName value for AccountID, and the PreferredName value for DisplayName, for the requestor in the main data source.

To add logic that sets the requestor user information

1. In the Rules task pane, click the Add list and then click Set a field's value.
2. In the Rule Details dialog box, click the Select a Field or Group button, located to the right side of the Field box.
3. In the Select a Field or Group dialog box, expand the Requestor group node and then expand the pc:Person group node.
4. Click the AccountId node and then click OK.
5. In the Rule Details dialog box, click the Insert Formula button, located to the right side of the Value box.
6. In the Insert Formula dialog box, click Insert Field or Group.
7. In the Select a Field or Group dialog box, click the Fields list and then click GetUserProfileByName (Secondary).
8. Expand dataFields, tns:GetUserProfileByNameResponse, GetUserProfileByNameResult, PropertyData, Values, ValueData, as shown in Figure 5.
   Figure 5. Navigating to the nested property value
   
   
9. Click the Value node and then click Filter Data.
10. In the Filter Data dialog box, click Add.
11. In the Specify Filter Conditions dialog box, click the first list and then click Select a field or group.
12. In the Select a Field or Group dialog box, click the Name node, which is nested directly in the PropertyData group, and then click OK.
13. In the Specify Filter Conditions dialog box, click the third list and then click Type text.
14. Type AccountName and then press TAB. The Specify Filter Conditions dialog box appears as shown in Figure 6.
    Figure 6. Filtering the property value
    
    
15. Click OK until all dialog boxes have been closed.
16. To add the requestor's display name to the main data source, repeat Steps 1-15, but click the DisplayName node in Step 4 and change AccountName toPreferredName in Step 14.

Adding information about the manager of the requestor requires some additional actions during the E:Microsoft.Office.InfoPath.FormEvents.Loading event. First, you must re-query the User Profile Service, passing the account name of the manager as a parameter. You can retrieve the account name from the current user's manager property, in this case Manager.

To re-query the User Profile Service for manager information

1. In the Rules task pane, click the Add list and then click Set a field's value.
2. In the Rule Details dialog box, click the Select a Field or Group button, located to the right side of the Field box.
3. In the Select a Field or Group dialog box, click the Fields list and then click GetUserProfileByName (Secondary).
4. Expand queryFields and then tns:GetUserProfileByName, as shown in Figure 7.
   Figure 7. Navigating to the query parameter node
   
   
5. Click the AccountName node and then click OK.
6. In the Rule Details dialog box, click the Insert Formula button, located to the right side of the Value box.
7. In the Insert Formula dialog box, click Insert Field or Group.
8. In the Select a Field or Group dialog box, click the Fields list and then click GetUserProfileByName (Secondary).
9. Expand dataFields, tns:GetUserProfileByNameResponse, GetUserProfileByNameResult, PropertyData, Values, ValueData.
10. Click the Value node and then click Filter Data.
11. In the Filter Data dialog box, click Add.
12. In the Specify Filter Conditions dialog box, click the first list and then click Select a field or group.
13. In the Select a Field or Group dialog box, click the Name node, which is nested directly in the PropertyData group, and then click OK.
14. In the Specify Filter Conditions dialog box, click the third list and then click Type text.
15. Type Manager.
16. Click OK until all dialog boxes have been closed.
17. In the Rules task pane, click the Add list and then click Query for data.
18. In the Rule Details dialog box, click the Data connection list, click GetUserProfileByName, and then click OK.

After you query the User Profile Service with the requestor Manager property value, you can then set the approver node fields in the main data source. This is a similar process to what was done for the requestor nodes.

To add logic that sets the approver fields in the form's main data source with the requestor's manager information

1. In the Rules task pane, click the Add list and then click Set a field's value.
2. In the Rule Details dialog box, click the Select a Field or Group button, located to the right side of the Field box.
3. In the Select a Field or Group dialog box, expand the Approver group node and then expand the pc:Person group node.
4. Click the AccountId node and then click OK.
5. In the Rule Details dialog box, click the Insert Formula button, located to the right side of the Value box.
6. In the Insert Formula dialog box, click Insert Field or Group.
7. In the Select a Field or Group dialog box, click the Fields list and then click GetUserProfileByName (Secondary).
8. Expand dataFields, tns:GetUserProfileByNameResponse, GetUserProfileByNameResult, PropertyData, Values, ValueData.
9. Click the Value node and then click Filter Data.
10. In the Filter Data dialog box, click Add.
11. In the Specify Filter Conditions dialog box, click the first list and then click Select a field or group.
12. In the Select a Field or Group dialog box, click the Name node, which is nested directly in the PropertyData group, and then click OK.
13. In the Specify Filter Conditions dialog box, click the third list and then click Type text.
14. Type AccountName and then click OK until all dialog boxes have been closed.
15. To add the approver's display name to the main data source, repeat Steps 1-14, but click the DisplayName node in Step 4 and change AccountName toPreferredName in Step 14.

Adding List Filtering

In the hardware request form, the requestor previews component information in the Hardware Information area before the form adds items to the Requested Hardware repeating table. First, the requestor uses the Hardware Type list to determine whether the needed item is a laptop, keyboard, or some other hardware item. After the requestor selects the hardware type, , the form filters the Model list to show only options that apply to the selected type. As was discussed earlier in the Best Practices section, these kinds of cascading drop-down list boxes can hamper form performance when inside repeating table controls. Therefore, this creates the need for a preview area. In the section that follows this one, you can examine code that adds items in the preview area to the repeating table.

The controls in the preview area are bound to nodes in the Preview group of the main data source. The Hardware Type drop-down list already pulls the hardware values from the Components secondary data source. For the Model drop-down list, you must add a filter that retrieves only the model numbers where the corresponding hardware type is equal to the selected hardware type in the form.

To add filtering for the Model drop-down list

1. Click the Model drop-down list in the form view.
2. In the ribbon, click the Properties tab.
3. In the Properties group, click Control Properties.
4. In the Drop-Down List Box Properties dialog box, click Get choices from an external data source.
5. Click the Data source list and then click Components.
6. Click the Select XPath button that is located to the right side of the Entries box.
7. In the Select a Field or Group dialog box, click the Component node and then click Filter Data.
8. In the Filter Data dialog box, click Add.
9. In the Specify Filter Conditions dialog box, click the first list and then click Type.
10. Click the third list and then click Select a field or group.
11. In the Select a Field or Group dialog box, click the Fields list and then click Main.
12. Expand the Preview node, click the HardwareType node, and then click OK. The Specify Filter Conditions dialog box appears as shown in Figure 8.
    Figure 8. Filtering the Model list
    
    
13. Click OK in all dialog boxes until you return to the Drop-Down List Box Properties dialog box.
14. Click the Select XPath button that is located to the right side of the Value box.
15. In the Select a Field or Group dialog box, click the Model node and then click OK.
16. Click the Select XPath button that is located to the right side of the Display name box.
17. In the Select a Field or Group dialog box, click the Model node and then click OK.
18. In the Drop-Down List Box Properties dialog box, click OK.

You now have cascading lists in your form view. The next step is to add logic that sets the corresponding Name, Cost, and Specs fields in the preview area. You add this logic using a declarative rule.

To add the logic that sets the component detail information

1. Click the Model drop-down list in the form view.
2. In the Rules task pane, click the New list and then click Action.
3. Click the Add list and then click Set a field's value.
4. In the Rule Details dialog box, click the Select a Field or Group button, located to the right side of the Field box.
5. In the Select a Field or Group dialog box, within the Preview group, click the HardwareName node and then click OK.
6. In the Rule Details dialog box, click the Insert Formula button, located to the right side of the Value box.
7. In the Insert Formula dialog box, click Insert Field or Group.
8. In the Select a Field or Group dialog box, click the Fields list and then click Components (Secondary).
9. Expand Component, click the Name node, and then click Filter Data.
10. In the Filter Data dialog box, click Add.
11. In the Specify Filter Conditions dialog box, click the first list and then click Model.
12. Click the third list and then click Select a field or group.
13. In the Select a Field or Group dialog box, click the Fields list and then click Main.
14. Expand the Preview group, click the HardwareModel node, and then click OK. The Specify Filter Conditions dialog box appears as shown in Figure 9.
    Figure 9. Filtering the hardware component details
    
    
15. Click OK until all dialog boxes have been closed.
16. To set the Cost and Specs fields, repeat Steps 3-15 separately. For the Cost field, click the HardwareCost node in Step 5 and then click the Cost node in Step 9. For the Specs field, click the HardwareSpecs node in Step 5 and then click the Specs node in Step 9.

Programmatically Manipulating the Data Source

Even very simple InfoPath form templates may require some lines of custom code. By using form templates that are used in browser scenarios, you have the choice of developing in Visual Basic or C#. InfoPath 2010 includes Visual Studio Tools for Applications, a streamlined Visual Studio IDE that lets you program to the event handlers in the form with either of those two languages. If a user takes a form that has custom code offline in the InfoPath filler, the .NET Framework (version 3.5 or earlier) must be running on that computer.

In the hardware request scenario, the user will first preview a component in the Hardware Information area of the form view before they add it to theRequested Hardware repeating table. The repeating table control is bound to the HardwareItem repeating main data source node, which is nested in theRequestedHardware group node. Each HardwareItem node contains a nested HardwareSelected, HardwareType, HardwareModel, and HardwareCost, all of which are displayed in the form view. The footer of the repeating table contains a single text box that sums the HardwareCost values.

Adding a hardware component to the Requested Hardware table programmatically requires an event. For this scenario, you will associate aE:Microsoft.Office.InfoPath.ButtonEvent.Clicked event handler with the Add to Requested Hardware Table button control. For end-users, this control will be disabled until a Model value is specified in the preview area.

To start Visual Studio Tools for Applications and add the Clicked event handler

1. Click the Add to Requested Hardware Table button control in the form view.
2. In the ribbon, click the Properties tab.
3. In the Button group, click Custom Code.

By default, a new form file has one blank row in the Requested Hardware repeating table. Blank rows must be removed from the table. Therefore, you start by adding code that deletes the default row. In Visual Studio Tools for Applications, within the Btn_AddHardware_Clicked procedure, add the following code.

C#

XPathNavigator selectedHardware = MainDataSource.CreateNavigator().SelectSingleNode("//my:RequestedHardware", NamespaceManager);
XPathNodeIterator hardwareItems = selectedHardware.Select("./my:HardwareItem", NamespaceManager);
if (hardwareItems.Count == 1 && selectedHardware.SelectSingleNode("./my:HardwareItem/my:HardwareType", NamespaceManager).InnerXml == string.Empty)
{
    XPathNodeIterator childNodes = selectedHardware.CreateNavigator().Select("*", NamespaceManager);
    for (int i = childNodes.Count - 1; i >= 0; i--)
    {
        XPathNavigator childNode = selectedHardware.CreateNavigator().SelectSingleNode("*[last()]", NamespaceManager);
        childNode.DeleteSelf();
    }
}

After you remove the default row, you can then add the code that creates a new HardwareItem row in the RequestedHardware group. The HardwareType,HardwareModel, and HardwareCost values are set based on the Model selected by the user. Immediately after the code that you previously added, within theBtn_AddHardware_Clicked procedure, add the following code.

C#

selectedHardware.AppendChildElement("my", "HardwareItem", selectedHardware.LookupNamespace(selectedHardware.Prefix), "");
XPathNavigator newItem = selectedHardware.SelectSingleNode("*[last()]", NamespaceManager);
newItem.AppendChildElement("my", "HardwareSelected", newItem.LookupNamespace(newItem.Prefix), "");
newItem.AppendChildElement("my", "HardwareType", newItem.LookupNamespace(newItem.Prefix), "");
newItem.AppendChildElement("my", "HardwareModel", newItem.LookupNamespace(newItem.Prefix), "");
newItem.AppendChildElement("my", "HardwareCost", newItem.LookupNamespace(newItem.Prefix), "");
newItem.SelectSingleNode("my:HardwareSelected", NamespaceManager).SetValue("false");
newItem.SelectSingleNode("my:HardwareType", NamespaceManager).SetValue(MainDataSource.CreateNavigator().SelectSingleNode("//my:Preview/my:HardwareType", NamespaceManager).InnerXml);
newItem.SelectSingleNode("my:HardwareModel", NamespaceManager).SetValue(MainDataSource.CreateNavigator().SelectSingleNode("//my:Preview/my:HardwareModel", NamespaceManager).InnerXml);
newItem.SelectSingleNode("my:HardwareCost", NamespaceManager).SetValue(MainDataSource.CreateNavigator().SelectSingleNode("//my:Preview/my:HardwareCost", NamespaceManager).InnerXml);

From a code perspective, the final thing that you will want to do for the Add to Requested Hardware Table button control is clear the detail fields in the preview section. Because you have a rule that sets the Name, Cost, and Specs fields based on the Model selection, you have only to clear the Model field. The three previously mentioned fields will then have empty values because of the declarative rule for the Model drop-down list. Optionally, you could also clear theHardwareType field, although the user may find it easier to add multiple items of the same type if this field is left alone. Immediately after the code that you previously added, within the Btn_AddHardware_Clicked procedure, add the following code.

C#

MainDataSource.CreateNavigator().SelectSingleNode("//my:Preview/my:HardwareModel", NamespaceManager).SetValue(string.Empty);

To remove an item from the Requested Hardware table, users can select that item's check box, bound to the HardwareSelected node, and then click theRemove from Requested Hardware Table button. Once again, a E:Microsoft.Office.InfoPath.ButtonEvent.Clicked event handler will be associated with the button control.

To add the Clicked event handler

1. In the InfoPath designer, click the Remove from Requested Hardware Table button control.
2. In the ribbon, click the Properties tab.
3. In the Button group, click Custom Code.

With the event handler installed, you will add code that removes all HardwareItem nodes where the nested HardwareSelected node is set to true, which indicates a selected item. When you programmatically added the HardwareItem node earlier, the HardwareSelected node was set to false (cleared). TheRemove from Requested Hardware Table button is disabled until at least one item in the Requested Hardware table is selected. In Visual Studio Tools for Applications, within the Btn_RemoveHardware_Clicked procedure, add the following code.

C#

XPathNavigator selectedHardware = MainDataSource.CreateNavigator().SelectSingleNode("//my:RequestedHardware", NamespaceManager);
XPathNodeIterator hardwareItems = selectedHardware.Select("./my:HardwareItem", NamespaceManager);
if (hardwareItems.Count > 0)
{
    for (int i = hardwareItems.Count - 1; i >= 0; i--)
    {
        int position = i + 1;
        XPathNavigator hardwareItem = selectedHardware.CreateNavigator().SelectSingleNode("my:HardwareItem[position() = " + position + "]", NamespaceManager);
        if (hardwareItem.SelectSingleNode("my:HardwareSelected", NamespaceManager).InnerXml == "true")
        {
            hardwareItem.DeleteSelf();
        }
    }
}

Enabling Submit Functionality

After filling out the hardware request form, the requestor will submit the form data to a SharePoint form library. You will have to enable submit functionality in the form template and specify the location of the form library (including the form file name) in a data connection. As was discussed in the Best Practices section, file names can be based on document IDs. These names are generated by a service, and are guaranteed to be unique across a SharePoint site collection. When you build the workflow for this solution later, you will include a step to set the form file name to the document ID. For now, the file name can be based on the hiddenRequestID node. By default, the name is a concatenation of the requestor display name and the time that the user opens the form. When creating the submit data connection, the wizard validates SharePoint library URLs. Therefore, you must specify an existing form library.

To enable submit functionality for the form template

1. In the InfoPath designer, in the ribbon, click the Data tab.
2. In the Submit Form group, click Submit Options.
3. In the Submit Options dialog box, select the Allow users to submit this form check box.
4. Click the Send form data to a single destination list and then click SharePoint document library.
5. Click Add.
6. In the first page of the Data Connection Wizard, in the Document library box, type the URL for the existing form library.
7. Click the Insert Formula button, located to the right side of the File name box.
8. In the Insert Formula box, click Insert Field or Group.
9. In the Select a Field or Group dialog box, click the RequestID node and then click OK.
10. In the Insert Formula dialog box, click OK.
11. In the wizard, select the Allow overwrite if file exists check box. Figure 10 shows how the wizard appears.
    Figure 10. Specifying the library and file name for submitted forms
    
    
12. Click Next.
13. In the last page of the wizard, click Finish. The Submit Options dialog box appears as shown in Figure 11.
    Figure 11. Enabling submit options in the form template
    
    
14. Click OK.

A new form file that is submitted by the requestor will have its RequestStatus node set to New Request. When the form is then opened by the approver, a declarative rule in the E:Microsoft.Office.InfoPath.FormEvents.Loading event switches to the Approver view, which displays the Requested Hardware table and has button controls for approving or rejecting the form. The button controls are hidden if the RequestStatus node value is Approved or Rejected, and theReject button control is disabled unless the approver enters a Rejection Reason. You will add declarative logic to both button controls that sets theRequestStatus node accordingly and then submits the form file back to the form library.

To add the submit functionality for the Approve and Reject button controls

1. In the ribbon, click the Page Design tab.
2. In the Views group, click the View list and then click Approver.
3. Click the Approve button control in the form view.
4. In the Rules task pane, click the New list and then click Action.
5. Click the Add list and then click Set a field's value.
6. In the Rule Details dialog box, click the Select a Field or Group button, located to the right side of the Field box.
7. In the Select a Field or Group dialog box, click the RequestStatus node and then click OK.
8. In the Value box, type Approved, as shown in Figure 12.
   Figure 12. Changing the RequestStatus value
   
   
9. Click OK.
10. In the Rules task pane, click the Add list and then click Submit data.
11. In the Rule Details dialog box, click OK.
12. In the Rules task pane, click the Add list and then click Close the form.
13. In the Rule Details dialog box, click OK.
14. To set the submit functionality for the Reject button control, repeat Steps 3-13, but click the Reject button control in Step 3 and change Approved toRejected in Step 8.

Deploying a Form Template

If your form library template has no custom code or external connections accessing data outside the domain of the template, you can publish the template directly to a SharePoint form library or as a site content type. Your template may have domain-level data connections but also use custom code. If this is the case, you can still publish the form directly to SharePoint as a sandboxed solution, but only if the code does not access files or settings on target computers. In those instances, SharePoint Server must be running the Microsoft SharePoint Foundation Sandboxed Code Service. In cases in which your form template has non-domain-level data connections or contains code that accesses files or settings on the target computer, your template must be administrator-deployed. In other words, you would have to publish your template to a network, and then hand your template off to a SharePoint Server administrator. The server administrator would then upload your template to InfoPath Forms Services, and then activate it to a site collection. Libraries within that site collection that had content types enabled could then reference your form template.

In the hardware request scenario, the form template contains only domain-level data connections, and the custom code does not access files or settings on the target computer. As a result, you can publish the template as a sandboxed solution. However, before you run the Publishing Wizard, confirm that the Microsoft SharePoint Foundation Sandboxed Code Service is running.

To verify that the service is started on the SharePoint server

1. Start SharePoint 2010 Central Administration.
2. On the home page, in the System Settings area, click Manage services on server.
3. Check the Status value for the Microsoft SharePoint Foundation Sandboxed Code Service. If the value equals Stopped, click the Start action. Figure 13 shows the service that is running.
   Figure 13. Checking the status of the user code service
   
   
   If the service is running on the SharePoint Server, you can publish the hardware request form template as a sandboxed solution. In this case, you will publish it as a site content type so that it can be used across libraries and associated with reusable SharePoint Designer workflows. The form template already has key fields in the form set to be promoted as SharePoint columns so that you can merely run the Publishing Wizard. Because the SharePoint workflow that is attached to the library will set the RequestID field to the document ID that is generated, you must configure the properties for that field so that it can be edited by the workflow.
4. In the ribbon, click the File tab to enter the backstage.
5. In the area to the left, click Publish.
6. Click SharePoint Server.
7. In the first page of the Publishing Wizard, type the URL for the SharePoint site that will host your form library. Figure 14 shows an example of a SharePoint site URL.
   Figure 14. Specifying the SharePoint site for a sandboxed solution
   
   
8. Click Next.
9. In the next page of the wizard, click Site Content Type (advanced) and then click Next.
10. In the next page, click Create a new content type and then click Next.
11. In the next page, type a name for the content type in the Name box (for example, Hardware Request) and then click Next.
12. In the next page, in the Specify a location and file name for the form template box, type the location and file name for the form template on the SharePoint site and then click Next. Figure 15 shows an example of a URL that include the form template name.
    Figure 15. Specifying the location and file name for the form template
    
    
13. In the next page, click the Request ID column and then click Modify.
14. In the Select a Field or Group dialog box, select the Allow users to configure data in this field by using a datasheet or properties page check box and then click OK.
15. In the wizard, click Next.
16. In the next page, click Publish.
17. In the last page, click Close.

Once you have published a form template, it is fairly easy to re-deploy a modified template later on. InfoPath 2010 uses one-click deployment for any form template that has a defined publish location. One-click deployment saves you from having to navigate through the Publishing Wizard every time you want to re-deploy a form template to a library.

To redeploy the hardware request form template

1. In the Quick Access Toolbar at the top, click the Quick Publish icon.
2. In the message box indicating that the form was successfully published, click OK.

Building a SharePoint Workflow

The other major component of the hardware request solution is a SharePoint Designer workflow that is associated with the form template. A SharePoint Designer workflow uses declarative logic and is composed of steps that contain sets of conditions and actions. SharePoint processes each workflow step in the order shown in the designer. Within each step, SharePoint also processes sets of conditions and actions in the order shown. SharePoint stops processing in a step when one set of conditions and actions evaluates to true. For this solution, you will create two separate steps:

1. Set the file name.
2. Notify the approver of a new hardware request.

When you create a workflow in SharePoint Designer, you have the option of making that workflow available across a site or merely for a specific library or list. In this scenario, you published the hardware request form template as a site content type. Therefore, it makes sense to associate a site workflow with your template. Later, when you add the site content type to a SharePoint library, you reference the form template and associated workflow for that content type together.

By default, reusable workflows are set to automatically start on item creation and on item change. For the hardware request solution, you will make the workflow start automatically only when a new form file is added, because resetting the file name and notifying the approver are both one-time actions.

To associate a workflow with the site content type that you published earlier

1. Start SharePoint Designer and then click Open Site.
2. In the Open Site dialog box, in the Site name box, type the URL for the SharePoint site where the library resides (for example, http://intranet.contoso.com) and then click Open.
3. In the ribbon, in the New group, click Reusable Workflow.
4. In the Create Reusable Workflow dialog box, in the Name box, type Request WF.
5. Click the Content Type list and then click the name of the site content type that you published earlier (for example, Hardware Request). Figure 16 shows how the Create Reusable Workflow dialog box appears.
   Figure 16. Creating a reusable workflow
   
   
6. Click OK.
7. In the breadcrumb trail at the top, click Request WF.
8. In the Start Options area, select the Disable automatic start on item change option check box, as shown in Figure 17.
   Figure 17. Setting the workflow start options
   
   

The first step in the workflow involves waiting for a document ID to be generated for the form file and then resetting the Name and Request ID columns accordingly. In the form template, the RequestID node (which is bound to the Request ID column) is used to uniquely name form files when they are submitted to the form library. For later submit operations, because the workflow resets the RequestID node, the form file will then always use the document ID as a file name. If you recall from the Best Practices section, you must start the Document ID Service at the site collection level before IDs are assigned to form files.

To create the first workflow step

1. In the Customization area, click Edit workflow.
2. In the ribbon, in the Insert group, click Action and then click Wait for Field Change in Current Item.
3. Click the field link and then click Document ID Value.
4. Click the to equal link and then click to be not empty.
5. In the Insert group in the ribbon, click Action and then click Set Field in Current Item.
6. Click the field link and then click Name (for use in forms).
7. Click the value link and then click the Define workflow lookup icon, located to the far right.
8. In the Lookup for String dialog box, click the Field from source list, click Document ID Value, and then click OK.
9. In the Insert group in the ribbon, click Action and then click Set Field in Current Item.
10. Click the field link and then click Request ID.
11. Click the value link and then click the Define workflow lookup icon, located to the far right.
12. In the Lookup for String dialog box, click the Field from source list, click Document ID Value, and then click OK. The step logic appears as shown in Figure 18.
    Figure 18. Setting the logic for the first workflow step
    
    

For the second workflow step, you will send an email message to the approver to indicate that the user submitted a new hardware request. When you published the form template, the AccountId node for the approver was promoted as a SharePoint column that is named Approver. That column identifies the account name of the approver, and you will use that column for the To line in your email message. You can also look up promoted fields to customize the CC and Subjectlines and the message body.

To create the second workflow step

1. In the Insert group in the ribbon, click Step.
2. In the Insert group in the ribbon, click Action and then click Send an Email.
3. Click the these users link.
4. Click the Select Users button that is located to the right side of the To box.
5. In the Select Users dialog box, double-click Workflow Lookup for a User.
6. In the Lookup for Person or Group dialog box, click the Field from source list and then click Approver.
7. Click OK in all dialog boxes until you return to the Define E-mail Message dialog box.
8. In the Subject box, type New Hardware Request.
9. In the message body area, type a message that instructs the approver to review the hardware request. Use the Add or Change Lookup button at the bottom to add lookups to form fields. Figure 19 shows an example of what the message might resemble.
   Figure 19. Creating the email message that is sent to the approver
   
   
10. Click OK. Figure 20 shows how the completed workflow appears in the designer.
    Figure 20. Completing the request workflow
    
    

You could have an additional action that sends an email message to the requestor. This email could indicate that the request was received and is in review. You could also associate a separate workflow with the site content type. This workflow could notify the requestor when the hardware request has either been approved or rejected. In the case of the latter, you would only have to select the Disable automatic start on item creation option check box, in the Start Options area. For this walkthrough, these actions are optional. The point of this section was to show how to build a simple Approval workflow, which you have done. The last step then is to check for any errors, publish the workflow, and then associate the workflow with the site content type.

To publish the workflow and associate it with the content type

1. In the ribbon, in the Save group, click Check for Errors.
2. In the message box indicating that there are no errors, click OK.
3. In the ribbon, in the Save group, click Publish.
4. In the breadcrumb trail at the top, click Request WF.
5. In the ribbon, in the Manage group, click Associate to Content Type and then click the name of the site content type (for example, Hardware Request).
6. In the browser session that starts, in the Start Options area, select the Start this workflow when a new item is created check box, as shown in Figure 21.

   Note
   The Start this workflow when an item is changed check box is disabled because of the settings that you chose in SharePoint Designer.

   Figure 21. Associating the workflow with the site content type
   
   
7. Click OK.

Once you associate your workflow with the site content type, the last step is to add the content type to a library in your site. You must configure settings to enable management of content types within the target library. Then, you can add the content type to the library, which will let the user access the form template and workflow from that library.

To reference the content type from a library in your site

1. In the browser, locate your library.
2. In the ribbon, click the Library tab.
3. In the Settings group, click Library Settings.
4. In the General Settings area, click Advanced settings.
5. In the Content Types area, click Yes to enable management of content types, as shown in Figure 22.
   Figure 22. Allowing for management of content types in a library
   
   
6. Click OK.
7. In the Content Types area, click Add from existing site content types.
8. In the Available Site Content Types area, click the name of the site content type (for example, Hardware Request) and then click Add, as shown in Figure 23.
   Figure 23. Adding a site content type to a library
   
   
9. Click OK.

Conclusion

Part one of this article described some best practices for building a SharePoint application by using InfoPath 2010. Part two walked through building a sample hardware request scenario. The InfoPath designer provides most of the functionality that can be used in a form template without the need for custom code. This included 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 includes 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.