Export (0) Print
Expand All

Best Practices for Deploying InfoPath 2007 Form Templates to a Production Environment

Office 2007

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Summary: This article identifies best practices for efficiently deploying a Microsoft Office InfoPath 2007 form template to a production environment. It also describes how to optimize browser form scenarios using configuration options. (15 printed pages)

Experienced developers who work on Microsoft Office InfoPath 2007 form solutions that are deployed to Windows SharePoint Services 3.0 or Microsoft Office SharePoint Server 2007 all ask the same question: How do I efficiently move a form template from my development environment to a production environment? Unfortunately, there is not a simple answer to this question. Even with the introduction of InfoPath Forms Services in the 2007 Microsoft Office release, a lot of planning is still needed to configure and deploy a form template for InfoPath-only and browser-compatible form scenarios in both a development and production environment.

This article examines some of the steps you can take to make InfoPath form template deployment less painful. In the following sections, the article describes:

  • Out-of-the-box and managed-code techniques to use when you design form templates.

  • Steps to take when you publish form templates.

  • Configuration options for compatibility with InfoPath Forms Services.

Many of the aforementioned pain points are typically a product of how your form template is designed. For example:

  • Does the form template contain data connections with hard-coded URLs?

  • Are there InfoPath features or controls being implemented that are not supported in browser scenarios?

This section reviews these questions and explores answers that can help you streamline your form template for use in multiple environments.

Making Submit Data Connections Dynamic

Nearly all form templates contain one data connection that submits form data to a certain location. Typically, this data connection submits the form file to the document library from which the form template was started. To define the connection, you use the InfoPath Data Connection Wizard, which you open by using the Data Connections command on the Tools menu. With the wizard, you can identify the URL for a document library and then use data source values to specify a file-naming convention, as shown in Figure 1.

Figure 1. Defining a submit data connection

Defining a submit data connection

With many form solutions, the SharePoint Web application URL for the development environment differs from the one for the production environment. For example, if you have an InfoPath-only template that was published to a document library, the development environment URL might be in http://dev.litwareinc.com, while the production environment URL might be in http://moss.litwareinc.com. The challenge then is to design the form template in such a way that the submit data connection becomes dynamic and thus can be used in both environments, without having to make changes to the form template in the InfoPath designer.

The InfoPath team described a great managed-code solution to this challenge in the blog post titled Submitting to 'this' document library, which is summarized in this section. For an InfoPath-only scenario like the one just described, you first create a FormState dictionary object, which is used to store the location from which the form template was started. For more information about this object, see XmlForm.FormState Property (Microsoft.Office.InfoPath).

NoteNote

All code samples listed in this article are created in Microsoft Visual C# using Microsoft Visual Studio 2005 Tools for Applications, which is included in Office InfoPath 2007.

To create the FormState dictionary object

  1. In the InfoPath designer, click Tools, select Programming, and then select Microsoft Visual Studio Tools for Applications.

  2. In Visual Studio Tools for Applications, place the cursor within your form code class, preferably after the InternalStartup procedure.

  3. Create the FormState dictionary object as shown in the following code example.

    private object _strUri
    {
        get
        {
            return FormState["_strUri"];
        }
        set
        {
            FormState["_strUri"] = value;
        }
    }
    
    

After you create your FormState dictionary object, add code to the form's Loading event that retrieves the form URI string value and sets the dictionary object accordingly. For InfoPath-only scenarios, the URI string value is retrieved from the Template.Uri object, and then the Substring method is used to get the substring of the value up to the Forms folder in the document library.

To add the Loading event and set the dictionary object

  1. In the InfoPath designer, click Tools, select Programming, and then select Loading Event.

  2. In Visual Studio Tools for Applications, place the cursor within the FormEvents_Loading procedure, and add the following code.

    try
    {
        string strUri = Template.Uri.ToString();
        _strUri = strUri.Substring(0, strUri.LastIndexOf("/Forms"));
    }
    catch (Exception ex)
    {
        MessageBox.Show("There was a problem identifying the library URI:\n\n" + ex.Message);
    }
    
    

