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.


InfoPath Development Basics

There are two ways to construct forms for use within a SharePoint environment. The first is to build an InfoPath form and publish it to a SharePoint Form Library. The second is to build a custom WebPart containing the appropriate child controls to collect information from the user and send it into SharePoint via an event handler. Each technique has some advantages and disadvantages, but generally you will find that the InfoPath experience is the easiest and fastest. Furthermore, MOSS directly integrates a new feature called InfoPath Forms Services, which supports users who don’t have the InfoPath Smart Client application installed by supporting form interaction for remote users who only have an appropriate browser installed.

Introduction to InfoPath Forms Services and InfoPath Object Model

Using InfoPath and InfoPath Forms Services over other methods of forms development provides several benefits that greatly extend the power of paperless forms and speed the time to production for a corporate electronic forms solution. Prior to the release of InfoPath Forms Services, InfoPath 2003 as a form development tool used to be frustrating for users, developers, and network engineers for several reasons. Developers were forced to use MSXML (Microsoft XML Core Services) as opposed to traditional .NET XML methods and native development environments were not robust. End-users and network engineers used to need the InfoPath client application in order to open the form to enter and submit relevant data, therefore mandating the required Client Access Licenses. If accessing the form from a separate machine other than one that had the InfoPath Smart Client installed, there was no mechanism by which to natively cast the InfoPath form to an HTML compatible form for remote data entry.

Design Once Programming Paradigm

Leveraging the capabilities of InfoPath Forms Services allows a majority of the Smart Client InfoPath form rendering to be parsed out to a comparable HTML form when the InfoPath client is not discovered on the requesting client machine. The InfoPath 2007 object model supports this by facilitating the Design Once programming paradigm.. By introducing the capabilities of InfoPath Forms Services where forms can be both rendered by the server in a browser as well as on a client machine running the InfoPath client, the option to develop against the InfoPath object model necessitates support for both scenarios of forms rendering. Under normal circumstances, providing the facility of both client and server side rendering would require the use of two separate InfoPath Object Models, one dedicated to form browser rendering and another dedicated to client form rendering. However, the object model in InfoPath 2007 is built to be uniform in that code written against a form will render in both environments, with certain exceptions in regards to particular controls, custom add-in, and custom task pane integration. InfoPath 2003 developers are most likely familiar with the COM-based solution development that InfoPath 2003 depending heavily upon. COM-based development likewise will only render within the InfoPath Smart Client, and not within any of the browser based forms.

The Design Once programming paradigm is supported by a feature in InfoPath 2007 called the Design Checker which allows the verification of form templates targeted for deployment to InfoPath Forms Services by generating information about backward-compatibility for controls and functionality that only renders within the InfoPath Smart Client. You also have the option when designing a new form in InfoPath to Enable Browser browser-compatible features only with the form content being created, which creates a browser complaint form by using only those controls which will parse to a cast HTML form. When designing the new form, you are also afforded the option within the Design Checker settings to point to a Forms Server where the URL can be entered in order to verify the settings.

Once the InfoPath forms designer is aware that the form being developed needs to be browser based, it will run a remote check and allow verification against the server, displaying both errors that occurred and important messages regarding the verification for zero footprint form fill-in.

Development Object Model and Development Tools

The InfoPath 2007 Object Model is fully CLR 2.0 compliant, which negates the interaction of PIA references as required previously and is based off the System.Xml namespace as opposed to MSXML so the .NET XML semantics developers are familiar with can be exploited. The caveat to this of course is if developing a custom InfoPath add-in or TaskPane that is targeting the InfoPath Smart Client the old PIA references need to be used, since the new OM is targeted towards both server and browser rendering.

The introduction of a new object model allows the leveraging of Visual Studio Tools for Applications (VSTA) or Visual Tools for Office (VSTO) IDE’s in order to develop managed code for custom forms. In short, VSTO enables a .NET project to use Office functionality, such as manipulating Word or Excel documents. VSTA enables an Office application (or any other app that incorporates VSTA) to use .NET code for customization. Typically, a customized InfoPath 2007 form will use VSTA coding which is why when using the programmability options within InfoPath VSTA can quickly be brought up under the programming menu or by selecting ALT+SHIFT+F12 (See Figure 14-10).

Figure 14-10

