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.
Angry
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
Stakeholder

 

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!
Share

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


Share