With the dictionary object set to the correct URI string value, you can then add code to the form's Submit event that modifies the FolderUrl property of your submit data connection. This update allows the form file to be submitted to the same document library from which it was started, regardless of the library location you specified in the Data Connection Wizard.

To add the Submit event and set the FolderUrl property

  1. In the InfoPath designer, click Tools, and then select Submit Options.

  2. In the Submit Options dialog box, select the Allow users to submit this form check box.

  3. Click Perform custom action using Code.

    Figure 2 shows how the Submit Options dialog box should appear.

    Figure 2. Configuring the submit options

    Configuring the submit options
  4. Click Edit Code.

  5. In Visual Studio Tools for Applications, place the cursor within the FormEvents_Submit procedure, and type the following code.

    try
    {
        FileSubmitConnection fc = (FileSubmitConnection)DataConnections["SharePoint Submit"];
        fc.FolderUrl = _strUri.ToString();
        fc.Execute();
        e.CancelableArgs.Cancel = false;
    }
    catch (Exception ex)
    {
        e.CancelableArgs.Message = "There was a problem submitting the form:\n\n" + ex.Message;
        e.CancelableArgs.Cancel = true;
    }
    
    
NoteNote

In the FileSubmitConnection initialization statement, you must replace SharePoint Submit with the name of the submit data connection.

Managing Receive Data Connections

Data connections that receive data from external sources present the same issue as connections that submit form data: URLs may change depending on whether you are in a development or production environment. In addition, data connections that automatically retrieve large amounts of data when the form is opened could significantly impact performance.

Regarding the performance issue, one approach is to determine whether a connection that retrieves data from a secondary data source, such as a Microsoft SQL Server 2005 database or a SharePoint list, can be converted into an XML resource file data connection. If a particular data connection retrieves static data, setting up that connection as an embedded XML resource file helps reduce query times in the form. For example, a connection to the Sales.SalesTerritory table of the sample AdventureWorks database could be represented in an XML file as follows.

<Territories>
    <Territory ID="1">USA-Northwest</Territory>
    <Territory ID="2">USA-Northeast</Territory>
    <Territory ID="3">USA-Central</Territory>
    <Territory ID="4">USA-Southwest</Territory>
    <Territory ID="5">USA-Southeast</Territory>
    <Territory ID="6">Canada</Territory>
    <Territory ID="7">France</Territory>
    <Territory ID="8">Germany</Territory>
    <Territory ID="9">Australia</Territory>
    <Territory ID="10">United Kingdom</Territory>
</Territories>

When you create the data connection for the XML file in the Data Connection Wizard, ensure that the option to Include the data as a resource file in the form template or template part is selected, as shown in Figure 3.

Figure 3. Embedding an XML data connection

Embedding an XML data connection

For a receive data connection that is dynamic, another approach to consider is whether the connection can be converted into a Universal Data Connection (UDC) v2.0 file. A UDC file stores data connection settings and resides in a SharePoint Server data connection library (DCL), thus allowing it to be used across form templates. This capability provides developers the luxury of being able to make modifications to the location of an external data source without having to update and redeploy form templates that use that data source.

The InfoPath team has provided developers with a UDC file-creation tool. Essentially, this is an InfoPath form template that enables you to define the settings for a UDC file. The following procedures use this tool to illustrate how to create a UDC file for the HumanResources.Employee table of the sample AdventureWorks database.

Before starting the form template, you need connection string information for the AdventureWorks database, which you can glean from an Office database connection (.odc) file. If an .odc file does not already exist for the HumanResources.Employee table, you can create one with the InfoPath Data Connection Wizard.