VSTO and VSTA are very similar development environments; however VSTA is a branched project off of VSTO. VSTO was designed for managed code development to construct various types of extensions for Office application consumption. VSTA extends the concepts that are presented in VSTO with the option to develop unmanaged, as well as managed code. Since VSTO is specific for building extensions for Office applications, if planning development environments for building applications besides Office extensions, VSTA would be a wise decision since VSTA leverages the Managed Add-in Framework (MAF) as its core engine. Using VSTO will allow you to host InfoPath development elements directly in your Visual Studio IDE, and allowing the creation of Form Template Projects if it is a known requirement that there is going to be custom backend business logic.

It is not necessary to choose just either VSTO or VSTA, VSTO is a subset of VSTA, consequently when using VSTO you can still leverage VSTA, therefore it is up to the developer to choose which track is appropriate for their purpose given that both still support both Smart Client and browser targeted form rendering.


Mastering InfoPath Development Series Introduction

Building business forms is an intrinsic part of architecting a serviceable collaboration environment that accentuates user interaction into overall business operations. Forms and the data that is entered into them build the backbone of most internal and external enterprise processes for organizations, regardless of industry background. One of the most frequent requests of any collaborative environment is to procure circumstances where normally endless paper, human-oriented processes are optimized and an environment that procures methodized, controlled, and manageable paper-less forms are introduced to speed user interaction, couple with intuitive workflows, fetch and push data between various types of data sources, and improve custom form time to production. The benefits of leveraging paperless forms are vast, ranging from cost benefits to flexible deployment and usability options. Form distribution fees and production costs are eliminated, capturing and routing become automated by the collaboration environment, forms can be audited for non-repudiation legal purposes, and robust levels of forms storage and pipeline security can be implemented.

InfoPath 2007 and Office SharePoint Server 2007 running InfoPath Forms Services, or a separately purchased Microsoft Office Forms Server (OFS 2007) platform, procure a bridge between the Information Worker whom is most aware of the organizational form content and process involvement, to the developer who can enhance and automate form activities, to the systems architect who is responsible for maintaining the form platform and tangible form maintenance.
Typical business form development can prove tend to be convoluted because a considerable quantity of conventional business forms are specialized in intent, often times the solitary persons whom are aware of how data should be inputted, manipulated, and stored is not an avid member of the development team. Empowering the set of stakeholders involved in the forms development process with the tools to help communicate needs to tangible deliverables, and deliverables to organizational systems will procure numerous benefits for an organization, increasing the overall quality and usability of the end product.
Stakeholders in the Form Development Process


Using Forms Services


For The Information Worker


Allow an integrated design environment where form controls can be easily added to a layout page, capturing the most beneficial user design while maintaining an uncomplicated, effortless form development and design surface.


For The Developer


Inherent functionality to bind form controls to various data sources and control basic form behavior. Allowance of backend managed code to tap into new InfoPath Object Model in order to create more complex form behavior using C# or VB.NET through the use of Microsoft Visual Studio Tools for Applications (VSTA) or Microsoft Visual Studio Tools for Office (VSTO). Support for native scripting languages such as Jscript and VBscript through the Microsoft Script Editor (MSE) for customizing other form attributes to be bundled with form template packages.


For the Systems Architect


Ease control over deploying custom forms to a SharePoint environment with a granular, defined publishing model. Exert forms jurisdiction over pieces that tap into custom business logic by allocating the task of activating such forms as an administrative task. Allow forms to be updated even while SharePoint users are entering in data, decreasing the amounts of service disruptions and increasing quality of data retrieval. Provide forms administration through familiar SharePoint STSADM command line interaction.


Throughout this series, I will introduce you to how to construct robust, extendable forms using InfoPath 2007. The constructed forms will then be able to employ InfoPath Forms Services in order to increase the reach of the form through its zero footprint form fill-in technology, allowing even users without the InfoPath Smart Client installed to utilize the InfoPath forms. As you’ll see shortly, you will exploit powerful development approaches that can immediately be put to work in your environment through the native InfoPath design surface and through custom managed code. The presented strategies include several sections of inherent InfoPath functionality as well as demonstrations of how to hook in custom logic written in managed C# code. For those developers who don’t have InfoPath 2007 as a development platform, for those developing forms solely on the Windows SharePoint Services V3 platform or not having the Enterprise Features of MOSS enabled, we will also explore how to use native WebPart development to build forms that can achieve the same goal as developing when using InfoPath 2007.
We will also walk through the architecture of InfoPath forms and InfoPath forms services. You will become familiar with the pieces that build up an InfoPath form and related pieces of technology that are important to an InfoPath forms developer. Since InfoPath FormsServices provides the foundational serving mechanism, we will also examine the core components that construct this service, and how exactly the rendering components of InfoPath Forms Services can expand the reach of custom built forms.
So warm up Visual Studio, strap on your seat belts, and let’s start developing!