Architecture of InfoPath Forms Services Browser Interaction

InfoPath Forms Services relies on the InfoPath 2007 client application for forms development, VSTO or VSTA to tap into the InfoPath Object Model exposed from Microsoft.Office.InfoPath, and either a standalone OFS 2007 instance or Microsoft Office SharePoint Server 2007 with Enterprise Features enabled to make use of Form Services. InfoPath Forms Services, although offered as a separate product, is directly integrated into the Office Server 2007 platform and even when OFS is a siloed installation will make use of WSSv3 components which allows Forms Server 2007 to provide powerful benefits. The most important function that InfoPath Forms Services presents is the option to cast an InfoPath form to HTML for users without the InfoPath Smart Client installed. This is accomplished using a basic four-step process. For conceptual purposes steps such as run-time data connection establishment through UDC’s and other small scope activities are left out in order to present the larger operational process.

Fundamental Browser Form Rendering Process




Description of Resulting Process


User Requests Form


When a user first requests an InfoPath .XSN (form template or InfoPath Solution File) hosted in a SharePoint Form Library, it will check whether the client InfoPath Smart Client application is installed on the client machine, if it is the client to display the form.


User Does Not Have InfoPath Installed


If the user does not have InfoPath installed, the InfoPath Forms converter is called and the user is redirected to the FormServer.aspx page by use of the InfoPath Forms Services HTTP Handler (using the xdEnvironment::IsBrowser() global function)


User Is Found On Mobile Device


If the user is on a mobile device, the InfoPath Forms converter is called and the user redirects to the MobileFormServer.aspx page by use of the InfoPath Forms Services HTTP Handler. (using the xdEnvironment::IsMobile() global function


Form Conversion


Using the FormsServices converter component, the XSN file is broke down into its source files. The source files include the manifest.XSF, .XSD schema files, template.xml files, and view XSL files. These files are then used on the server to output the relevant XML, ASPX, and Jscript files required for browser based rendering contained by the XmlFormView control (derived out of the Microsoft.Office.InfoPath.Server.Controls namespace as you will see shortly)


The backend data process during submission when using InfoPath Forms Services is drastically different than data process when submitting through the use of the InfoPath Smart Client. When entering and submitting data through the InfoPath Smart Client, the data set that InfoPath pushes is pushed as the complete XML set. Within the browser environment provided by the Forms Services XmlFormView control, there is a constant event log whenever a user is submitting data in order to promote an environment to accomplish activities such as formatting and validation controls through DOM scripting languages such as Jscript. Before data is submitted to its final destination source by a browser based form, the event log that is being captured is verified against the server through the use of AJAX(Asynchronous JavaScript and XML) methods, and lastly the XML submission occurs. Periodically, data is sent back to the server in order to increase the performance of the forms rendering page, otherwise the amount of data being captured on the client machine would become unmanageable and decrease the performance of the browser based forms page heavily.