To create the .odc file for the HumanResources.Employee table

  1. In the InfoPath designer for any form template, on the Tools menu, select Data Connections.

  2. In the Data Connections dialog box, click Add.

  3. On the first page of the Data Connection Wizard, click Create a new connection to, click Receive data, and then click Next.

  4. On the next page of the wizard, click Database (Microsoft SQL Server of Microsoft Office Access only), and then click Next.

  5. On the next page, click Select Database.

  6. In the Select Data Source dialog box, double-click +Connect to New Data Source.odc.

  7. In the Data Connection Wizard, click Microsoft SQL Server, and then click Next.

  8. Type the name of your database server in the Server name box, provide the logon credentials, and then click Next.

  9. In the Select the database that contains the data you want list, select AdventureWorks.

  10. In the Connect to a specific table list, click Employee.

    Figure 4 shows how the Data Connection Wizard should appear.

    Figure 4. Connecting to the Employee table

    Connecting to the Employee table
  11. Click Finish.

  12. In the Data Connection Wizard, click Cancel.

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

The previous set of steps creates an .odc file for the HumanResources.Employee table in your My Documents\My Data Sources folder. You obtain the connection string information from that file when you use the UDC file-creation tool.

To create the UDC file for the HumanResources.Employee table

  1. In Windows Explorer, right-click UDC File Creator.xsn, and then click Design.

  2. In the dialog box that indicates that the form template has been saved or moved to a different location, click OK.

  3. Press CTRL+S, save the form template with a new name, and then close Office InfoPath 2007.

    By default, the new form template name is Universal Data Connection V2.xsn.

  4. Double-click the newly named form template.

  5. In the Name box, type AdventureWorks Employees.

  6. In the Description box, type a description.

  7. Click the Type list, and then click Database.

  8. In Windows Explorer, navigate to My Documents\My Data Sources, and open the AdventureWorks employee .odc file in Microsoft Notepad.

  9. Copy the content of the odc:ConnectionString element from the .odc file into the Connection String box in the UDC file-creation tool.

  10. In the UDC file-creation tool, in the Query box, type SELECT * FROM "AdventureWorks"."HumanResources"."Employee".

    Figure 5 shows how the UDC file-creation tool should appear.

    Figure 5. Creating the UDC file

    Creating the UDC file
  11. Press CTRL+S, and in the Save As dialog box, navigate to the desired location.

  12. In the File name box, type AdventureWorks Employees, and then click Save.

  13. Close the UDC file-creation tool.

With the UDC file (an XML file) created, the next step is to add a DCL to the site collection where your form template will be published. You then add your UDC file as an item to the DCL.

