Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

InfoPath Forms Services Architecture

InfoPath Forms Services, as part of either Microsoft Office Forms Server 2007 or Microsoft Office SharePoint Server 2007, is a true multitiered system. The InfoPath Forms Services architecture includes Microsoft Office InfoPath 2007 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 Office SharePoint Server 2007 components.

Integration with Office SharePoint Server 2007

InfoPath Forms Services integrates with the core platform and advanced components of Office SharePoint Server 2007, which includes several server products and components that are built on the Windows SharePoint Services 3.0 platform. Because InfoPath Forms Services, Office SharePoint Server 2007, 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.

Components of Office SharePoint Server 2007

Office SharePoint Server 2007 aggregates services and applications that were previously separate products. For example, the functionality of Microsoft Office SharePoint Portal Server 2003 and Microsoft Content Management Server (MCMS) 2002 are now part of Office SharePoint Server 2007. In addition, Office SharePoint Server 2007 adds new administrative, collaboration, business process management, and business intelligence features along with Excel Services, Enterprise Content Management, a common search architecture, and workflow.

Figure 1 shows the major application features and components of Office SharePoint Server 2007 and the shared application and administration services.

Figure 1. Applications and components of SharePoint Server

Applications and components of SharePoint Server

Note Figure 1 offers a generalized view of Office SharePoint Server 2007 and the Windows SharePoint Services platform, and does not show which of the shared application services are specifically associated with the core components such as Windows Workflow Foundation. Additionally, InfoPath Forms Services integrates with Office SharePoint Server 2007 at the same level as Excel Services but is shown in the diagram as a separate SKU, namely Office Forms Server 2007.

Products

Microsoft Office Project Server 2007 and Microsoft Office Forms Server 2007 are available separately from Microsoft Office SharePoint Server 2007.

All of the products in the 2007 Microsoft Office system, including Office SharePoint Server 2007, Office Project Server 2007, and Office Forms Server 2007, make use of the Windows SharePoint Services core platform and some of the application services in Office SharePoint Server 2007.

All of the features in Office SharePoint Server 2007 can be integrated and extended with a common set of tools and technologies in Microsoft Visual Studio 2005 and Microsoft Office SharePoint Designer 2007. Microsoft ASP.NET 2.0 allows developers to create and modify Web Parts, master pages, provide personalization for Web sites, and integrate an extensible provider model for navigation, security, and other platform features.

Office SharePoint Server 2007 requires either SQL Server 2000 with Service Pack 3 or later, or SQL Server 2005. If these applications are installed on a single computer, Office SharePoint Server 2007 can run with SQL Server 2000 MSDE or SQL Server 2005 Express Edition. For a farm installation using multiple computers, all of the 2007 Microsoft Office system server products require the full SQL Server product.

General Architecture

There are four main components of InfoPath Forms Services that allow form template (.xsn) files to be converted, rendered, and function in the browser 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 based on their contents 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, gets 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 similar way 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 needing 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 entire 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, 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 solve this problem. For more information about using 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 where 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, along 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 way, 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 on using query parameters, see How to: Use Query Parameters to Invoke Browser-Enabled InfoPath Forms.

The Form Template Lifecycle

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

The lifecycle of a form template

Figure 2. Lifecycle of a Form Template

For more information on 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 needed by InfoPath Forms Services to render the form in the XmlFormView control.

Community Additions

ADD
Show:
© 2015 Microsoft