Overview of the Fluid Application Model in SharePoint Foundation 2010
Summary: Discover how to host applications that are external to Microsoft SharePoint, such as Microsoft Silverlight applications, in Web Parts, and learn about the Fluid Application Model.
Applies to: Business Connectivity Services | Office 2010 | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio
Provided by: Ricky Kirkham, Microsoft Corporation
Contents
Overview of External Application Integration
Different Levels of Development
Critical Elements of the Fluid Application Model
External Application Provider
Create a Hosting Web Part
Development Tasks
Conclusion
Additional Resources
Overview of External Application Integration
Within certain constraints, Web site users who have contributor rights can add to their pages Web Parts that host applications, such as Microsoft Silverlight applications, that are external to Microsoft SharePoint. It can be a great advantage to Microsoft SharePoint Foundation 2010 users to be able to host applications that are in a different domain from the SharePoint Foundation Web application, because many such applications can be hosted on an application server and made available to all Web applications in the farm. SharePoint Foundation 2010 introduces the Fluid Application Model (FAM) to make this scenario possible in a secure way.
The FAM enables administrators to control the permissions of the external applications without unduly restricting the ability of users to add Web Parts hosting these applications to Web Parts pages. When an application conforms to the FAM, the server on which it is installed logs on to the SharePoint Foundation Web application as a distinct type of user known as an application principal. The application's permissions are the intersection of the permissions that the administrator has granted this special user and the permissions of the real user who opened the Web page containing the Web Part that hosts the application. These Web Parts provide development teams with a quick means to integrate non-SharePoint applications into the SharePoint Foundation Web sites.
Typically, if an external server hosts more than one application that is being used in SharePoint Foundation, all such applications would use the same application principal user credentials. You can create different application principal users for each application, but nothing can prevent the server from using any of its application principal users for any of its applications.
Note
An application is external to a SharePoint Foundation Web application (that is, it has a different domain) if the URI of the application's executable differs from the URI of the Web application in any of four ways described in HTTP Communication and Security with Silverlight: Cross-Domain Communication.
Different Levels of Development
The amount of development work to integrate an application into SharePoint Foundation varies depending primarily on these factors.
Whether the application's executable is hosted within the SharePoint Foundation Web application or in some external domain.
Whether the application needs to read and write SharePoint Foundation data.
Whether the default settings governing how the Web Part is rendered need to be changed.
Whether the application needs custom configuration information to run in a SharePoint Foundation Web Part.
Whether a custom UI in SharePoint Foundation is needed to create and edit the properties of the Web Part that hosts the application.
In the simplest cases, the non-SharePoint application is either located within the same domain as the SharePoint Foundation Web application or hosted at an external URL but does not need to access SharePoint data. In either of these situations, there is no required SharePoint development. When the executable is finished, the Web application administrator deploys it to an application server or a document library. Users who add a Web Part that can host a non-SharePoint application are prompted to supply the URL of the executable when they add the Web Part. If the application is locally deployed, it can access SharePoint Foundation data by using the SharePoint 2010 Client Object Model in the context of the current user. (If the external application is a Silverlight application, it uses the special Silverlight client object model.)
If the application will be deployed to a different domain from that of the Web application and if it will need to access SharePoint data, integration requires the use of the FAM.
Critical Elements of the Fluid Application Model
The following are the critical elements in the FAM about which developers need to be aware.
Access to SharePoint Foundation data from an application on an external domain must be enabled by a farm administrator by registering an External Application Provider (EAP), and for security reasons this cannot be done in the SharePoint Foundation UI. Instead, it must be done programmatically. You can include instructions about the required code with your solution or supply a small utility for farm administrators to run. For more information about creating this utility code, see Enabling an External Application Provider later in this article.
Note
The EAP has to be registered only once even when multiple external applications are being used.
You must create some External Application XML markup that gives SharePoint Foundation information it needs about the application. Users who add a Web Part that hosts the application are prompted to supply the markup, so you must make it available to the users. For more information about creating this markup, see Creating External Application XML later in this article.
The farm administrator must create a user identity under which the external application logs on to SharePoint Foundation, and this user must be configured as an application principal. For security reasons, this configuration cannot be performed in the UI. You must provide a utility that assigns values to certain properties of the SPUser object that represents an application that requires cross-domain access to SharePoint Foundation data. For more information about creating this utility, see Creating an Application Principal later in this article. Web site owners who want their contributors to be able to add a Web Part hosting the application must add the application principal as a user on their Web sites.
You must create an HTTP Request Handler that is installed on the external application's domain. Requests from the external application to a SharePoint Foundation Web application are directed first to this handler, which then forwards them, along with a security hash and user credentials, to the SharePoint Foundation front-end Web server. For more information about creating this handler, see Creating an HTTP Request Forwarder later in this article.
The code in the Silverlight application that reads or writes data to the SharePoint Foundation Web application uses a special Silverlight version of the SharePoint Foundation client object model that is implemented in its own client assemblies. For more information about this object model and programming to it, see Using the Silverlight Object Model.
Note
Although the preceding tasks must be done only if the application is in an external domain and it needs access to SharePoint Foundation data, you may want to complete these tasks even if one of the conditions is not met. For example, you may want to use External Application XML to customize the width and height of the Web Part.
External Application Provider
An EAP is a kind of configuration and provisioning engine for Web Parts that host non-SharePoint applications. It interprets the External Application XML, manages the creation of Web Parts that host the application, and manages the editing of the properties of the Web Parts.
A default EAP is used unless a custom EAP is registered. There can be just one EAP for each SPWebService object in the farm. So all external applications hosted in Web Parts in all the Web applications that are children of the same Web service are managed by the same EAP. For more information on SPWebService and Web services, see Services Hierarchy of Microsoft SharePoint Foundation and Background: Service Entities in Microsoft SharePoint Foundation.
You can create a custom EAP and substitute it for the default EAP. Some of the scenarios in which you might want to do this are as follows:
The Web Part that hosts the non-SharePoint application needs a customized Tool Part that users can employ to edit the properties of the Web Part or to do other work. For example, such a Tool Part could open a custom application registration page with a button whose code-behind creates an application principal user for the external application.
The Web Part needs customized chrome.
The external application, or more precisely the request forwarder of the application, needs a client hash so that it can verify that query responses received from the SharePoint Foundation front-end Web server have not been altered. For more information about request forwarders, see Creating an HTTP Request Forwarder later in this article.
The External Application XML for the Web Part needs to contain custom configuration properties.
Custom logic needs to be executed when the Web Part's child controls are created.
For more information about creating a custom EAP, see Creating a Custom External Application Provider later in this article.
Create a Hosting Web Part
A Web Part for hosting Silverlight applications is included in SharePoint Foundation. If you want to host another kind of application in a Web Part, you can derive a new Web Part type from ClientApplicationWebPartBase. For more information about creating a Web Part that hosts a non-SharePoint application, see Creating a Hosting Web Part later in this article.
Development Tasks
Creating External Application XML
External Application XML is markup that provides information to SharePoint Foundation about a Silverlight application that is hosted in a Web Part. The markup is required only if the Silverlight application is hosted on a different domain and accesses data from the SharePoint Web site. It can also be used, although it is not required, whenever an EAP is being used. There are three categories of information in the markup:
Identifying information about the Silverlight application and the application principal name that it uses to get data from the SharePoint Web site.
Information about the Web Part that hosts the external application.
Custom information that can be used by a custom EAP to register the external application.
There is more than one way to assign the markup to a Web Part:
The markup can be assigned to the Web Part in the SharePoint Foundation UI at the time the Web Part is added to a page. If your Silverlight Web Part solution uses that method, you need to provide the markup as a file with instructions to users on how to insert it, possibly with local modifications, by using the UI.
You can also specify the markup as an ApplicationXML property within the Web Part markup of a module in a feature definition (elements.xml) or site definition (onet.xml).
Finally, you can set the ApplicationXml property programmatically in, for example, a FeatureInstalled or FeatureActivated event.
Examples of External Application XML
The following is an example of External Application XML markup. For detailed information about the elements and attributes, see External Application XML. UTF-16 is used as the encoding in this example, but you can use any encoding. The children of the customProperties element can be any XML markup. If you use custom properties, you must create a custom EAP to read and process the custom properties. (See Creating a Custom External Application Provider.)
<?xml version='1.0' encoding='utf-16'?>
<applicationParts xmlns='https://schemas.microsoft.com/sharepoint/2009/fluidapp'>
<applicationPart>
<metaData>
<applicationId>00000000-0000-0000-0000-000000000000</applicationId>
<applicationUrl>https://www.contoso.com/someapplication.xap</applicationUrl>
<principal>domain\username</principal>
<sharepointRequestHandlerUrl>/sp.ashx</sharepointRequestHandlerUrl>
</metaData>
<data>
<webPartProperties>
<property name='Title'>Title</property>
<property name='Description'>Description</property>
<property name='WindowlessMode'>TRUE</property>
<property name='Height'>200px</property>
<property name='Width'>100px</property>
<property name='HelpUrl'>https://www.contoso.com/someapplication/help.aspx</property>
<property name='HelpMode'>Modal</property>
<property name='Direction'>NotSet</property>
<property name='MinRuntimeVersion'>3.0</property>
</webPartProperties>
<customProperties>
<property name='CustomPropertyName'>CustomPropertyInfo </property>
</customProperties>
</data>
</applicationPart>
</applicationParts>
The following is an example of External Application XML inside an AllUsersWebPart element in either an elements.xml or an onet.xml file.
<AllUsersWebPart WebPartZoneID="Top_Right" WebPartOrder="2">
<![CDATA[
<webParts>
<webPart xmlns="https://schemas.microsoft.com/WebPart/v3">
<metaData>
<type name="Microsoft.SharePoint.WebPartPages.SilverlightWebPart, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=94de0004b6e3fcc5" />
<importErrorMessage>Cannot import this Web Part.</importErrorMessage>
</metaData>
<data>
<properties>
<property name="ChromeType" type="chrometype">Default</property>
<property name="Height" type="unit">600px</property>
<property name="Url" type="string" />
<property name="HelpMode" type="helpmode">Navigate</property>
<property name="ApplicationXml" type="string"><?xml version="1.0" encoding="utf-8"?>
<applicationParts xmlns="https://schemas.microsoft.com/sharepoint/2009/fluidapp">
<applicationPart>
<metaData>
<applicationId>00000000-0000-0000-0000-000000000000</applicationId>
<applicationUrl>https://server/ClientBin/SomeApplication.xap</applicationUrl>
<principal>domain\ContosoApp</principal>
<sharepointRequestHandlerUrl>/ReqForwarder.ashx</sharepointRequestHandlerUrl>
</metaData>
</applicationPart>
</applicationParts></property>
<property name="Hidden" type="bool">False</property>
<property name="Title" type="string" />
</properties>
</data>
</webPart>
</webParts>
]]>
</AllUsersWebPart>
Enabling an External Application Provider
A farm administrator must set the ExternalApplicationSettings.Enabled property to true to enable management of external applications by an EAP, including the default EAP. When the property is set, the EAP specified in the ExternalApplicationSettings.Provider property becomes the manager of all external applications in all Web applications within the Web service. Unless the provider has been set to something else, a default provider that is included with SharePoint Foundation is used.
The property cannot be set in the UI, so a farm administrator must do this programmatically. The following shows the C# code. (Note that you must call Update() to persist the change to the configuration database.)
SPWebService.ContentService.ExternalApplicationSettings.Enabled = true;
SPWebService.ContentService.Update();
The farm administrator can use the Windows PowerShellAdd-Type cmdlet to run the code, or you can provide the farm administrator with a utility. In theory, this code could be in a console application, a custom PowerShell cmdlet, the Click event handler for a control on an application page, or any other form of executable code. However, it is probably simplest for the administrator to use Add-Type. The following procedure shows one way to do this, by creating a PowerShell script.
To Create and Run a PowerShell Script that Uses Add-Type to Enable an EAP
Add the following to a text file.
Add-type @" using System; using Microsoft.SharePoint.Administration; namespace ContosoCmdlets public class EAPEnabler { public static void EnableEAP() { SPWebService.ContentService.ExternalApplicationSettings.Enabled = true; SPWebService.ContentService.Update(); } } "@ -Language CsharpVersion3 [ContosoCmdlets.EAPEnabler]::EnableEAP()Save the file as EAPEnable.ps.
Run the script in a PowerShell window.
Creating an Application Principal
For security reasons, administrators cannot add application principals in the SharePoint Foundation UI. Application principals can be created only with code. Typically, the code is in a small console application, but it could be in a custom PowerShell cmdlet, or a PowerShell script that uses the Add-Type cmdlet, or any other executable context.
The code must run in the context of an administrator of the site collection parent of the Web site to which the application principal user is being added.
To Create an Application Principal
Add references to Microsoft.SharePoint.dll to your C# project and a using statement for Microsoft.SharePoint.
Get a reference to the Web site to which the application principal user is being added. The following is an example.
SPSite site = new SPSite("https://localhost"); SPWeb web = site.RootWeb;Create the user object with a call to AddApplicationPrincipal(String, Boolean, Boolean). In this example, the user is given a name that contains a reminder that it represents an external server on which one or more external applications are installed. The two Boolean parameters set the user's AllowBrowseUserInfo and RequireRequestToken properties, respectively, to their recommended values. This ensures that:
The application cannot access user information even if its permission assignments would otherwise allow it to have such access.
The application cannot access the SharePoint Foundation Web application at all unless it is hosted in a Web Part on a page to which a real user has navigated. The application's effective permissions are the intersection of its own permission assignments and the permissions of the real user.
SPUser principal = web.AddApplicationPrincipal("ContosoAppServer", false, true);Important
The name passed to AddApplicationPrincipal(String, Boolean, Boolean), in this case "ContosoAppServer", must be of a user who is already known to the authentication system (for example, a user that already exists in the Active Directory), but who is not already a user in the Web site.
Assign the application principal to a permission level. In this example, the application principal is made a contributor.
SPRoleDefinitionBindingCollection roleDefBindCol = new SPRoleDefinitionBindingCollection(); roleDefBindCol.Add(web.RoleDefinitions.GetByType(SPRoleType.Contributor)); SPRoleAssignment roleAssign = new SPRoleAssignment(principal); roleAssign.ImportRoleDefinitionBindings(roleDefBindCol); web.RoleAssignments.Add(roleAssign);
Creating an HTTP Request Forwarder
Some applications, such as Silverlight, cannot make cross-domain requests. When the application needs to communicate with a server on another domain, its requests must first be sent to the request-forwarding handler, which, of course, is in the same domain as the application. The handler can then repackage the request and send it to the destination in the external domain.
In this situation, a request forwarder must be created. For example, if a Silverlight Web Part hosts a Silverlight application on a different domain from the SharePoint Foundation Web application whose page has the Web Part, and if the application needs to send requests to the Web application, a request-forwarding handler must be created and installed on the domain of the Silverlight application. The URL of the handler is specified in External Application XML when the Web Part is added to a page. For more information about creating this XML, see Creating External Application XML earlier in this article.
Most of the logic needed by the handler is in the RequestForwarder class. The handler class you create is a kind of wrapper around this class.
To Create a Request Forwarding Handler
Add a plain text file to your Visual Studio project and give it an ashx extension.
Add a WebHandler directive to the top of the page. Use the Language and Class attributes to specify the programming language and the class that implements the handler. The following is an example.
<%@ WebHandler Language="C#" Class="ToSharePointForwarder" %>Below this directive, you add code exactly as you would in an ordinary code file. Begin by adding using statements, including one for the Microsoft.SharePoint.Client namespace.
using System; using System.Web; using Microsoft.SharePoint.Client;Add a declaration for your handler class. Because it is an HTTP handler, it must implement the IHttpHandler interface.
public class ToSharePointForwarder : IHttpHandler { }Add an implementation of the IsReusable property. It should simply return false.
public bool IsReusable { get { return false; } }Add an implementation of the ProcessRequest(HttpContext) method. For the most part, your implementation is simply a wrapper around the ProcessRequest() method of the RequestForwarder class. However, you must first add the credentials of the application principal to the request. In this example, a NetworkCredential is constructed from the name and password of the application principal user and the Active Directory domain of that user.
public void ProcessRequest (HttpContext context) { RequestForwarder forwarder = new RequestForwarder(context); if (!String.IsNullOrEmpty(forwarder.Url)) { forwarder.WebRequest.Credentials = new System.Net.NetworkCredential("ContosoSilverlightApp", "&Tu*)2v", "Contoso"); forwarder.ProcessRequest(); } }
Creating a Custom External Application Provider
Creating a custom EAP requires deriving new classes from one or both of two abstract classes:
SPExternalApplicationRequestResult There are two scenarios in which you implement a class derived from SPExternalApplicationRequestResult:
The site and request forwarder where the external application is installed require that all results that it receives from SharePoint Foundation include a client hash that the request forwarder can verify to ensure that the result has not been tampered with.
You want to change the way the SilverlightWebPart, or some custom Web Part that hosts a non-SharePoint application, is rendered; for example, you want to render custom chrome around the Web Part.
SPExternalApplicationProvider You need to implement this class in any of the following scenarios:
Any situation in which you are implementing a class derived from SPExternalApplicationRequestResult.
The External Application XML for the Web Part contains custom markup that needs to be read and processed.
You want special logic to run when the child control of the Web Part is created.
You want to customize the UI of the SilverlightToolPart or change the application registration page that opens when the Configure button on the Tool Part is clicked.
Important
When considering whether to create a custom EAP, keep in mind that there can be only one EAP for all the application-hosting Web Parts in all the SharePoint Foundation Web applications that are children of a given Web service.
To Implement a Request Result Class
In Microsoft Visual Studio 2010, start an empty SharePoint project.
Add a class item to the project.
Set the class to inherit from SPExternalApplicationRequestResult.
If you do not want a client hash, implement the ClientHash property to return null. If you want to include a client hash in the results sent back to the external application, implement the ClientHash property as a wrapper around a private backing field that is a Byte array.
private Byte[] clientHash; public override Byte[] ClientHash { get { return clientHash; } }If you are using a client hash, create a constructor that takes a parameter of type SPExternalApplicationRequestProperties and a second parameter that is a byte array (which represents the client salt). This constructor should use the RequestTokenPrefix property of the SPExternalApplicationRequestProperties object and the byte array as input in creating a client hash value. The byte array must be a value that is provided by server that hosts the external application, and the algorithm used must be the same one that will be used by the external application to create its copy of the client hash. Consider using the classes of the System.Security.Cryptography namespace, such as HashAlgorithm or SHA512Managed. The following is an example. To use the SHA512Managed class as this example does, you must add a using (Imports in Visual Basic) statement for the System.Security.Cryptography namespace to the code file.
public CustomRequestResult() { } public CustomRequestResult(SPExternalApplicationRequestProperties externalAppRequest, byte[] clientSalt) { string prefix = externalAppRequest.RequestTokenPrefix; int nCount = Encoding.Unicode.GetByteCount(prefix); nCount += clientSalt.Length; byte[] bytes = new byte[nCount]; nCount = Encoding.Unicode.GetBytes(prefix, 0, prefix.Length, bytes, 0); for (int i = 0; i < clientSalt.Length; i++) { bytes[nCount + i] = clientSalt[i]; } // Compute the hash value SHA512Managed sha512 = new SHA512Managed(); clientHash = sha512.ComputeHash(bytes); }If the only part of the SPExternalApplicationRequestProperties that your derived class uses is the RequestTokenPrefix property, the constructor could be written to take a String as the first parameter, and calling code (which is the OnApplicationWebPartCreateChildControls(SPExternalApplicationRequestProperties) method discussed in the following procedure) just passes the RequestTokenPrefix property to it. Another option is to design the calling code to create the client hash before it constructs an object of your derived type. In that case, the constructor of the type can be designed to take the hash value itself as a byte array parameter and write immediately to the clientHash backing field.
If you do not want to customize how the Web Part is rendered, implement the GetContentControl(String) method to return null. But if you do want to customize how the Web Part is rendered, implement the method to return a Control that is the sole child control of the Web Part. Typically this is a Literal containing HTML markup.
To Implement an EAP Class
Add a class item to the project.
Set the class to inherit from SPExternalApplicationProvider.
If you want to customize the UI of the SilverlightToolPart, implement the GetRegistrationInformation(SPWeb) method. You can change any of the five properties of the SPExternalApplicationRegistrationInformation object that the method returns. For example, if you wanted to substitute a custom registration page, assign the URL of your custom page to the HyperlinkUrl property. You can use inline, or code behind, of the custom page to provide other services to users. For example, your code could read the Application XML and determine whether it specifies an application principal name. If so, the code determines whether that application principal user exists and, if not, creates it.
The following example changes the name of the button on the page (from "Configure" to "Register"), the instructional text for the button, and the size of the dialog that it opens. It also causes the button to open a custom alternative application registration page. (The default registration page is newslwp.aspx.)
public override SPExternalApplicationRegistrationInformation GetRegistrationInformation(SPWeb web) { SPExternalApplicationRegistrationInformation info = new SPExternalApplicationRegistrationInformation(); info.Description = "To register a Silverlight application (.xap), click Register"; info.DialogHeight = 600; info.DialogWidth = 500; string url = web.ServerRelativeUrl; if (!url.EndsWith("/")) { url = url + "/"; } url += "_layouts/alternateReg.aspx"; info.HyperlinkText = "Register"; info.HyperlinkUrl = url; return info; }If you did not derive a class from SPExternalApplicationRequestResult, you can implement OnApplicationWebPartCreateChildControls(SPExternalApplicationRequestProperties) to simply return null. Otherwise, you must give this method a substantial implementation so that your request result class is constructed and used.
The OnApplicationWebPartCreateChildControls(SPExternalApplicationRequestProperties) method is called by the CreateChildControls method of the Web Part. Specifically, the CreateChildControls method does the following:
Constructs a SPExternalApplicationRequestProperties object from the External Application XML that was used to register the Web Part and from information about the current Web site.
Passes the SPExternalApplicationRequestProperties object to the OnApplicationWebPartCreateChildControls(SPExternalApplicationRequestProperties) method.
Receives an object (derived from SPExternalApplicationRequestResult) that is returned by the OnApplicationWebPartCreateChildControls(SPExternalApplicationRequestProperties) method.
Uses the GetContentControl(String) method of the request result object to obtain the sole child control of the Web Part.
If, for any reason, OnApplicationWebPartCreateChildControls(SPExternalApplicationRequestProperties) returns null, as it does in the default EAP that is built into SharePoint Foundation, the CreateChildControls method needs to render a default child control. This is what the CreateChildControls() method of the built-in SilverlightWebPart does.
Hence, the primary job of your implementation of OnApplicationWebPartCreateChildControls(SPExternalApplicationRequestProperties) is to call the constructor of the class that you derived from SPExternalApplicationRequestResult and return the constructed object. Here are some points to keep in mind the following points when developing your override of the OnApplicationWebPartCreateChildControls(SPExternalApplicationRequestProperties) method:
If the object that you derived from SPExternalApplicationRequestResult has a non-null ClientHash property, OnApplicationWebPartCreateChildControls(SPExternalApplicationRequestProperties) should call the non-default constructor that you created for the class that you derived from SPExternalApplicationRequestResult. OnApplicationWebPartCreateChildControls(SPExternalApplicationRequestProperties) should pass to this constructor the same SPExternalApplicationRequestProperties object that it received as a parameter when it was called.
Even if your request result class does not give a substantial implementation to ClientHash (and hence has only a default constructor), you still need to give the Web Part's CreateChildControls method an SPExternalApplicationRequestResult object so it can call the GetContentControl(String) method. This is why you must implement the OnApplicationWebPartCreateChildControls(SPExternalApplicationRequestProperties) method if you derived a class from SPExternalApplicationRequestResult.
An implementation of OnApplicationWebPartCreateChildControls(SPExternalApplicationRequestProperties) can do other work as well; for example, it can read custom properties in the External Application XML.
In the following example, the overridden OnApplicationWebPartCreateChildControls(SPExternalApplicationRequestProperties) calls the non-default constructor of a class named CustomRequestResult derived from SPExternalApplicationRequestResult . For more about this non-default constructor, see the procedure To Implement a Request Result Class earlier in this article.
public override SPExternalApplicationRequestResult OnApplicationWebPartCreateChildControls( SPExternalApplicationRequestProperties args) { SPExternalApplicationRequestResult reqRes = CustomRequestResult(args, saltFromApplication); return reqRes; }
The process of identifying to SharePoint Foundation your custom EAP is almost the same as the process for enabling an EAP as described in Enabling an External Application Provider. The only difference is that instead of simply enabling an EAP, you construct an object of your EAP type and assign it to the ExternalApplicationSettings.Provider property. The following is an example, where ContosoEAP is a class derived from SPExternalApplicationProvider.
ContosoEAP exAppProvider = new ContosoEAP();
SPWebService.ContentService.ExternalApplicationSettings.Provider = exAppProvider;
SPWebService.ContentService.ExternalApplicationSettings.Enabled = true;
SPWebService.ContentService.Update();
Tip
The line that sets the Enabled property is not needed if external application management has already been enabled for the Web service, but it does no harm. If management has not previously been enabled, including it obviates the need for the procedure in Enabling an External Application Provider. However, the converse is not the case: Even if the default EAP is being used, the management enabling code must be executed.
You have available all the methods for running the preceding lines of code that are mentioned in Enabling an External Application Provider. The following example shows how to run the code with the PowerShell Add-Type cmdlet in a PowerShell script.
To Identify Your EAP to the Web Service
Add the following to a text file.
Add-type @" using System; using Microsoft.SharePoint.Administration; namespace ContosoCmdlets public class EAPIdentifier { public static void IdentifyEAP() { ContosoEAP exAppProvider = new ContosoEAP(); SPWebService.ContentService.ExternalApplicationSettings.Provider = exAppProvider; SPWebService.ContentService.ExternalApplicationSettings.Enabled = true; SPWebService.ContentService.Update(); } } "@ -Language CsharpVersion3 [ContosoCmdlets.EAPIdentifier]::IdentifyEAP()Save the file asEAPIdentify.ps.
Run the script in a PowerShell window.
Creating a Hosting Web Part
If the external application is a Silverlight application, you should use the built-in SilverlightWebPart. Otherwise, you should derive a new Web Part class from ClientApplicationWebPartBase. Typically, your Web Part will have editable properties, so you also need to create a Tool Part for the Web Part.
To Create the Web Part
In Visual Studio 2010, start an empty SharePoint project.
Add a Web Part to the project and open the cs or vb source code file.
Add a using statement (Imports in Visual Basic) for the Microsoft.SharePoint.WebPartPages namespace.
Set your Web Part class to inherit from ClientApplicationWebPartBase, instead of the default WebPart.
Override, as needed, the class constructor, CreateChildControls, and RenderContents methods.
If you want to make it possible for your Web Part to be used with a custom EAP, your CreateChildControls method should do the following:
Call the inherited GetExternalApplicationRequestResult() method.
Call the inherited GetInitParams() method.
Call the GetContentControl(String) method of the SPExternalApplicationRequestResult object returned by the call of GetExternalApplicationRequestResult(), and pass it as a parameter the String returned by the call to GetInitParams().
If no custom EAP has been created and registered with the Web service that contains the Web application, then this series of calls will do nothing.
If the External Application XML of the Web Part includes custom properties, you must create a custom EAP to read them. As part of the process of creating the custom EAP, you implement the OnApplicationWebPartCreateChildControls(SPExternalApplicationRequestProperties) method. For more information about creating a custom EAP, see Creating a Custom External Application Provider.
If your Web Part has editable properties, implement the inherited CreateEditorParts() method to create an object of your Tool Part class. For more information about this class, see the next procedure.
To Create the Tool Part
Add another Web Part to the project.
Set your class to inherit from EditorPart instead of the default WebPart.
Add an implementation of SyncChanges() to read editable properties from the Web Part into editable controls in the Tool Part.
Add an implementation of ApplyChanges() to read values from the controls in the Tool Part and assign them to the properties of the Web Part.
Override, as needed, the CreateChildControls method, RenderContents method, and other members.
Conclusion
The Fluid Application Model, introduced in SharePoint Foundation 2010, enables integration into Web Parts of applications that are external to SharePoint, including Silverlight applications, even if those applications work with SharePoint data but are located outside the domain of the SharePoint installation.