Publishing InfoPath Forms | Programming Microsoft Infopath: A Developers Guide

InfoPath forms that aren t deployed as fully trusted solutions are sandboxed based on an URL. InfoPath, like IE, has no access to the local computer resources.

These types of InfoPath forms are stored in the local Internet cache, and changes are automatically downloaded to the local machine. When deploying InfoPath solutions, enterprises should always try to use the sandboxed approach to forms as their first choice.

Publishing Forms

Sandboxed forms are deployed through a publishing process. This is a feature of InfoPath that places forms into a shared location where users can access the form template. Many times, InfoPath forms are used to collect data for review and aren t directly submitted to a Web Service until some later point of the workflow. For example, if we rebuild the New Candidate Questionnaire using the following XSD, we get Listing 10.2. (You can see this example in \Code\Chapter 10\Candidate\OtherPublish\CandidatePublish.xsn on the companion CD-ROM.)

Listing 10.2: XSD for the New Candidate Questionnaire.

 <?xml version="1.0"?> <xsd:schema  targetNamespace="http://schemas.mycompany.com/ns/candidate/info"  xmlns:candidate="http://schemas.mycompany.com/ns/candidate/info"  xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="date" type="xsd:date"/> <xsd:element name="name" type="xsd:string"/> <xsd:element name="ssn" type="xsd:string"/> <xsd:element name="phone" type="xsd:string"/> <xsd:element name="positionapplyingfor" type="xsd:string"/> <xsd:element name="highschool" type="xsd:string"/> <xsd:element name="college" type="xsd:string"/> <xsd:element name="employeename" type="xsd:string"/> <xsd:element name="employeeaddress" type="xsd:string"/> <xsd:element name="employeeposition" type="xsd:string"/> <xsd:element name="candidateinfo">   <xsd:complexType>     <xsd:sequence>       <xsd:element ref="candidate:date"/>       <xsd:element ref="candidate:name"/>       <xsd:element ref="candidate:ssn"/>       <xsd:element ref="candidate:phone"/>       <xsd:element ref="candidate:positionapplyingfor"/>       <xsd:element ref="candidate:education" minOccurs="0"  maxOccurs="1"/>       <xsd:element ref="candidate:mostrecentemployer" minOccurs="0"  maxOccurs="1"/>     </xsd:sequence>   </xsd:complexType> </xsd:element> <xsd:element name="education">   <xsd:complexType>     <xsd:sequence>       <xsd:element ref="candidate:highschool"/>       <xsd:element ref="candidate:college"/>     </xsd:sequence>   </xsd:complexType> </xsd:element> <xsd:element name="mostrecentemployer">   <xsd:complexType>     <xsd:sequence>       <xsd:element ref="candidate:employeename"/>       <xsd:element ref="candidate:employeeaddress"/>       <xsd:element ref="candidate:employeeposition"/>     </xsd:sequence>   </xsd:complexType> </xsd:element> </xsd:schema>

We can design a form based on this schema, as shown in Figure 10.10.

Figure 10.10: The New Candidate Questionnaire.

Once the form design is complete, the Publishing Wizard enables the InfoPath form to be deployed into the following shared locations:

Shared folder
Web server
Sharepoint Forms Library

Publishing to a Shared Folder

When deploying an InfoPath form to a shared folder, you need to provide the common network path to the location, as shown in Figure 10.11.

Figure 10.11: Entering the shared folder location.

If the network path is not a common path for network users, the Publishing Wizard provides an alternate entry point, as shown in Figure 10.12.

Figure 10.12: Defining an alternate network point.

Defining a system-wide accessible network path is essential for this mode of deployment. For example, when you deploy forms using this method, a login script is often run to attach the correct drive letters and paths to users. This guarantees that all users will have the same path structure. As with all publishing, InfoPath provides a notification mechanism that allows user notification when a form has been deployed, as shown in Figure 10.13.

Figure 10.13: E-mail notification that a form has been deployed.

Once the form is published users are able to open the form and save existing XML instances to the shared drive as shown in Figure 10.14.

