18 New InfoPath Development Articles!

I have finished posting 18 new InfoPath development articles that are available on the main sharepointsecurity.com site for your to browse and learn InfoPath development from, called my “Mastering InfoPath Development Series”. They take you through everything from beginning InfoPath development to building a simple Form WebPart if you don’t have InfoPath available in your environment to use as a design / development tool. I will be extending this series out as I get time, but for those seeking a starting point for InfoPath development, or to maybe pick up some Forms development skills, it should make for some good reading!

If you would like, you can visit the main index of the articles here (note, you will be redirected to the main site using these links):

Mastering InfoPath Development Series Index

Here is the full article index as it appears on the main sharepointsecurity.com site:

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…

Read More

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…

Read More

Introduction To InfoPath Development and The Forms Services Object Model

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…

Read More

Customizing InfoPath Web Service Interaction through Managed Code

One of the most used data connections is a Web Service, and often times the default Web Service connection behavior does not offer the granular level of control that is desired. Since the new InfoPath Object Model is handled through managed code out of the System.Xml namespace, custom web service code can easily be written in order to handle web service consumption on a more granular scale…

Read More

Architecture of the InfoPath Templates (.XSN)

InfoPath templates use several child files and one overlying manifest bundled within an .XSN file. However, there are both packaged and unpackaged InfoPath template states. One of the states is the form template, saved as the bundled .XSN file, which contains all InfoPath source files that although packaged can be extracted using either the InfoPath client or command line operations. Since an .XSN file is basically an archived cabinet file, you can unpackage an .XSN by using the following command…

Read More

InfoPath Form Templates and InfoPath Form Template Parts

When creating a new form in InfoPath, you can create a new template that build out a new packaged .XSN file, or you can build on one of the newer features provided with InfoPath 2007 called a Form Template Part, which instead creates an .XTP file.

Template parts can be loosely compared to User Controls within the Visual Studio IDE. When using template parts, the InfoPath templates that contain controls, datasources, formatting, validation, formatting, rules, and calculations can be reused over and over again without having to keep performing the same redundant tasks…

Read More

Working With InfoPath Controls on the Design Surface and Building a Basic InfoPath Form

he InfoPath design surface provides many methods to build and enhance an InfoPath form with custom actions such as conditional formatting, rules, and other formidable functionality. There are several options available from the control level menu that a developer can leverage to circumvent having to write custom code to achieve certain form tasks. We have already explored how to use a template part in order to build a reusable InfoPath form piece similar to user controls in Visual Studio development that can be dragged onto the InfoPath design surface…

Read More

Managing Data Connections and Universal Data Connection V2 (UDC) Files

InfoPath exposes several external data sources that are available for consumption either as a primary or secondary data connection. Most of the consumed data connections can be called from within the Data Connection Wizard that InfoPath provides. When using the Data Connection Wizard, you can choose to create a new data source for fetching or submitting. In relation to SharePoint, it is possible to crawl a Microsoft Office Server instance to harvest available data connections, by only supplying the site…

Read More

The XmlFormView Control

The XmlFormView control plays the central role in rendering the display to a user in an HTML compatible format. When not using the Forms Service XmlFormControl within a WebPart, it becomes exceptionally difficult to develop a custom solution to render out the InfoPath form. It could be theorized that one could load the InfoPath XML document by calling a StreamReader on the XML contents, go through all the XML contents…

Read More

Event Handling In InfoPath

Within the InfoPath 2007, there is the option to handle events using an item called the Event Manager. Similar to the event receiver architecture provided by other facilities of SharePoint, the Event Manager provides mechanisms by which forms can provide and respond to event capturing. Writing code that is consumed by the Event Manager is done using Visual Studio Tools for Application (VSTA), and when choosing to program events off the InfoPath design surface it will attempt to open the VSTA IDE…

Read More

Deployment Scenarios and Forms Service Security

