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.

Microsoft.Office.InfoPath.Server.Administration

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.

Microsoft.Office.InfoPath.Server.Controls

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():

[csharp]

XPathNavigator sharepointPro2007Nav = this.MainDataSource.CreateNavigator();

[/csharp]

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:

[csharp]

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

[/csharp]

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:

[csharp]

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);

}

[/csharp]

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:

[csharp]

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”);

break;

case “ProSharePoint2Case”:

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

break;

}

[/csharp]

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:

[csharp]

catch (Exception ex)

{

e.CancelableArgs.Cancel = true;

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

}

[/csharp]

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:

[csharp]

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

[/csharp]

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:

[csharp]

XPathNavigator sharepointPro2007Nav = this.MainDataSource.CreateNavigator();

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

[/csharp]

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

[csharp]

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

[/csharp]

Share

Getting Started With Information Rights Management (IRM) Integration With SharePoint

What is the purpose of Information Rights Management Marriage With SharePoint
Distributing local information through unwanted channels is one of the largest problems that exist within a SharePoint environment. Because SharePoint is meant to provide users with large facilities in order to share and work with arbitrary business data, this can sometimes lead to users sharing information that should otherwise not be shared.

A major method to procure added assurance that will help to eliminate intentional and/or accidental redistribution of sensitive or classified business information is to persistently protect the the business data under multiple circumstances, across multiple environments.

A common incident is when someone sends a piece of confidential information to the wrong person, through a mistake of choosing out of an address book or something similar. These situations are commonplace within an environment that builds out virtual teams focused on collaboration, when sensitive information in business information stored in such mediums such as Microsoft Office documents is easily shared accidentally or intentionally for whatever reason.

These types of information leaks can be costly because of:

  • loss of revenue
  • competitive advantage
  • customer confidence

MOSS is tailored to controls access to various documentation, following usage once the document has been downloaded. For an organization that has to adhere to certain legal / business requirements, this can be an invaluable piece of functionality.

What is Information Rights Management and What Can It Protect?

Information Rights Management (IRM) is a component of the Microsoft Office SharePoint Server and Microsoft Office product suite. Although its base technology derives from Windows Right Management, it has heavy ties into the Microsoft Office product suite, and has direct hooks into the Microsoft Office SharePoint Server system.
IRM allows document authors to specify who can read their document, what they are able to do with the document, and when they are able to do it. IRM can be applied to Outlook e-mails, Word documents, Excel spreadsheets, and PowerPoint presentations (along with others which implement a customized “protector”). While the Microsoft Office SharePoint Server environment is meant to promote collobration of documents between virtual teams, IRM will provide offline methods of working with the arbitrary office documents.
Some of the key features that one should look to implement in an offline protection implementation is:

  • Implement A Protection Scheme That Travels With An Arbitrary File
    • Protection that exists at the file level
    • Protection that will bind and travel with the file, wherever the file goes
  • Controls Access To The Document, and How the Document Can be Used
    • Leverages encryption methods that controls usage
    • Implements usage policies bound to the document that translate to the native client application
    • Expire relevant content when it is deemed no longer necessary
  • The Protection System Should Be Easy For End Users
    • Easy for clients to implement protection for business data
    • Tightly integrated with Microsoft Office clients that in turn are relevant to SharePoint
  • Policies That Are Managed By The Enterprise

    • Permission Policies that are organizational consistent
    • One organizational owns overall access

In a typical SharePoint environment, documents are controlled at a very granular level when stored at the web level, however once a client gets the chance to download the arbitrary document, the overall permission levels are lost. MOSS and IRM work together in order to translate roles on the SharePoint server, to permission levels as they are specified within IRM.

If a SharePoint environment if there is no IRM functionality implemented, documents circulated electronically are uncontrolled and can be printed, copied, and forwarded feasibly to anyone. Transmission of e-mails and documents over secure networks may protect the information in transit, but offer no control over what the recipients do with the information. Password security protection for documents can easily be circumvented if the password is also provided.

