Building SharePoint Applications with InfoPath 2010 (Part 2 of 2) (MSDN refresh)

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 2010

In this article
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.

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 to PreferredName 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 to PreferredName 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 the Requested Hardware repeating table. The repeating table control is bound to the HardwareItem repeating main data source node, which is nested in the RequestedHardware 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 a E: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.

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 the Btn_AddHardware_Clicked procedure, add the following code.

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 the HardwareType 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.

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 the Remove 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). The Remove 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.

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 hidden RequestID 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 the Reject button control is disabled unless the approver enters a Rejection Reason. You will add declarative logic to both button controls that sets the RequestStatus 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 to Rejected 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 Subject lines 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.

Additional Resources

For more information, see the following resources:

• Microsoft Office Development Center

• InfoPath Developer Center

• SharePoint Developer Center

• InfoPath Developer Reference for Form Templates

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

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.