Introduction To InfoPath Development and The Forms Services Object Model

The InfoPath Forms Services functionality is coupled with a set of powerful class libraries that are broken up into two major namespaces which can be found in

  1. %Drive%:
  2. Program Files
  3. Microsoft Office Servers
  4. 12.0
  5. Bin

The following section describes each of these namespaces and the components that they provide.


The administration namespace provides the option to develop routines revolving around common administrative tasks, similar to how the SharePoint administrative namespace exposes classes for managing deployments. The most important class in this namespace is arguably the FormsService class. The FormsService class represents the top level for Forms Service in a web farm. The administration namespace contains various other classes that allow administration operations such as managing form templates, InfoPath related SharePoint Features, Universal Data Connections, and other minor functions. Therefore, you could use the administration namespace for pieces such as the FormTemplate object which denotes a form template that has been uploaded to Forms Services, exposing several levels of Form template interaction and manageability.


This namespace provides access to the relevant InfoPath controls. Notably, this namespace must be referenced in order to call the XmlFormView control, which is used for the rendering of the InfoPath control in a web environment as opposed to rendering within the InfoPath Smart client. This namespace also contains other minor classes that deal with utilizing [Author: The word procure and its derivatives seem inappropriate throughout this chapter.] browser based form rendering.

InfoPath Controls Reference Push or Pull Values

An important concept regarding the use of InfoPath 2007 controls when developing forms is the concept of how controls are referenced, which will effect howdata that is pushed and pulled from an arbitrary InfoPath control is manipulated,. One of the most common examples is to take a sample control, such as an InfoPath ListBox or ComboBox control, and passvalues into the control to populate its contents with a dataset InfoPath controls, unlike traditional controls in .NET, are not referenced directly by using control identifiers, They are instead referenced by binding or pulling related values on the XML nodes on an XmlNode object that represents the control. For example, you might have a TextBox control on the Visual Studio design surface that has programmatic name to reference the control in order to identify the object (see Figure 14.4) that you normally could reference by the identifier. This is different when developing against InfoPath since control reference does not occur directly, but rather the controls are referenced by the XmlNode object that represents the control.

Figure 14-4

Calling Data Out Of an InfoPath Control

Frequently when developing custom InfoPath code you need to call a piece of data out of one of the XML nodes set in the control, in essence selecting a single node from the XMLnode object. In order to pull data out of a control, first call the XPathNavigator (as opposed to using legacy InfoPath 2003 methods such as the XmlDocument class and the SelectNodes method). The XPathNavigator class provides cursor navigation through the provided InfoPath XML node set from the root of the set datasource, so you can perform queries againstdata.. The first task in order to get the data out of an InfoPath control therefore is for you to call the XPathNavigator class by implementing the CreateNavigator() method. The XPathNavigator you should set to the main (primary) data source by using the MainDataSource property to get the DataSource object, which can be set to a variety of secondary datasources if you require it.

Here is the code for setting the DataSource and calling CreateNavigator():


XPathNavigator sharepointPro2007Nav = this.MainDataSource.CreateNavigator();


In order to query data that resides in the InfoPath control, you can use the SelectSingleNode method in order to build an XPath statement to return a Node object that matches the XPath expression, and the Value method out of XPathNavigator you can then use to return the query of the current node value to return a string result. The NamespaceManager property is used in order to resolve any namespace resolutions that are required. You can use the NamespaceManager property to accomplish more XmlNamespaceManager object actions as well, such as adding or deleting namespaces within a form.

Here is the code for returning a value from an XML node:


string value = sharepointPro2007Nav.SelectSingleNode
(“//my:pro2007field”, NamespaceManager).Value;


Similarly, to iterate through all the available nodes, XPathNodeIterator and the Select method can be leveraged. Following, the variable housing the results could simply be passed as an argument to a MoveNext method in order to go through the returned values step by step. Taking it a step further, you could use this strategy to extract a single field as demonstrated in the below code using the Current property out of the System.Xml.XPath namespace, then query the value of the current node using the SelectSingleNode method.

Here is the code for a select method to pass to a MoveNext() method:


XPathNodeIterator pro2007Iteration = nav.Select(“// my:pro2007field”, NamespaceManager);

// Start a while loop against the iteration and implement the MoveNext() method

while (pro2007Iteration.MoveNext())


// Get a current field using the SelectSingleNode method string

pro2007String = pro2007Iteration.Current.SelectSingleNode(“my:myfield”, this.NamespaceManager);



It is also possible for you to set values for an InfoPath control using a switch/case to do minor pattern matching in order to execute an action, such as setting a value by using the SetValue() method.

Here is the code for switch/case setting of node values:


XPathNavigator sharepointPro2007Nav = this.MainDataSource.CreateNavigator(); XPathNavigator sharepointPro2007Node = sharepointPro2007Nav.SelectSingleNode(“//my: sharepointPro2007”, this.NamespaceManager);

switch (sharepointPro2007Node.Value)


case “ProSharePoint1Case”:

sharepointPro2007Node.SetValue(“Pro SharePoint Case Value 1”);


case “ProSharePoint2Case”:

sharepointPro2007Node.SetValue(“Pro SharePoint Case Value 2”);




Furthermore, you can implement some exception handling that can handle canceling save events by using the CanceableArgs property in order to extinguish an attempt at a save event. Putting exception handling into the custom InfoPath code is important since it will trap form logic errors, provide isolation of errors, and increase the overall reliability of the final form. Use the CancelableArgs property to allow the capture of the Save Event which will allow a user to cancel by setting it to true (which is the default as well). In order to display an error to the user, use MessageDetails allowing a string to be thrown to the user informing them of the error so that they can report the problem to you.

Here is the code for some example exception handling:


catch (Exception ex)


e.CancelableArgs.Cancel = true;

e.CancelableArgs.MessageDetails = “The error is:” + ex.ToString();



Setting the Data of an InfoPath Control

A comparable approach to calling out data is required in order to set the fields in an InfoPath control. The XPathNavigator class will allow a cursor into the XML node set, and XPath expression matching occurs, however pushing a specific piece of data is performed by using the SetValue method out of XPathNavigator in order to set the child nodes with the passed in string argument.

Here is the code for setting a control value:


XPathNavigator sharepointPro2007Nav = MainDataSource.CreateNavigator(); sharepointPro2007Nav.SelectSingleNode(“//my:pro2007field “, NamespaceManager).SetValue(“pro2007Value”);


Compiling Frequently Used InfoPath Control Queries

It is important to realize that when you are using the XPathNavigator class and the related XPath expressions, the XPath expressions can be precompiled in order to optimize the code being integrated into InfoPath. For example, if a value is constantly being queried it is possible for you to use the Compile method in order to pass in the XPath query in order to return an XPathExpression object to call the same XPath expression string multiple times. Using the Compile method when coding against InfoPath will result in less bloated code and less development time while developing reusable XPath queries. In the code introduced above where we queried the Pro2007field, it could be optimized if being reused multiple times by adjusting it with the Compile method.

Here is the code for compiling an expression:


XPathNavigator sharepointPro2007Nav = this.MainDataSource.CreateNavigator();

XPathExpression pro2007Exp = sharepointPro2007Nav.Compile(“//my:pro2007field”, NamespaceManager).Value;


Afterwards, the XPathExpression object becomes available which will allow the expression you to pass the object into the SelectSingleNode method.


string value = sharepointPro2007Nav.SelectSingleNode(pro2007Exp).Value; value = sharepointPro2007Nav.SelectSingleNode(pro2007Exp).Value;



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.