SharePoint 2010 Cross-Farm Services And External Data Sources

There are several steps involved in the process of deploying cross farm services. Each step is very important to gain the overall results you are after.

Configuration of trusted farms ensures all of the farms that use exchanges can trust each other. Certificates have to be exported to a file. Make sure you back up that file before you connect to any of the cross farm services. Publishing service applications must be done before you will be able to successfully share it across farms. Connecting cross farm service applications provides a connection must be made to a service that is published by a remote farm. This will require the URL to be entered of the published service. This is going to be displayed when you publish it. The connection on the local farm has to be created so that it can be connected successfully to a service application for a remote farm.

Should there be two domains where the server farms are located, the User profile service application will require both of them to trust each other. With the Business Data Connectivity and Secure Store Service the domain of the publishing farm has to trust that of the consuming farm. None of the cross farm service applications are going to work if there isn’t a trust requirement in place for the two domains.

It is possible for certain service applications to access external data sources. This occurs through the access of a delegated Windows identity that will place some additional requirements on a given environment. These types of service applications have to be in the same domain as the SharePoint Server 2010 farm. This is where the service applications are housed. The other option is for the service application to be configured using the Secure Store Service.There are plenty of different service applications that can be found across the external data. They use a delegated Window identity. This includes:

  • Excel Services
  • InfoPath Forms Services
  • PerformancePoint Services
  • Visio Services

The service applications used to access external data sources must have a delegated Windows identity. Otherwise it has to be configured for the use of the Secure Store Service. This will store and maintain the credentials of a user or a service. When service applications are used to store credentials, they have to be authenticated before the data can be accessed.

If the external data sources aren’t within the same domain then authentication for the external data sources will fail unless you use the Secure Store Service. Farm servers can be split between two different domains but the application servers have to be found in the same domain as the external data sources.

There are several service applications and products that don’t have those requirements. They include:

  • Access Services
  • Business Data connectivity Services
  • Microsoft Business Connectivity Services
  • Microsoft Project Server 2010
  • Microsoft SQL Server PowerPivot for Microsoft SharePoint
  • Microsoft SQL Server Reporting Services
Share

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.

Forms Services solves one of the largest issues that was present in environments trying to leverage a hybrid InfoPath and SharePoint solution, where users attempting to access InfoPath forms required the InfoPath Smart Client to be installed on the requesting machine in order to input relevant data. The introduction of the XmlFormView control provided by InfoPath Forms Services allows HTML rendering of InfoPath forms either within SharePoint WebPart pages or using a custom SharePoint WebPart, allowing InfoPath forms to be accessed from any machine, regardless of available form software.

Using Design Once programming principles split object models aren’t necessary for developing forms that will render in both the InfoPath Smart Client as well as casting the form to a browser, programming intuitive forms that are environment agnostic is a straightforward task. Benefiting from integration with the System.Xml namespace, integration with powerful IDE’s such as VSTA, many familiar programming concepts and semantics are available when developing tailored, impressive electronic forms targeting the Forms Services platform.

Several types of data sources can be assimilated into the InfoPath Forms environment when using InfoPath 2007, such as Web Services or Databases, all of which can be customized further through the use of managed code. Using the inherent Data Connection Libraries that SharePoint provides allows the option to store UDC’s that are being used throughout a Forms environment to be managed in one central location and called by forms at run-time, allowing the backend connection plumbing to be hidden from users that are consuming various connection types from InfoPath.

Using the Events Manager allows the capturing of three types of events, Form events, Xml events, and Control events. Using custom code to manage these events allows the granular options which allow you to heavily control user interaction with the form in regards to event trapping and management. Calling these events can be done through the design surface control menu in the InfoPath Forms Designer, or by registering the event capturing the InternalStartup() method.

Using InfoPath Forms Services requires some consideration in the terms of security and deployment. There are three main security settings for forms, full-trust, domain, and restricted, each with their own implications that must be considered. Most importantly, administrators must approve forms that are tapping into backend business logic since they require full-trust. When deploying forms, there are certain steps that must be followed to successfully deploy a form, from initial publishing of the form to activating the form to make it available to various site collections.

Forms Services is one of the most powerful features that has been released based off the SharePoint platform. Because forms build the interface to enterprise data operations, automating forms through electronics process greatly increases overall organizational operations efficiency and procures an environment that can highlight end-user interaction into how the forms development process should develop and grow.

Share

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