Office Forms Server 2007 Features and Enhancements

Office Forms Server 2007 makes available to the end user InfoPath 2007 forms, whether the client is a Microsoft Office system client or only a browser. Office Forms Server 2007 provides several benefits, two of which are particularly important. First, Office Forms Server provides a consistent, secure, and robust mechanism to more easily handle n-tier solutions. Second, Forms Server 2007 provides what has been called the reach experience. This allows people who do not have the InfoPath 2007 client software installed on their machines to fill out and view Office InfoPath forms using their Web browser. This ability is called zero footprint form fill-in. With the addition of Forms Server 2007, InfoPath is poised to become the new de facto standard for generating and filling out forms in an enterprise.

Forms Server 2007 is built on top of Microsoft Windows SharePoint Services 3.0. This underpinning allows Forms Server 2007 to supply several valuable abilities to the 2007 release of the Microsoft Office system. Its most notable feature is the ability to fill in forms on a remote computer using only a Web browser, including Internet Explorer, FireFox, and Apple Computers Safari. In addition, InfoPath 2007 forms can contain Microsoft .NET-managed code that performs a wide variety of valuable functions, such as automatically totaling prices on a purchase order or invoice.

Security Alert 

If it is not checked, the .NET-managed code can be a security risk. However, Forms Server 2007 helps keep the work place secure by allowing administrators to explicitly authorize the execution of custom managed-code business logic contained in InfoPath forms.

Here is an expanded list of Forms Server 2007 benefits:

• Allows explicit administrative authorization of custom business logic

• Promotes designing of forms once for both the InfoPath client and Web browser

• Helps improve security by the use of C# and Microsoft Visual Basic .NET to implement custom business logic

• Helps you comply with Sarbains-Oxley Act requirements, because it leverages the powerful digital signature-handling capabilities of InfoPath 2007

• Provides administrative control over the data connections an InfoPath form can use

• Uses InfoPath 2007 forms on personal digital assistants (PDAs) and other mobile Web devices

• Includes a backup and restore feature

• Hosts an InfoPath form in either an ASPX page or a Windows application

• Archives forms in a fixed format for legal and long-term retention purposes

• Prechecks a form's design and its features to ensure that it will function correctly when deployed to a SharePoint Portal Server document library

• Allows access to the same InfoPath 2007 form using a Web browser from multiple URLs

• Includes a powerful administrative command-line interface

Office Forms Server 2007 Architecture

Forms can contain custom business logic programmed in either C# or Visual Basic .NET. Moreover, forms can be deployed using a process called administrative deployment. In fact, forms must be administratively deployed if they contain custom business logic or managed code. Initially, this process places references to these forms in the Windows SharePoint Services 3.0 configuration database. When the process is complete, the form itself is placed into the Windows SharePoint Services 3.0 content database of the hosting site. You can upload forms to a central location and then list and manage them in the Central Administration site in the Application Management's InfoPath Forms Services section.

The Web browser accesses the form using a URL with the following syntax:

 http://contos0.contoso.msft:39250/sites/ori/_layouts/ FormServer.aspx?XsnLocation=....wdata2.xsn&SaveLocation=... url_to_Form_Library&Source=...AllItems.aspx&DefaultItemOpen=1. 

FormServer.aspx accesses the Forms Server, which in turn accesses the needed content from the content database. FormServer.aspx then presents the form to the user after checking with the configuration database to make sure it's marked as safe. InfoPath forms are packaged in a file with an .xsn extension. The primary files contained in the .xsn file are listed in Table 21-1.

Table 21-1: Files Inside an InfoPath .xsn File
Open table as spreadsheet

Extension	Name	Description
.xsf	Form Definition	Specification for an entire application. It is the application's conceptual manifest and can be customized.
.xsd	Schema Files	Holds type definitions for .xml files and connections.
.xsl	Transform Files	Each view is visually produced by applying a transform file to the appropriate underlying .xml files (for example, the template.xml and sampledata.xml files).
.xct	Component Template	Holds editing controls used to work with your forms (only in pre-version 1.0 .xsn files).
.js, .vbs	Script Files	Hold custom logic, event handlers, and so on.
.dll, .exe	Custom COM	Hold custom business logic.
.htm and others		Miscellaneous resource files used in the form application.

These files are parsed when run by the InfoPath client and are used to transform the .xml files into .html files for display in the InfoPath client. The .xsd schema files are used to validate the form data and structure, whether coming from a saved InfoPath .xml form file or from a database connection, .xml file, Web service, or SharePoint list.

Note 

There will be one XML transformation file (*.xsl) for each InfoPath View that produces an appropriate file for display. The .xsl files can produce any type of file, but for Web purposes, they are generally .tlm, .asp, and .aspx files.

The Forms Server must take these various files, as shown in Figure 21-1, and convert them into corresponding .aspx, .css, and .js files for rendering in browsers such as Apple Safari, FoxFire, and Internet Explorer.

Figure 21-1: The Update.xsl file updates the view .xsl, .xsf, and .xsd files if necessary