IRM can be used to prevent the printing or forwarding of e-mails and to make them inaccessible to the recipient after a specified expiry date. IRM can make documents unreadable by anyone other than the specified recipients.

Deploying Information Rights Management and IRM Requirements
Deployment of Information Rights Management is performed across an organization typically by the server/SharePoint administrator. In addition to installing the Microsoft Office 2003/2007 client software (since these are the default protectors that are provided by IRM), there are some other services and software that need to be installed and configured to support the IRM infrastructure:

  • Microsoft Windows Server 2003 Enterprise Edition (prerequisites for SharePoint)
  • Microsoft Windows Rights Management Server for Windows Server 2003
  • Microsoft Active Directory Services
  • Microsoft Internet Information Services
  • Microsoft SQL Server 2000/2005
  • Microsoft Windows Right Management Client software to be installed on all WFE’s

The relevant server and clients that will be accessing the IRM enabled document repositories need to be loaded with the Rights Management Update for Windows. For the encryption service to function correctly, public and private keys for creators and readers are created when the users enroll to use the Rights Management Service (RMS). Microsoft Office is required to create rights protected documents, or through the MOSS interface, but they can be viewed with other editions of Microsoft Office, or with the IRM add-on for Microsoft Internet Explorer.

By default, when Microsoft Office is installed, IRM is not enabled. Without the additional software listed above, end users will not be able to create rights-protected material even though it is enabled on the MOSS server.

IRM Protection Policies
The policies that RMS will leverage are formulated, enforced and populated by SharePoint or network administrators. After the policy has been established, the client still has to apply the appropriate policy to the document they are sending, by pressing a button and specifying rights that are available for this document. MOSS will translate roles from the site if here is no direct rights bound to the arbitrary piece of documentation.

What are some of the benefits of IRM?
There are several benefits of using IRM for various environments.

  • Documents created with MS Office with IRM are encrypted using Windows RMS (Rights Management Services). Restrictions can then be set to limit recipients’ rights to view, copy, print, and distribute MS Office 2003 documents, including Outlook e-mail messages, and to set a time limit on the readability of the document.
  • Appropriate use of this technology restricts access to records, either by internal or external organizations interacting with a third party, may prevent various organizations from creating, maintaining, and disposing of electronic records in a legal and proper fashion. Furthermore, use of this technology may prevent agencies from producing such records to competent external authorities, such as in response to arbitrary legal requests.
  • An organization can create and enforce a policy to deal with the receipt of MS Office IRM-restricted files sent by internal and external organizational users, in order to ensure such files comply with the accessibility requirements of an arbitrary organization.

Getting Started With the IRM
The reason that most people have trouble with IRM is because the requirements for MOSS can be somewhat rather confusing, however if you make sure, and inventory, all the portions that are required, and ensure that they are properly implemented within your environment, it is a relatively painless procedure. The important portion to gather out of the first steps needed to properly implement IRM is ensure that you meet all of the requirements. The actual process of getting IRM going is relatively painless and you can up in running in about 30 minutes (depending on whether you need to write / implement any custom protectors [the methods by which IRM can actually implement its protection policies]). Obviously, we are not talking about client based rights management, the IRM that we are going to be enabling exists on the server, although will provide hooks into the client portions of IRM.

The first requirement for IRM is you must have a server with IRM enabled, by this I mean a Windows 2003 Server with SP1 or later running Windows Rights Management Services since it provider the backbone framework for the IRM services. Next, since IRM has to somehow be enabled on all of the FWE’s through the web farm, it can be downloaded from here:

http://www.microsoft.com/downloads/details.aspx?familyid=A154648C-881A-41DA-8455-042D7033372B&displaylang=en

This is how your MOSS services will hook into the main IRM server, it provides the functionality that is needed in order for the document libraries that you are using, in essence, to become IRM enabled. As well, for your users to work with the IRM features that are available in an off-line format (those features after a document is downloaded from a document library and is placed in native encrypted format) will need to have the client installed.

Once the prerequisites are defined, and appropriately enabled on all of your servers, you can begin the actual implementation of the service.

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