Deploying an InfoPath form involves examining the type of InfoPath development that was performed, whether the forms you developed were codeless or code-bound. When developing custom forms that don’t hook into any backend business logic, the forms can simply be deployed to the server by an end user for consumption by other organizational units. However, if the .XSN contains backend business logic, a server administrator must intervene in the deployment process in order to deploy the form, providing the vital step of allowing activation of the form before the form is consumed by the user base. Server administrator intervention is also required when other conditions for form deployment are met, namely if the form being deployed requires full-trust…

Read More

Building Forms without Forms Services – Introduction

For some organizations, it is not possible to use Forms Services either as an architectural or budget constraint. Therefore, other avenues of development must be considered when looking to move to a paperless form process with zero footprint form fill-in capabilities. When not using InfoPath and Microsoft Office Forms server, a traditional solution is to build forms using standard WebPart development techniques, submitting the data to either a corporate database or to a SharePoint list for storage…

Read More

Building Forms without Forms Services – Part 1 – Set Up the WebPart Class

Before accomplishing any custom development, the necessary foundational code must be added to the WebPart in order to set it up for inclusion in the SharePoint environment. You must establish the following references (shown in the code listing) in the main WebPartclass file. Doing so allows WebPart class derivation out of the WebPart base class, procures SQL connectivity using ADO.NET 2.0, allows for definition of WebPart attributes, and tolerates the binding of the appropriate user interface controls for final output by an overridden RenderWebPart method…

Read More

Building Forms without Forms Services – Part 2 – Declare Variables, Assign Controls, And Set up Exception Management

Once the class is setup for the Form WebPart, you need to declare relevant variables and instantiate the required controls by overriding the CreateChildControls() method. For the Forms WebPart, which only accepts an ID input, the only required controls are a TextBox control and a new button that is wired to a submission event…

Read More

Building Forms without Forms Services – Part 3 – Setup the Connection to the SQL Server with ADO.NET 2.0

In order to manage the connection to the database and perform relevant database operations, use ADO.NET functionality out of the System.Data.SqlClient namespace. For the Forms WebPart, ADO.NET provides the crux of the operations for database logic.

In order to open a connection to the SQL database, the Forms WebPart can harvest the connection information out of a configuration file by using WebConfigurationManager out of the System.Web.Configuration namespace. By exposing the AppSettings public property, you can return key-value pairs from the configuration file…

Read More

Building Forms without Forms Services – Part 4 -Setup the Validation Controls

The data that is being submitted with the Forms WebPart requires validation before it is committed to the database in order to maintain integrity of the information being stored. Doing validation with WebParts typically occurs in two main ways. One can choose to script a separate method in order to validate the entry by using an option like ServerValidateEventArgs.IsValid against the argument, or the inherent validation controls that ASP.NET 2.0 provides can be called in order to validate the information. Considering software architecture concerns and code bloat as a factor, it is typically preferable to use the inherent ASP.NET 2.0 validation options…

Read More

Building Forms without Forms Services – Part 5 – Wiring The Submission Event

The last portion required for the Form WebPart is getting the actual data into the database by wiring a submission event to the save button declared previously, easily accomplished by calling a stored procedure to accomplish the task. By pursing the option of using stored procedures, the option exists whether to use the native CLR stored procedures or to use a standard T-SQL stored procedures.

Since the submission of the data is relatively straightforward, the Forms WebPart uses three small classes to build extendable business logic…

Read More

Conclusions On Forms Services Development

Using InfoPath 2007 and InfoPath Forms Services within a SharePoint environment is a powerful option to take legacy paper-based form processes and convert them to powerful electronic data entry mechanisms that streamline overall business process while easing overall development efforts. Although there are methods to generate forms for use within SharePoint by developing custom WebParts that contain the relevant .NET controls for data capture and event handling to fetch or submit data to a variety of a data sources, the inherent InfoPath development capabilities make it a lucrative option for form development tasks…

Read More