InfoPath Forms Services Architecture

Applies to: SharePoint Server 2010

In this article
Integration with Office SharePoint Server
General Architecture
Runtime Architecture
Rendering and Query Parameters
The Form Template Lifecycle
The Form Template Converter

InfoPath Forms Services, as part of Microsoft SharePoint Server 2010, is a true multitiered system. The InfoPath Forms Services architecture includes Microsoft InfoPath 2010 and the XmlFormView browser control on the desktop. They communicate with the middle tier either directly or through the InfoPath Forms Services Web services, which in turn communicate with the underlying InfoPath Forms Services and SharePoint Server 2010 components.

Integration with Office SharePoint Server

InfoPath Forms Services integrates with the core platform and advanced components of SharePoint Server 2010, which includes several server products and components that are built on the Microsoft SharePoint Foundation 2010 platform. Because InfoPath Forms Services, SharePoint Server 2010, and related products are built on the common SharePoint Products and Technologies platform, developers can use a common set of development tools and techniques to integrate and extend all of the products.

General Architecture

There are four main components of InfoPath Forms Services that enable form template (.xsn) files to be converted, rendered, and function in the browser much like they do in the InfoPath client:

• IIS and supporting ASP.NET modules: Return HTML to the browser, make file requests to the Page Generator and Converter, and forward postback information to be processed by the Page Generator.

• InfoPath Forms Services HTTP Handler: Forwards requests from the IIS and supporting ASP.NET modules and the Page Generator.

• Converter: Converts form template (.xsn) files into solution modules and .aspx pages, caches solution data, and forwards converted files to the InfoPath Forms Services HTTP Handler.

• Page Generator: Communicates with external data sources, stores and retrieves session state, retrieves initial data and solution modules, processes postback event log data, and returns data to IIS and supporting ASP.NET modules based on request from the InfoPath Forms Services HTTP Handler.

Runtime Architecture

By default, if InfoPath is installed on the computer requesting the form, the form will open in InfoPath. When a browser-enabled form is requested and InfoPath is not installed on the computer, InfoPath Forms Services redirects to the FormServer.aspx page and sends pre-generated JScript code and solution-specific JScript data arrays to the browser. The non-modifiable client-side script array is generated in two parts: when the form template is converted, and when the form is requested. It functions in a manner similar to Asynchronous JavaScript and XML (AJAX) in handling HTML generation and server communication on the client. The script array handles the following tasks:

• Generating and rendering HTML based on the JScript array from the server.

• Generating an event log of what occurs on the client to postback to the server.

• Data Validation

• Calculations

• Rules

• Editing Actions, such as inserting or removing parts of the form

• Conditional Formatting

When the user enters data into the form or otherwise updates it, an event log records all user actions. This event log, in the form of a JScript data array, is sent back to the server on the next postback, and the server repeats actions in this log on the initial XML data and executes rules and business logic as needed. The server then sends an updated JScript data array to the browser. This combined client and server-side architecture enables the form to function in the browser without having to communicate with the server for every user action. However, when communication with the server is necessary, the client and server communicate with the event log JScript data array to optimize response time and update the form with differential changes instead of sending and receiving the complete form and pre-generated JScript code with each request.

Submitting Forms

When a form is submitted, the server handles the submission for the browser. In contrast to a form submitted from the InfoPath client, which is a single XML submission process, a form submitted from the browser first submits the event log via XMLHTTP to the server, after which the server replays the event log, and then submits the XML to the final submission destination. This two-step submission process can introduce authentication problems, commonly referred to as the double-hop problem, and using the InfoPath Forms Services proxy can help resolve this problem. For more information about how to use the proxy, see About Data Connections, Authentication, and Alternate Access Mapping.

Rendering and Query Parameters

The rendering components of InfoPath Forms Services are the FormServer.aspx and MobileFormServer.aspx pages, which resides in the _layouts and the _layouts/Mobile folders, respectively, on the server. In cases in which there are multiple Web Front-End (WFE) servers and a database server comprising the farm, these components reside on the WFE.

When a browser-based form template is rendered by the FormServer.aspx page, the initial XML data and the HTML representing the form is sent to the browser, together with the supporting, non-modifiable JScript solution modules. These modules handle client-side operations such as simple calculations, conditional formatting, and data validation. The modules also handle communication of incremental changes in the XML data with the server. The results of these changes are then used in the JScript solution modules to update the HTML page representing the form, increasing performance by minimizing full page postbacks to the server.

A browser-based form template rendered by the MobileFormServer.aspx page is handled in a similar manner; however client-side processing via JScript solution modules is absent. More operations in the mobile form require communication with the server, and each communication causes a full page postback. Instead of communicating incremental changes with the server, name/value pairs are sent to the server for each control in the view.

InfoPath Forms Services support query parameters to control how a form is rendered, where it will be saved, and the page a user will be redirected to when the form is closed. For more information about how to use query parameters, see How to: Use Query Parameters to Invoke Browser-Enabled InfoPath Forms.

The Form Template Lifecycle

Figure 1 illustrates the various states that a form template can have in InfoPath Forms Services:

Figure 1. Lifecycle of a Form Template

For more information about the form template lifecycle, see Form Development and Deployment Lifecycle.

The Form Template Converter

During form conversion, a form template (.xsn) file is expanded into its component files, such as the manifest.xsf file, schema (.xsd) files, and view (.xsl) files. These files are stored on the server and are used to generate scripts and other components that are needed by InfoPath Forms Services to render the form in the XmlFormView control.