Figure 10.14: XML files saved on a file share.

Publishing to a Web Server

Publishing a form to a Web server involves the same deployment process used for shared folders. The major functional difference is that the form is downloaded to the local machine from an IIS virtual directory as opposed to being run across a network file system. The first step in deploying forms using this publishing method is to create an IIS Virtual Directory. You can do this by using the Microsoft Management Console (MMC) and selecting the Virtual Directory Creation Wizard, as shown in Figure 10.15.

Figure 10.15: Starting the Virtual Directory Creation Wizard.

This wizard is responsible for creating a new Virtual Directory within IIS that can be used to deploy the InfoPath form. The wizard takes you through the following steps:

Create the name for the new Virtual Directory, as shown in Figure 10.16.

Figure 10.16: Defining the Virtual Directory alias.
Define the URL alias that is tied to the disk directory on the server, as shown in Figure 10.17.

Figure 10.17: Defining the content directory.
Define the directory permissions for your application, as shown in Figure 10.18.

Figure 10.18: Defining the directory security.
Deploy the InfoPath form by entering the URL of the IIS Virtual Directory, as shown in Figure 10.19.

Figure 10.19: Defining the InfoPath HTTP path for form publishing.

Once the form is deployed, users can then download, complete, and save the forms. All instances of the form template are actually saved to their local Internet cache, as seen in Figure 10.20.

Figure 10.20: The local Internet cache, showing saved InfoPath forms.

Publishing to a Sharepoint Forms Library

The Sharepoint Forms Library is the best solution for deploying forms. The Forms Library function available within WSS allows you to both save and define reporting views of the data. Publishing a form to WSS involves the following steps:

Create a new Sharepoint Forms Library, as shown in Figure 10.21.

Figure 10.21: Creating the Sharepoint Forms Library.
Enter the URL to the location where the Sharepoint Forms Library should be created, as shown in Figure 10.22.

Figure 10.22: Entering the URL path for the new library.

Note
This URL will change based on the WSS architecture deployed in your enterprise.
Define a description for the library that users will view when they add, edit, or delete forms, as shown in Figure 10.23.

Figure 10.23: Providing a description for the forms library.
Define the fields for promotion to columns, as shown in Figure 10.24. These are the columns that users will be able to view and sort on within the library.

Figure 10.24: Defining the promotion fields.
Define any filters to organize the view of your data, as shown in Figure 10.25.

Figure 10.25: Defining view filters.

Upgrading Modified Forms

Applications are never really complete. They are in a constant process of modification, change, and reengineering to meet the business needs and requirements. InfoPath allows you to modify and upgrade changes in the form template both silently and automatically.

When a form template is modified in design mode, the existing form template also needs to be upgraded. This guarantees that users can continue to work with their existing forms data wherever it is published. If a form is not upgraded, this may prevent the form from opening or functioning properly, and the existing data for forms could be lost. Forms can either be upgraded automatically or using a custom script function.

Choosing to automatically upgrade existing forms when you modify the form template ensures that any changes made to a published form template don t prevent users from opening and working with an existing form. Choosing to automatically upgrade a form allows the users to open an existing form template even if the underlying XML Schema has been changed. This is because InfoPath can schematically reconstruct the .xml file so that it is compatible against the modified form template s new XML Schema. By default, InfoPath is set to automatically upgrade existing templates, as shown in Figure 10.26.

Figure 10.26: Defining the template upgrade options.

Note	When the automatic upgrade option is selected, the form template maintains a copy of each version of the XSD saved in design mode.

More complicated upgrades (including element changes or XSD modification) should be handled through script. The OnVersionUpgrade event is responsible for handling form templates upgrade events and provides access to the underlying XML schema and data. For example, the following script will alert the user that a form upgrade has taken place:

 function XDocument::OnVersionUpgrade(eventObj) {   XDocument.UI.Alert("An upgrade has occurred and the new form  version is : " + eventObj.DocumentVersion +   "\nThe form template version: " + eventObj.SolutionVersion);    eventObj.ReturnStatus = true; }