To create the DCL and upload the UDC file

  1. In Microsoft Internet Explorer, navigate to the URL for your SharePoint site (for example, http://moss.litwareinc.com).

  2. In the left navigation bar, click View All Site Content.

  3. On the All Site Content page, click Create.

  4. On the Create page, in the Libraries section, click Data Connection Library.

  5. On the New page, in the Name box, type a name for your DCL (for example, Data Connections), and then click Create.

  6. In your DCL, click Upload, and then click Upload Document.

  7. On the Upload Document page, click Browse.

  8. In the Choose file dialog box, navigate to the location of AdventureWorks Employees.xml, and double-click it.

  9. On the Upload Document page, click OK.

    Figure 6 shows how your DCL item should appear in the browser.

    Figure 6. Adding a DCL item

    Adding a DCL item
  10. Click OK.

    NoteNote

    For DCL items to appear in public views, they must be approved.

Now, within your form template, you can create a data connection for the uploaded UDC file. You can use the Data Connection Wizard to identify SharePoint sites that you want to search for data connections.

To add the data connection for the UDC file

  1. Open your form template in the InfoPath designer, and on the Tools menu, click Data Connections.

  2. In the Data Connections dialog box, click Add.

  3. On the first page of the Data Connection Wizard, click Search for connections on a Microsoft Office SharePoint Server, and then click Next.

  4. On the next page of the wizard, click Manage Sites.

  5. In the Manage Sites dialog box, click Add.

  6. In the Site Details dialog box, in the URL box, type the URL for the SharePoint site where the DCL is located (for example, http://moss.litwareinc.com), and then click OK.

  7. In the Manage Sites dialog box, click Close.

  8. In the Data Connection Wizard, click the Site list, and then click the URL you just added.

  9. Expand the name of your DCL, and click AdventureWorks Employees.xml.

    Figure 7 shows how the Data Connection Wizard should appear.

    Figure 7. Creating the data connection in the form template

    Creating the data connection in the form template
  10. Click Next.

  11. On the next page of the Data Connection Wizard, click Next.

  12. On the last page, click Finish.

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

Distinguishing InfoPath-Only and Browser Functionality

Up to this point, this article has focused on InfoPath-only scenarios. If the environment in which you are working has InfoPath Forms Services installed, there is a strong likelihood that browser scenarios will also need to be supported.

Making the switch from an InfoPath-only form template to one that also supports browser scenarios is simple enough to execute. You can use the Design Checker to change the compatibility settings of your form template and check for issues. The next set of steps illustrates this process using the sample meeting agenda form template that comes with Office InfoPath 2007.

To change the compatibility settings for the meeting agenda form template

  1. Start Office InfoPath 2007. In the Getting Started dialog box, click Customize a Sample.

  2. Double-click the Sample - Meeting Agenda sample.

  3. In the Design Tasks task pane, click Design Checker.

  4. In the Design Checker task pane, click Change Compatibility Settings.

  5. In the Form Options dialog box, select the Design a form template that can be opened in a browser or InfoPath check box, and then click OK.

Figure 8 shows the results of switching the compatibility.

Figure 8. Changing compatibility settings

Changing compatibility settings

The Design Checker lists errors and messages for controls and features that are not compatible with InfoPath Forms Services. In this particular case, you would be left to address each issue before you deploy the meeting agenda template. Of course, this scenario is avoidable if you select the Enable browser-compatible features only check box when you are designing a new form template, as shown in Figure 9. Then, controls that are not supported by InfoPath Forms Services do not appear in the Controls task pane, and unsupported features are clearly identified in task panes and dialog boxes.

Figure 9. Enabling browser support in new form templates

Enabling browser support in new form templates

With browser-compatible form templates that use managed code, you might have to distinguish between InfoPath-only and browser functionality. For example, consider the scenario described earlier in the Making Submit Data Connections Dynamic section. If the form template were compatible with InfoPath Forms Services, the code would not execute properly if a user started the form in the browser. That is because the Template.Uri object does not work for browser forms.

To distinguish between InfoPath-only and browser functionality, you can use the Application.Environment class in your code. This class has properties that enable you to determine the run-time environment that was used to open the form. In the revised scenario of dynamically setting the submit data connection for browser forms, you can use the IsBrowser property to set the FormState dictionary object correctly, as shown in the following update for the Loading event.

NoteNote

Browser-compatible form templates that use managed code must be fully trusted and deployed by a server administrator. As a result, the document library URI string cannot be identified in this scenario if the form is started in InfoPath, even with the Template.Uri object.

try
{
    if (Application.Environment.IsBrowser)
    {
        string strUri = e.InputParameters["SaveLocation"].ToString();
        _strUri = strUri.Substring(0, strUri.LastIndexOf("/"));
    }
    else
    {
        FileSubmitConnection fc = (FileSubmitConnection)DataConnections["SharePoint Submit"];
        _strUri = fc.FolderUrl.ToString();
        MainDataSource.CreateNavigator().SelectSingleNode("//my:RuntimeAlert", NamespaceManager).SetValue
          ("Dynamic submit data connections are not supported for forms started in InfoPath.");
    }
}
catch (Exception ex)
{
    MainDataSource.CreateNavigator().SelectSingleNode("//my:RuntimeError", NamespaceManager).SetValue(ex.Message);
}

Here, the SaveLocation input parameter is used to identify the document library URI string of a form opened in the browser, with the trailing "/" omitted. If the form is opened in InfoPath, the FormState dictionary object is simply set to the current FolderUrl property value for the submit data connection. The MessageBox.Show method (in the System.Windows.Forms class) is not available for forms that are deployed to InfoPath Forms Services; therefore, the RuntimeAlert and RuntimeError nodes in the form's main data source are used to display alert messages and record exceptions, respectively.

Debugging the Form Template

At design time, you can use the InfoPath preview functionality to simulate the end-user experience of filling out a form. For managed-code solutions, you can perform additional debugging with Visual Studio by inserting breakpoints and stepping through lines of code. However, your users' actual run-time experience is often different from the debugging scenarios you use at design time. How do you know if data source values are being set correctly after the form is deployed to a production environment?

The answer is to create a debug view that exposes all of the form's data sources, including values from secondary data sources. This view is hidden from end users at run time, unless a problem is reported and form values must be evaluated in the development or production environment. To facilitate the debugging process, you can add the aforementioned RuntimeAlert and RuntimeError nodes to your data source and bind them to controls in this view.

To create a debug view for your form template and hide it from users at run time

  1. In the InfoPath designer, click View, and then click Data Source.

  2. In the Data Source task pane, right-click the root node, and then click Add.

  3. In the Add Field or Group dialog box, in the Name box, type RuntimeAlert, and then click OK.

  4. Repeat the two previous steps for the RuntimeError node.

  5. Click View, and then click Manage Views.

  6. In the Views task pane, click Add a New View.

  7. In the Add View dialog box, in the New view name box, type Debug, and then click OK.

  8. Click View Properties.

  9. In the View Properties dialog box, clear the Show on the View menu when filling out the form check box, as shown in Figure 10.

    Figure 10. Hiding the debug view from end users

    Hiding the debug view from end users
  10. Click OK.

  11. Click View, and then click Data Source.

  12. Drag the root node of the main data source to the form view, and then click Section with Controls.

    You can repeat the last step for any secondary data sources in your form template. Use the Data source list in the task pane to change the data source you want to display. Add labels to the form view as needed to help distinguish the data sources. When you are ready to implement the debug view in your development or production environment, select the Show on the View menu when filling out the form check box described earlier, and then redeploy the form template.

For a simple form solution (for example, a department status report scenario), using the InfoPath Publishing Wizard to publish the template directly to a SharePoint document library may be an effective deployment method. However, as you add complexity to the form template, this method becomes less practical. If you have a browser-compatible form template that must be used in multiple libraries or sites, includes data connections for UDC files, or contains managed code, administrator-deployment is the appropriate method. In fact, administrator-deployment is required for all browser-compatible form templates that contain code.

When administrator-deploying a form template, you use the Publishing Wizard to save a copy of the form template to a shared location. In addition, you can save any UDC files that the form uses to the same share. After all files have been saved, a server administrator must then deploy the form templates and associated UDC files to a SharePoint site. This process publishes the form template as an InfoPath content type, thus allowing it to be referenced across document libraries within the site and thereby promoting greater reuse. This section examines the administrator-deployment process for form templates and UDC files.

Administrator-Deploying Data Connection Files

The Managing Receive Data Connections section describes how you can store data connection settings in a SharePoint DCL, making them reusable across form templates within a site. If you plan to administrator-deploy the form template, you can store associated UDC files in a centrally managed connection library in InfoPath Forms Services. This passes control of the data connection from the form developer to the server administrator. It also offers the possibility of using the data connection across multiple sites. The next procedure steps through the process of administrator-deploying the AdventureWorks Employees UDC file, which was previously uploaded to a local DCL.

To upload the AdventureWorks Employees UDC file to a central library

  1. Start Windows SharePoint Services 3.0 Central Administration.

  2. On the Central Administration page, click the Application Management tab.

  3. On the Application Management page, in the InfoPath Forms Services section, click Manage data connection files.

  4. On the Manage Data Connection Files page, click Upload.

  5. On the Upload Data Connection File page, click Browse.

  6. In the Choose file dialog box, navigate to the location of AdventureWorks Employees.xml, and double-click it.

  7. To enable the connection to work with forms started in InfoPath, select the Allow HTTP access to this file check box.

    Your Upload Data Connection File page should appear as shown in Figure 11.

    Figure 11. Uploading UDC files to a central library

    Uploading UDC files to a central library
  8. Click Upload.

Administrator-Deploying Form Templates

After you move UDC files from a local DCL to one that is centrally managed in InfoPath Forms Services, you can then modify data-connection properties in the InfoPath designer and administrator-deploy the form template. In the next set of steps, the form template is modified to include a data connection for the AdventureWorks Employees UDC file.

To update the data-connection properties

  1. In the InfoPath designer, on the Tools menu, click Data Connections.

  2. In the Data Connections dialog box, click the AdventureWorks Employees data connection, and then click Modify.

  3. In the Data Connection Wizard, click AdventureWorks Employees.xml, and then click Connection Options.

  4. In the Connection Options dialog box, click Centrally managed connection library, as shown in Figure 12.

    Figure 12. Changing the data connection link options

    Changing the data connection link options
  5. Click OK.

  6. In the Data Connection Wizard, click Next.

  7. On the next page of the Data Connection Wizard, click Next.

  8. On the last page, click Finish.

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

After you update all the data connections, you use the Publishing Wizard to save the form template to a location that the server administrator can access. Before proceeding, make sure that the form is compatible with InfoPath Forms Services. Use the Design Checker to identify and address any compatibility errors.

To publish the form template to a location for the server administrator

  1. On the File menu, click Publish.

  2. On the first page of the Publishing Wizard, click To a SharePoint server with or without InfoPath Forms Services, and then click Next.

  3. On the next page of the wizard, type the URL for a site that has InfoPath Forms Services enabled (for example, http://moss.litwareinc.com), and then click Next.

  4. On the next page, ensure that the Enable this form to be filled out by using a browser check box is selected and that the Administrator-approved form template (advanced) option is clicked, as shown in Figure 13.

    Figure 13. Administrator-deploying the form template

    Administrator-deploying the form template
  5. Click Next.

  6. On the next page of the Publishing Wizard, click Browse.

  7. In the Browse dialog box, navigate to a location that your server administrator can access, type a name in the File name box, and then click Save.

  8. In the Publishing Wizard, click Next.

  9. On the next page of the wizard, manage promoted columns as needed, and then click Next.

  10. On the next page of the wizard, click Publish.

  11. On the last page, click Close.

After you publish the form template to a network location, the server administrator can then upload the form template to InfoPath Forms Services. After the form template is in InfoPath Forms Services, the administrator can then activate it to a particular site collection so that it can be referenced in document libraries within that site collection.

To upload the form to InfoPath Forms Services and activate to a site collection

  1. Start Windows SharePoint Services 3.0 Central Administration.

  2. On the Central Administration page, click the Application Management tab.

  3. On the Application Management page, in the InfoPath Forms Services section, click Manage form templates.

  4. On the Manage Form Templates page, click Upload form template.

  5. On the Upload Form Template page, click Browse.

  6. In the Choose file dialog box, navigate to the location of the published (saved) form template, and double-click it.

  7. On the Upload Form Template page, click Upload.

  8. On the page indicating that the form template has been successfully uploaded, click OK.

  9. On the Manage Form Templates page, pause on the form template you just uploaded, click it to start the Open menu, and then click Activate to a Site Collection, as shown in Figure 14.

    Figure 14. Activating to a site collection

    Activating to a site collection
  10. On the Activate Form Template page, click the Site Collection list, and then click Change Site Collection.

  11. In the Select Site Collection dialog box, click the Web Application list, and then click Change Web Application.

  12. In the Select Web Application dialog box, click the appropriate Web application (for example, moss.litwareinc.com).

  13. In the Select Site Collection dialog box, click OK.

  14. On the Activate Form Template page, click OK.

NoteNote

Form templates that have been uploaded to InfoPath Forms Services can be activated to multiple site collections.

When you activate a form template to a site collection, you can use that form template in multiple document libraries within that site collection. Before you reference the form template, make sure that the document library allows for the management of content types.

To reference an InfoPath content type in a document library

  1. In Internet Explorer, navigate to the document library in the site collection for which you activated the form template.

  2. Click Settings, and then click Document Library Settings.

  3. In the General Settings section, click Advanced settings.

  4. On the Document Library Advanced Settings page, ensure that Yes is selected for Allow management of content types?, as shown in Figure 15.

    Figure 15. Allowing management of content types

    Allowing management of content types
  5. Click OK.

  6. In the Content Types section, click Add from existing site content types.

  7. On the Add Content Types page, click the appropriate site content type, click Add, and then click OK.

Scenarios that support browser-compatible form templates can be optimized using InfoPath Forms Services configuration options in Windows SharePoint Services 3.0 Central Administration. This section reviews these options and examines some scenarios that would require additional configuration beyond what is found on the Configure InfoPath Forms Services page.

Configuring InfoPath Forms Services

Server administrators can modify time-out settings, authentication restrictions, and other configuration options for browser-enabled form templates in Windows SharePoint Services 3.0 Central Administration.

To navigate to the Configure InfoPath Forms Services page

  1. Start Windows SharePoint Services 3.0 Central Administration.

  2. On the Central Administration page, click the Application Management tab.

  3. On the Application Management page, in the InfoPath Forms Services section, click Configure InfoPath Forms Services.

The default settings on the Configure InfoPath Forms Services pages are sufficient for most form solutions. Table 1 describes some of the key options on this page and lists corresponding default values.

Table 1. Key options on the Configure InfoPath Forms Services page

Option

Description

Default

Allow users to browser-enable form templates

If this option is not selected, users who attempt to publish a browser-compatible form template see a message in the InfoPath Publishing Wizard indicating that the form template cannot be browser-enabled on the selected site.

Yes

Render form templates that are browser-enabled by users

If this option is not selected, users who attempt to start a form file in the browser are prompted to start the form in Office InfoPath 2007 instead (assuming Office InfoPath 2007 is installed on the user's computer).

Yes

Require SSL for HTTP authentication to data sources

If data connections in a browser-enabled form template require basic authentication or digest authentication, a password is sent across the network. This option requires an SSL-encrypted connection for these authentication types.

Yes

Allow embedded SQL authentication

If this option is selected, SQL Server data connections (whether direct or through the use of UDC files) in a browser-enabled form template can contain embedded SQL authentication in connecting strings.

No

Allow user form templates to use authentication information contained in data connection files

If this option is selected, UDC files in a browser-enabled form template can contain an explicit user name and password or a Microsoft Office Single Sign-On Application ID.

No

Allow cross-domain data access for user form templates that use connection settings in a data connection file

If this option is selected, data connections in a browser-enabled form template can access data from domains that are different from the one from which the form was started. Even if the data connection is a UDC file, this option can be used to override cross-domain access.

No

Enabling Extranet Scenarios

If you have a scenario in which you must access browser-enabled forms from both an intranet URL (for example, http://moss.litwareinc.com) and an extranet URL (for example, http://extranet.litwareinc.com), you must have alternate access mappings set up so that the intranet and extranet sites both point to the same location. Without alternate access mappings, form files that are saved or submitted to the intranet site cannot be accessed from the extranet URL, because the intranet URL is stored in the href attribute in a processing instruction at the top of the form file.

To set up alternate accessing mappings for your extranet scenario

  1. Start Windows SharePoint Services 3.0 Central Administration.

  2. On the Central Administration page, click the Operations tab.

  3. On the Operations page, in the Global Configuration section, click Alternate access mappings.

  4. On the Alternate Access Mappings page, click the Alternate Access Mapping Collection list, and then click Change Alternate Access Mapping Collection.

  5. In the Select An Alternate Access Mapping Collection dialog box, click the Web application for your intranet URL (for example, moss.litwareinc.com).

  6. On the Alternate Access Mappings page, click Add Internal URLs.

  7. On the Add Internal URLs page, in the URL protocol, host and port box, type the extranet URL (for example, http://extranet.litwareinc.com) that you want to map to the intranet URL.

    Figure 16 shows how the Add Internal URLs page should look.

    Figure 16. Mapping the intranet and extranet URLs

    Mapping the intranet and extranet URLs
  8. Click Save.

NoteNote

If you are using a pre-Service Pack 1 version of Office SharePoint Server 2007, there is a known bug that prevents users from accessing administrator-deployed forms in the browser from the extranet URL, even with the alternate access mappings set up. As a result, you must install the InfoPath 2007 hotfix package from Microsoft Help and Support for extranet scenarios that use administrator-deployed forms.

Supporting Digital Signatures in Form Files

If you have a scenario in which browser forms have to be digitally signed, you must ensure that the digital certificate being used is in the correct location on both the end user's computer and the Office SharePoint Server 2007 computer. To use a digital signature in a browser form, the certificate must reside in the user's Personal certificate store and the Trusted Root Certification Authorities certificate store on the Office SharePoint Server 2007 computer. If you export a certificate from one computer so that it can be used on another computer, you must export the private key and include all certificates in the certification path, if possible.

To export a user's digital certificate for use on a SharePoint server

  1. On the client computer, start Internet Explorer.

  2. Click Tools, and then click Internet Options.

  3. In the Internet Options dialog box, click the Content tab.

  4. In the Certificates section, click Certificates.

  5. In the Certificates dialog box, click the Personal tab.

  6. Click the appropriate digital certificate, and then click Export.

  7. On the first page of the Certificate Export Wizard, click Next.

  8. On the next page, click Yes. Export the private key, and then click Next.

  9. On the next page of the Certificate Export Wizard, select the Include all certificates in the certification path if possible check box, as shown in Figure 17.

    Figure 17. Including all certificates in the certification path

    Including all certificates in certification path
  10. Click Next.

  11. On the next page of the wizard, type and confirm a password as needed, and then click Next.

  12. On the next page of the wizard, click Browse.

  13. In the Save As dialog box, navigate to a location where you want to save the certificate, type a name in the File name box, and then click Save.

  14. In the Certificate Export Wizard, click Next.

  15. On the last page of the Certificate Export Wizard, click Finish.

  16. In the dialog box that indicates that the export was successful, click OK.

  17. In the Certificates dialog box, click Close.

  18. In the Internet Options dialog box, click OK.

The previous set of steps saves a Personal Information Exchange (.pfx) file to your computer. After you export the user's certificate, you must import it into the Trusted Root Certification Authorities certificate store on the Office SharePoint Server 2007 computer.

To import the user's digital certificate for use on a SharePoint server

  1. On the Office SharePoint Server 2007 computer, start Internet Explorer.

  2. Click Tools, and then select Internet Options.

  3. In the Internet Options dialog box, click the Content tab.

  4. In the Certificates section, click Certificates.

  5. In the Certificates dialog box, click the Trusted Root Certification Authorities tab. Click Import.

  6. On the first page of the Certificate Import Wizard, click Next.

  7. On the next page, click Browse.

  8. In the Open dialog box, change the Files of type list value to Personal Information Exchange (*.pfx;*.p12), as shown in Figure 18.

    Figure 18. Changing the certificate file type

    Changing the certificate file type
  9. Navigate to the location of the .pfx file, and double-click it.

  10. In the Certificate Import Wizard, click Next.

  11. On the next page of the Certificate Import Wizard, type the password as needed, and then click Next.

  12. On the next page, click Next.

  13. On the last page of the wizard, click Finish.

  14. In the Security Warning dialog box, click Yes.

  15. In the dialog box that indicates that the import was successful, click OK.

  16. In the Certificates dialog box, click Close.

  17. In the Internet Options dialog box, click OK.

Configuring and deploying Office InfoPath 2007 form solutions does not come without pain points. References to secondary data sources in a form template are probably different depending on whether you are deploying to a development or production environment. In addition, the functionality exhibited by a form template in an InfoPath-only scenario might not be identical to the functionality for that same template in a browser scenario.

This article identifies some best practices for efficiently deploying Office InfoPath 2007 form templates to a production environment. There are out-of-the-box and managed-code techniques to use in the InfoPath designer in addition to certain steps you can take when you publish a form. For administrator-deployed form templates, you can use Windows SharePoint Services 3.0 Central Administration to optimize form templates that are compatible with InfoPath Forms Services. While there is still a fair amount of work to perform, steps identified in this article will help minimize the effort of managing form templates in multiple environments.

Show:
© 2014 Microsoft