Traduction

Cet article est la traduction la plus fidèle possible de l'article original de Steve Peschka, The Claims, Azure and SharePoint Integration Toolkit Part 3.

Introduction

Ceci est la troisième partie d'une série en six parties sur le CASI (Claims, Azure and SharePoint Integration) Kit.

  • Partie 1 : une introduction présentant une vue d'ensemble de l'intégralité du « framework » et de la solution, et qui décrit ce que la série va tâcher de couvrir.
  • Partie 2 : la partie « instructions et lignes directrices » du CASI Kit. Cela commence par faire de WCF le « frontend » pour toutes vos données - cela pourrait être des jeux de données, du XML, des classes personnalisées ou tout simplement de l'HTML. Dans la première phase, nous prenons votre service WCF standard et en faisons un service prenant en charge les revendications - c'est ce qui nous permet de prendre le jeton d'utilisateur de SharePoint et de le transmettre, indépendamment des limites des applications ou des centres de données, vers nos applications WCF personnalisées. Dans la deuxième phase, j'éplucherai la liste de toutes les choses à effectuer pour faire passer cette application WCF classique de « hébergée en local » à « hébergée dans Windows Azure ». Une fois cela terminé, vous aurez le « backend » en place pour assurer une prise en charge multi-applications, multi-centres de données avec l'authentification intégrée.
  • Partie 3 : décrit l'assembly de la trousse d'outils personnalisé qui fournit « le ciment » pour connecter votre application WCF prenant en charge les revendications dans le cloud et votre ferme SharePoint. J'expliquerai comment utiliser cet assembly, je parlerai du contrôle personnalisé plutôt simple que vous devez créer (environ 5 lignes de code) et comment vous pouvez l'héberger dans une page du répertoire « _layouts » comme moyen de récupérer et d'effectuer le rendu des données dans un web part. L'intégralité du code source de l'exemple de contrôle personnalisé et de la page « _layouts » sera également publiée.
  • Partie 4 : le web part que j'inclus dans le CASI Kit. Il fournit une solution sans code, prête à l'emploi, qui vous permet de vous raccorder et de vous connecter à une requête asynchrone côté client pour récupérer des données à partir de votre service hébergé dans le cloud, et de les afficher ensuite dans le web part. Il dispose également « d'accroches » intégrées afin que vous puissiez le personnaliser un peu et utiliser vos propres fonctions JavaScript pour effectuer le rendu des données.
  • Partie 5 : un bref examen de quelques exemples d'applications qui illustrent quelques autres scénarios pour utiliser le contrôle personnalisé que vous aurez construit dans la troisième partie dans d'autres cas de figures communs. L'un de ces scénarios utilisera le contrôle pour récupérer certains types de données utilisateur ou de données de configuration et les stocker dans le cache ASP.NET, puis les utiliser dans un web part personnalisé. L'autre scénario utilisera le contrôle personnalisé pour récupérer des données d'Azure et de les utiliser dans une tâche personnalisée ; dans le cas présent, un travail du minuteur SharePoint personnalisé. L'intégralité du code source de ces exemples d'applications sera également publiée.
  • Partie 6 : article complémentaire contenant quelques conseils sur l'utilisation de SQL Azure afin que vous puissiez l'intégrer facilement et rapidement dans vos projets de développement SharePoint 2010 avec Windows Azure.

Le CASI Kit : Partie 3 - L'assembly personnalisé

La première partie de cette série présentait une vue d'ensemble de l'intégralité du « framework » et de la solution, et décrivait les objectifs de chacun des articles de la série. Dans la deuxième partie de la série nous avons vu comment créer et utiliser une application WCF personnalisée comme « frontend » pour vos données et du contenu, comment faire pour la rendre capable de prendre en charge les revendications, et finalement comment la modifier pour la transférer vers et l'intégrer à Windows Azure.

Dans cet article, je vais discuter de l'un des livrables les plus importants du « framework », une classe de base de contrôle personnalisé que vous utilisez pour effectuer votre connexion de SharePoint à votre application WCF hébergée dans Windows Azure. Voici les éléments que nous allons aborder :

  • la classe de base - à quoi elle correspond et comment l'utiliser dans votre projet ;
  • une page de dispositions - comment ajouter votre nouveau contrôle à une page du répertoire « _layouts » ;
  • des propriétés importantes - une discussion de quelques-unes des propriétés importantes à connaître dans la classe de base.

La classe de base du CASI Kit

L'un des principaux livrables du CASI Kit est la classe de base pour un contrôle personnalisé qui se connecte à votre application WCF et envoie des requêtes en utilisant le jeton de connexion de l'utilisateur actuel. La classe de base proprement dite est un contrôle serveur ASP.NET standard, et l'implémentation de ce modèle de développement exige que vous construisez un nouveau contrôle serveur ASP.NET qui hérite de cette classe de base. Pour des raisons qui dépassent le cadre de cet article, votre contrôle devra effectivement pouvoir faire deux choses :

  1. Créer une référence de service à votre application WCF hébergée dans Windows Azure.
  2. Substituer la méthode ExecuteRequest de la classe de base. Ceci est actuellement plutôt simple parce que tout ce qu'il vous suffit est d'écrire environ cinq lignes de code où vous créez et configurez le proxy qui va se connecter à votre application WCF, et ensuite d'appeler la méthode ExecuteRequest de la classe de base.

Pour entamer cela, vous pouvez créer un nouveau projet dans Visual Studio et choisir le projet de type « Bibliothèque de classes Windows ». Après avoir modifié l'espace de noms et le nom de classe en ce qui vous convient, vous allez ajouter une référence à la classe de base du CASI Kit, qui se trouve dans l'assembly AzureConnect.dll. Vous allez également devoir ajouter des références aux assembly suivants : Microsoft.SharePoint, System.ServiceModel, System.Runtime.Serialization et System.Web.

Dans votre classe de base, ajoutez une instruction using pour Microsoft.SharePoint, puis modifiez votre classe de sorte qu'elle hérite de AzureConnect.WcfConfig. WcfConfig est la classe de base qui contient l'intégralité du code et de la logique pour se connecter à l'application WCF, pour incorporer toutes les propriétés afin d'ajouter de la flexibilité à l'implémentation et d'éliminer le besoin d'avoir recours à toutes les modifications web.config typiques qui sont normalement nécessaires pour se connecter à un point de terminaison de service WCF. Il est important de comprendre ceci - vous auriez généralement besoin d'ajouter près d'une centaine de lignes de modifications web.config pour chaque application WCF à laquelle vous vous connectez, pour chaque fichier web.config de chaque serveur, pour chaque application Web l'ayant utilisé. La classe de base WcfConfig enveloppe tout cela dans le contrôle proprement dit, donc, il vous suffit d'hériter du contrôle et il fait le reste pour vous. Toutes les propriétés qui doivent, toutefois, être modifiées dans le fichier web.config peuvent l'être également dans le contrôle WcfConfig, parce qu'il expose les propriétés de l'ensemble d'entre elles. J'approfondirai ce point dans la section consacrée aux propriétés importantes.

Parce que vous aurez besoin d'enregistrer ce contrôle dans le Global Assembly Cache (GAC), vous devez ajouter une clé qui sera utilisée pour signer l'assembly et lui donner un nom fort. Comme pour n'importe quel projet Visual Studio, vous pouvez le faire dans les Propriétés de projet, en cliquant sur l'onglet « Signature ». Il est temps à présent d'ajouter une nouvelle référence de service à votre application WCF hébergée dans Windows Azure. Il n'y a rien de spécifique au CASI Kit qui a besoin d'être effectué ici. Faites simplement un clic droit sur « Références » dans votre projet et sélectionnez « Ajouter une référence de service ». Indiquez l'URL vers votre application WCF Azure en spécifiant « ?WSDL » à la fin, de sorte qu'elle récupère le WSDL correspondant à votre implémentation de service. Modifiez ensuite le nom en ce que vous voulez, ajoutez la référence et cette partie est finie.

À ce stade, vous disposez d'une classe vide et d'une référence de service à votre application WCF. Passons maintenant à la partie écriture de code, qui est heureusement plutôt courte. Vous devez substituer la méthode ExecuteRequest, créer et configurer le proxy de la classe de service, puis appeler la méthode ExecuteRequest de la classe de base. Pour simplifier, voici le code complet de l'exemple de contrôle que je joins à cet article ; j'ai surligné en jaune les parties que vous devez modifier pour qu'elles correspondent à votre référence de service :

 
Sélectionnez
using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Diagnostics;

using Microsoft.SharePoint;

 

//requires References to:

//1. AzureConnect

//2. Microsoft.SharePoint

//3. System.ServiceModel

//4. System.Runtime.Serialization

//5. System.Web

 

namespace AzureWcfPage

{

    public class WcfDataControl : AzureConnect.WcfConfig

    {

 

        //this method must be overridden so the proxy can be

 //configured and created correctly

        public override bool ExecuteRequest()

        {

            try

            {

                //create the proxy instance with bindings and endpoint the base class

                //configuration control has created for this

                CustomersWCF.CustomersClient cust =

                    new CustomersWCF.CustomersClient(this.FedBinding,

                     this.WcfEndpointAddress);

 

                //configure the channel so we can call it with

                //FederatedClientCredentials.

                SPChannelFactoryOperations.ConfigureCredentials<CustomersWCF.ICustomers>

                     (cust.ChannelFactory,

                     Microsoft.SharePoint.SPServiceAuthenticationMode.Claims);

 

                //create a channel to the WCF endpoint using the

  //token and claims of the current user

                CustomersWCF.ICustomers claimsWCF =

                    SPChannelFactoryOperations.CreateChannelActingAsLoggedOnUser

                    <CustomersWCF.ICustomers>(cust.ChannelFactory,

                     this.WcfEndpointAddress,

                    new Uri(this.WcfEndpointAddress.Uri.AbsoluteUri));

 

                //set the client property for the base class

                this.WcfClientProxy = claimsWCF;

            }

            catch (Exception ex)

            {

                Debug.WriteLine(ex.Message);

            }

               

            //now that the configuration is complete, call the method

            return base.ExecuteRequest();

        }

 

    }

}

Voilà donc - fondamentalement cinq lignes de code, et vous pouvez simplement copier et coller directement le code de la substitution d'ExecuteRequest indiquée ici dans votre propre substitution. Une fois cela effectuée, vous n'avez plus ensuite qu'à remplacer les parties surlignées en jaune par la classe et les interfaces appropriées exposées par votre application WCF. Dans le code surligné ci-dessus :

  • CustomersWCF.CustomersClient : « CustomersWCF » est le nom que j'ai utilisé lorsque j'ai créé ma référence de service, et « CustomersClient » est le nom de la classe que j'ai exposée via mon application WCF. Le nom de la classe dans mon WCF n'est qu'en fait « Customers ». Les outils « Ajouter une référence de service » de VS.NET ajoute la partie « Client » à la fin.
  • CustomersWCF.ICustomers : « CustomersWCF » est identique à ce qui est décrit ci-dessus. « ICustomers » est l'interface que j'ai créée dans mon application WCF et qui est en fait implémentée par ma classe « Customers » WCF.

C'est tout - c'est tout ce que vous avez à écrire comme code pour établir la connexion vers votre application WCF hébergée dans Windows Azure. Espérons que vous serez d'accord que c'est plutôt facile. Pour une petite mise en contexte, le code que vous avez écrit est ce qui permet de passer l'appel de l'application WCF avec le jeton de l'utilisateur SharePoint. Ceci est expliqué avec davantage de détails dans cet autre article que j'ai écrit : http://blogs.technet.com/b/speschka/archive/2010/09/08/calling-a-claims-aware-wcf-service-from-a-sharepoint-2010-claims-site.aspx.

Maintenant que le code est complet, vous devez veiller à inscrire tant la classe de base que votre nouveau contrôle personnalisé dans le Global Assembly Cache (GAC) de chaque serveur où il sera utilisé. Cela est évidemment facile à accomplir avec une solution SharePoint. Le contrôle étant terminé et inscrit, il est temps de jeter un œil sur comment l'utiliser pour récupérer des données et effectuer leur rendu. Dans le CASI Kit, j'ai essayé de traiter trois scénarios principaux relatifs à l'utilisation de données Azure :

  1. rendu de contenu dans une page SharePoint en utilisant un web part ;
  2. récupération des données de configuration a être utilisées par un ou plusieurs contrôles et stockage de ces données dans le cache ASP.NET ;
  3. récupération de données et leur utilisation dans des exécutables de type tâche, par exemple un travail du minuteur SharePoint.

Le premier scénario est probablement celui qui est le plus généralisé, c'est pourquoi nous allons l'aborder en premier. La chose la plus facile à faire, une fois que cette méthodologie fut mappée, aurait été de simplement créer un web part personnalisé qui effectue tous ces appels durant un événement Load ou quelque chose du genre, de récupérer les données et d'effectuer leur rendu sur la page. Cependant, cela serait selon moi une énorme erreur. En enveloppant ce code dans le web part proprement dit, de sorte qu'il s'exécute côté serveur durant le traitement d'une demande de page, cela peut considérablement ralentir l'ensemble du débit de la ferme. J'avais de sérieux réserves quant à l'idée d'avoir un ou plusieurs web parts sur une page, qui effectuent un ou plusieurs appels latents parmi les applications et les centres de données afin de récupérer des données, et je pouvais très facilement imaginer un scenario où une utilisation intensive pouvait littéralement mettre à genou l'ensemble d'une ferme. Toutefois, il y a cette nécessité que du code doit s'exécuter sur le serveur, parce qu'il est requis pour configurer le canal vers l'application WCF afin d'envoyer le jeton d'utilisateur avec la requête. Ma solution a ce problème en est revenue à deux parties :

  1. Une page personnalisée hébergée dans le dossier « _layouts ». Elle contiendra le contrôle personnalisé que nous venons d'écrire ci-dessus et effectuera le rendu des données renvoyées à partir de l'appel WCF.
  2. Un web part personnalisé qui n'exécute aucun code côté serveur, mais qui utilise à la place du JavaScript et du jQuery pour appeler la page dans le dossier « _layouts ». Il lit les données qui ont été renvoyées à partir de la page, puis les transmet à une fonction JavaScript qui, par défaut, effectuera simplement le rendu du contenu dans le web part. Bien sûr, il est possible de faire bien plus de choses dans le web part, mais j'examinerai le web part plus en détails dans le prochain article. L'essentiel, toutefois, est que lorsqu'un utilisateur demande la page, son traitement est effectué sans avoir à effectuer d'appels latents supplémentaires à l'application WCF. À la place, la page passe par le pipeline de traitement et parvient de manière prompt et directe dans le navigateur de l'utilisateur. Ensuite, une fois que la page est entièrement chargée, l'appel est effectué pour récupérer uniquement le contenu WCF.

La page de dispositions

La page de dispositions qui va héberger votre contrôle personnalisé est effectivement très simple à écrire. J'ai fait le tout dans le Bloc-notes en l'espace d'environs cinq minutes. Espérons qu'il en sera de même, voire plus rapide, pour vous, car je vais simplement copier et coller ici ma page de dispositions, et vous montrer ce que vous devez remplacer dans votre page.

 
Sélectionnez
<%@ Page Language="C#" AutoEventWireup="true" Inherits="Microsoft.SharePoint.WebControls.LayoutsPageBase,Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" MasterPageFile="~/_layouts/simple.master" %>

 

<%@ Assembly Name="Microsoft.SharePoint.ApplicationPages, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%>

<%@ Import Namespace="Microsoft.SharePoint.ApplicationPages" %>

<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<%@ Import Namespace="Microsoft.SharePoint" %>

<%@ Assembly Name="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

 

<%@ Assembly Name="AzureConnect, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c0b51bd3d3b33212"%>

<%@ Register Tagprefix="AzWcf" Namespace="AzureWcfPage" Assembly="AzureWcfPage, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f0ed63b2f4046026" %>

 

 

<asp:Content ID="Content1" ContentPlaceHolderId="PlaceHolderPageTitle" runat="server">

    <SharePoint:EncodedLiteral ID="wcfConnectPageTitle" runat="server" text="Azure Wcf Connect Page" EncodeMethod='HtmlEncode'/>

</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderId="PlaceHolderPageTitleInTitleArea" runat="server">

    <SharePoint:EncodedLiteral ID="wcfConnectPage" runat="server" text="Azure Wcf Connect Page" EncodeMethod='HtmlEncode'/>

</asp:Content>

<asp:Content ID="Content3" ContentPlaceHolderId="PlaceHolderSiteName" runat="server"/>

<asp:Content ID="Content4" ContentPlaceHolderId="PlaceHolderMain" runat="server">

    <AzWcf:WcfDataControl runat="server" id="wcf" WcfUrl="https://azurewcf.vbtoys.com/Customers.svc" OutputType="Page" MethodName="GetAllCustomersHtml" />

</asp:Content>

Une fois encore, l'implémentation de la page proprement dite est vraiment plutôt simple. Tout ce qu'il y a absolument à changer c'est le nom fort de l'assembly pour votre contrôle personnalisé. Aux fins d'illustration, j'ai également surligné quelques-unes des propriétés de la balise de contrôle proprement dite. Ces propriétés sont spécifiques à mon service WCF, et peuvent être modifiées et, dans certains cas, entièrement supprimées de votre implémentation. Les propriétés seront abordées plus en détail ci-dessous. Une fois la page de dispositions créée, elle doit être distribuée au répertoire « _layouts » de chaque serveur « frontend » Web de votre ferme SharePoint. À ce stade, elle peut être appelée à partir de n'importe quel site, dans n'importe quelle application Web prenant en charge les revendications au sein de votre ferme SharePoint. Évidement, vous ne devriez pas vous attendre à ce qu'elle fonctionne dans un site d'authentification classique, tel que l'Administration centrale. Une fois que la page a été déployée, elle peut alors être utilisée par le web part du CASI Kit, qui sera décrit dans la quatrième partie de cette série.

Propriétés importantes

WcfConfig contient deux grandes catégories de propriétés - celles pour configurer le canal et la connexion à l'application WCF, et celles qui configurent l'utilisation du contrôle proprement dit.

Propriétés WCF

Comme décrit précédemment, toutes les informations de configuration de l'application WCF qui sont normalement contenues dans le fichier web.config ont été encapsulées dans le contrôle WcfConfig. Toutefois, quasiment la totalité de ces propriétés sont exposées de manière à ce qu'elles puissent être modifiées en fonction des besoins de votre implémentation. Deux exceptions importantes sont la version de sécurité du message, qui est toujours MessageSecurityVersion.WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12BasicSecurityProfile10, et le transport, qui est toujours HTTPS, et non HTTP. Sinon, le contrôle comporte un certain nombre de propriétés qui peuvent être utiles à un peu mieux connaître dans le cadre de votre implémentation (malgré, qu'en règle générale, vous n'avez pas besoin de les modifier).

En premier lieu, il existe cinq propriétés en lecture seule pour exposer les objets de configuration de niveau supérieur utilisés dans la configuration. Par « lecture seule », je veux dire que les objets eux-mêmes sont en lecture seule, mais que vous pouvez définir leurs propriétés individuelles si vous manipulez le contrôle par programmation. Ces cinq propriétés sont :

 
Sélectionnez
SecurityBindingElement SecurityBinding

BinaryMessageEncodingBindingElement BinaryMessage

HttpsTransportBindingElement SecureTransport

WS2007FederationHttpBinding FedBinding

EndpointAddress WcfEndpointAddress

Les autres propriétés peuvent toutes être configurées dans la balise de contrôle qui est ajoutée à la page de dispositions aspx. Pour ces propriétés, j'ai utilisé une convention de nommage qui, je l'espérais, aurait un sens pour les valeurs de propriétés composées. Par exemple, la propriété SecurityBinding a une propriété appelée LocalClient, qui a elle-même une propriété booléenne appelée CacheCookies. Pour rendre tout cela le plus facile à comprendre et à utiliser que possible, j'ai juste créé une propriété appelée SecurityBindingLocalClientCacheCookies. Vous verrez plusieurs propriétés comme ça, et c'est également une piste pour vous aider à trouver la propriété adéquate si vous êtes en train d'examiner le SDK du framework .NET et que vous vous demandez comment vous pouvez modifier certaines de ces valeurs de propriétés dans l'implémentation de la classe de base. Voici la liste complète des propriétés :

 
Sélectionnez
SecurityAlgorithmSuite SecurityBindingDefaultAlgorithmSuite

SecurityHeaderLayout SecurityBindingSecurityHeaderLayout

SecurityKeyEntropyMode SecurityBindingKeyEntropyMode

bool SecurityBindingIncludeTimestamp

bool SecurityBindingLocalClientCacheCookies

bool SecurityBindingLocalClientDetectReplays

int SecurityBindingLocalClientReplayCacheSize

int SecurityBindingLocalClientMaxClockSkew

int SecurityBindingLocalClientMaxCookieCachingTime

int SecurityBindingLocalClientReplayWindow

int SecurityBindingLocalClientSessionKeyRenewalInterval

int SecurityBindingLocalClientSessionKeyRolloverInterval

bool SecurityBindingLocalClientReconnectTransportOnFailure

int SecurityBindingLocalClientTimestampValidityDuration

int SecurityBindingLocalClientCookieRenewalThresholdPercentage

bool SecurityBindingLocalServiceDetectReplays

int SecurityBindingLocalServiceIssuedCookieLifetime

int SecurityBindingLocalServiceMaxStatefulNegotiations

int SecurityBindingLocalServiceReplayCacheSize

int SecurityBindingLocalServiceMaxClockSkew

int SecurityBindingLocalServiceNegotiationTimeout

int SecurityBindingLocalServiceReplayWindow

int SecurityBindingLocalServiceInactivityTimeout

int SecurityBindingLocalServiceSessionKeyRenewalInterval

int SecurityBindingLocalServiceSessionKeyRolloverInterval

bool SecurityBindingLocalServiceReconnectTransportOnFailure

int SecurityBindingLocalServiceMaxPendingSessions

int SecurityBindingLocalServiceMaxCachedCookies

int SecurityBindingLocalServiceTimestampValidityDuration

int BinaryMessageMaxReadPoolSize

int BinaryMessageMaxWritePoolSize

int BinaryMessageMaxSessionSize

int BinaryMessageReaderQuotasMaxDepth

int BinaryMessageReaderQuotasMaxStringContentLength

int BinaryMessageReaderQuotasMaxArrayLength

int BinaryMessageReaderQuotasMaxBytesPerRead

int BinaryMessageReaderQuotasMaxNameTableCharCount

System.Net.AuthenticationSchemes SecureTransportAuthenticationScheme

System.ServiceModel.HostNameComparisonMode SecureTransportHostNameComparisonMode

System.Net.AuthenticationSchemes SecureTransportProxyAuthenticationScheme

System.ServiceModel.TransferMode SecureTransportTransferMode

bool SecureTransportManualAddressing

long SecureTransportMaxBufferPoolSize

long SecureTransportMaxReceivedMessageSize

bool SecureTransportAllowCookies

bool SecureTransportBypassProxyOnLocal

bool SecureTransportKeepAliveEnabled

int SecureTransportMaxBufferSize

string SecureTransportRealm

bool SecureTransportUnsafeConnectionNtlmAuthentication

bool SecureTransportUseDefaultWebProxy

bool SecureTransportRequireClientCertificate

HostNameComparisonMode FedBindingHostNameComparisonMode

WSMessageEncoding FedBindingMessageEncoding

Encoding FedBindingTextEncoding

SecurityAlgorithmSuite FedBindingSecurityMessageAlgorithmSuite

SecurityKeyType FedBindingSecurityMessageIssuedKeyType

bool FedBindingSecurityMessageNegotiateServiceCredential

int FedBindingCloseTimeout

int FedBindingOpenTimeout

int FedBindingReceiveTimeout

int FedBindingSendTimeout

bool FedBindingBypassProxyOnLocal

bool FedBindingTransactionFlow

long FedBindingMaxBufferPoolSize

long FedBindingMaxReceivedMessageSize

bool FedBindingUseDefaultWebProxy

int FedBindingReaderQuotasMaxDepth

int FedBindingReaderQuotasMaxStringContentLength

int FedBindingReaderQuotasMaxArrayLength

int FedBindingReaderQuotasMaxBytesPerRead

int FedBindingReaderQuotasMaxNameTableCharCount

bool FedBindingReliableSessionOrdered

int FedBindingReliableSessionInactivityTimeout

bool FedBindingReliableSessionEnabled

Une fois encore, ces propriétés ont toutes été créées de manière à pouvoir être modifiées directement dans la balise de contrôle de la page de dispositions aspx. Par exemple, voici comment vous auriez défini la propriété FedBindingUseDefaultWebProxy :

 
Sélectionnez
<AzWcf:WcfDataControl runat="server" id="wcf" WcfUrl="https://azurewcf.vbtoys.com/Customers.svc" OutputType="Page" MethodName="GetAllCustomersHtml" FedBindingUseDefaultWebProxy="true" />

Propriétés d'utilisation

Les autres propriétés du contrôle sont conçues afin de contrôler comment il est utilisé. Bien qu'il y ait une liste des propriétés qui soit plutôt longue, notez qu'elles sont principalement dans le cadre d'une certaine souplesse d'utilisation - dans un cas de figure simple, vous n'aurez qu'une ou deux propriétés à définir, ou encore, simplement les définir dans le web part qui sera décrit dans la quatrième partie de cette série. Voici une liste de chaque propriété avec une courte description de chacune.

string WcfUrl - c'est l'URL du point de terminaison de service WCF, c'est-à-dire https://azurewcf.vbtoys.com/Customers.svc.

string MethodName - c'est le nom de la méthode qui doit être appelée lorsque la page est demandée. Vous pouvez affecter cette propriété la méthode qui sera appelée par défaut à cette propriété. Par ailleurs, vous pouvez également affecter la valeur false à la propriété AllowQueryStringOverride, ce qui limitera la page à utiliser uniquement la propriété MethodName que vous définissez dans la balise de contrôle. Cette propriété peut être définie via une chaîne de requête en utilisant le web part du CASI Kit.

string MethodParams - c'est la liste de valeurs de paramètre séparées par des points-virgules et qui doivent être passées à l'appel de méthode. Elles doivent être dans le même ordre qu'elles apparaissent dans la signature de méthode. Comme expliqué dans la deuxième partie de la série, les valeurs de paramètre ne prennent en charge que les types de données simples, tels que string, bool, int et datetime. Si vous souhaitez passer davantage d'objets plus complexes en tant que paramètres de méthode, il vous faut alors définir le paramètre en tant que chaîne, et dé-sérialiser votre objet en XML avant d'appeler la méthode, ensuite dans votre application WCF, vous pouvez ré-sérialiser la chaîne en instance d'objet. Toutefois, si vous passez cela en tant que paramètre de chaîne de requête, vous serez limité par la longueur maximale de chaîne de requête prise en charge par votre navigateur et IIS. Cette propriété peut être définie via une chaîne de requête en utilisant le web part du CASI Kit.

object WcfClientProxy - la propriété WcfClientProxy est ce qui sert en fait à effectuer l'appel à l'application WCF. Elle doit être configurée pour prendre en charge le passage du jeton d'utilisateur avec l'appel, c'est la raison pour laquelle la dernière partie du code de configuration que vous écrivez dans votre contrôle personnalisé dans le cadre de la substitution d'ExecuteRequest doit affecter à cet objet proxy le proxy d'application de service que vous avez créé et configuré pour utiliser les informations d'identification du client actuel.

string QueryResultsString - cette propriété contient une représentation sous forme de chaîne des résultats renvoyés à partir de l'appel de méthode. Si votre méthode WCF renvoie un type de données simple tel que bool, int, string ou datetime, alors la valeur de cette propriété correspondra à la valeur de retour ToString(). Si votre méthode WCF renvoie une classe personnalisée ça passe aussi - lorsque la classe de base reçoit la valeur de retour, elle la dé-sérialise en une chaîne de sorte que vous ayez une représentation XML des données.

object QueryResultsObject - cette propriété contient une représentation sous forme d'objet des résultats renvoyés à partir de l'appel de méthode. Elle est utile lorsque vous utilisez le contrôle par programmation. Par exemple, si vous utilisez le contrôle pour récupérer des données à stocker dans le cache ASP.NET, ou à être utilisées dans un travail du minuteur SharePoint, la propriété QueryResultsObject dispose exactement de ce que l'appel de méthode WCF a renvoyé. S'il s'agit d'une classe personnalisée, il vous suffit alors d'effectuer un transtypage des résultats de cette propriété vers le type de classe approprié afin de pouvoir l'utiliser.

DataOutputType OutputType - la propriété OutputType est une énumération qui peut avoir l'une des quatre valeurs suivantes : Page, ServerCache, Both ou None. Si vous utilisez le contrôle dans la page de dispositions et que vous allez effectuer le rendu des résultats avec le web part, alors OutputType doit avoir la valeur Page ou Both. Si vous souhaitez récupérer les données et les stocker dans le cache ASP.NET, alors vous devriez utiliser la valeur ServerCache ou Both. Il est à noter que lors du stockage des résultats dans le cache, seul QueryResultsObject est stocké. Évidemment, la valeur Both va effectuer le rendu des données et stocker ces dernières dans le cache ASP.NET. Si vous utilisez simplement le contrôle par programmation dans quelque chose comme un travail du minuteur SharePoint, alors vous pouvez affecter la valeur None à cette propriété, car vous allez simplement lire QueryResultsString ou QueryResultsObject après l'appel de la méthode ExecuteRequest. Cette propriété peut être définie via une chaîne de requête en utilisant le web part du CASI Kit.

string ServerCacheName - si vous choisissez une valeur ServerCache ou Both pour OutputType, il vous faut alors affecter une valeur de chaîne non vide à la propriété ServerCacheName, sinon une exception sera levée. C'est la clé qui sera utilisée pour stocker les résultats dans le cache ASP.NET. Par exemple, si vous affectez « MyFooProperty » à la propriété ServerCacheName, alors après l'appel de la méthode ExecuteRequest, vous pouvez récupérer l'objet qui a été renvoyé à partir de l'application WCF en faisant référence à HttpContext.Current.Cache["MyFooProperty"]. Cette propriété peut être définie via une chaîne de requête en utilisant le web part du CASI Kit.

int ServerCacheTime - c'est le temps, en minutes, qu'un élément ajouté au cache ASP.NET doit être conservé. Si vous affectez la valeur ServerCache ou Both à la propriété OutputType, alors vous devez également affecter une valeur non zéro à cette propriété, sinon une exception sera levée. Cette propriété peut être définie via une chaîne de requête en utilisant le web part du CASI Kit.

bool DecodeResults - cette propriété est fournie au cas où votre application WCF renverrait des résultats HtmlEncoded. Si vous affectez la valeur true à cette propriété, alors HtmlDecoding sera appliqué aux résultats. Dans la plupart des cas, cela n'est pas nécessaire. Cette propriété peut être définie via une chaîne de requête en utilisant le web part du CASI Kit.

string SharePointClaimsSiteUrl - cette propriété est fournie principalement pour les scénarios où vous êtes en train de créer le contrôle par programmation en dehors d'une requête Http, telle que dans le cas d'un travail du minuteur SharePoint. Par défaut, lorsqu'une requête est effectuée via le web part, la classe de base va utiliser l'URL du site actuel pour se connecter au point de terminaison du Security Token Service de SharePoint afin de fournir le jeton d'utilisateur à l'appel WCF. Toutefois, si vous avez créé le contrôle par programmation et que vous n'avez aucun contexte Http, vous pouvez affecter à cette propriété l'URL d'un site SharePoint sécurisé prenant en charge les revendications, et ce site sera utilisé pour accéder au Security Token Service de SharePoint. Ainsi, par exemple, vous ne devriez jamais avoir à définir cette propriété dans la balise de contrôle de la page de dispositions parce que vous disposerez toujours d'un contexte Http en appelant cette page.

bool AllowQueryStringOverride - cette propriété permet aux administrateurs de verrouiller efficacement une balise de contrôle dans la page de dispositions. Si AllowQueryStringOverride est affectée la valeur false, alors toutes les valeurs de substitution de chaîne de requête qui sont passées à partir du web part du CASI Kit seront ignorées.

string AccessDeniedMessage - il s'agit du message d'erreur « Access Denied » qui devrait être affiché dans le web part du CASI Kit si l'accès est refusé à l'utilisateur pour une méthode particulière. À titre d'exemple, comme expliqué dans la deuxième partie de cette série, si nous passons le jeton de l'utilisateur avec l'appel WCF, nous pouvons « décorer » les méthodes avec une demande PrincipalPermission, telle que « Cet utilisateur doit faire partie du groupe des responsables des ventes ». Si un utilisateur ne répond pas aux exigences d'une demande PrincipalPermission, alors l'appel WCF échouera avec une erreur de refus d'accès. Dans ce cas, le web part affichera quel que soit sera l'AccessDeniedMessage. Notez que vous pouvez utiliser une mise en forme enrichie dans ce message, pour effectuer des choses telles que définir la police en gras ou en rouge en utilisant des balises HTML (c'est-à-dire, <font color='red'>Accès refusé : veuillez contacter votre administrateur</font>). Cette propriété peut être définie via une chaîne de requête en utilisant le web part du CASI Kit.

string TimeoutMessage - c'est le message qui sera affiché dans le web part du CASI Kit, s'il y une erreur de délai d'attente lors de la tentative d'exécution de l'appel de méthode WCF. Elle prend également en charge la mise en forme enrichie, telle que la définition d'une police en gras, en rouge, etc. Cette propriété peut être définie via une chaîne de requête en utilisant le web part du CASI Kit.

L'ensemble des propriétés suivantes a été ajouté afin de vous aider à faire du débogage à partir du web part proprement dit.

bool ReturnDiagnosticsInformation - cette propriété contrôle si des informations de diagnostic seront renvoyées à l'appelant. Puisqu'elle pourrait contenir des informations qui pourraient être considérées comme étant sensibles - telles que le nom du serveur sur lequel la demande fut exécutée - vous pouvez lui affecter une valeur false pour empêcher un retour des informations dans le web part.

string ExecutionServerName - c'est le nom du serveur sur lequel la demande a été exécutée. Si vous avez des soucis avec la demande, vous pouvez alors utilisez ces informations pour savoir sur quel serveur vous voudrez peut-être consulter les journaux du service ULS.

string ExecutionErrorMessage - contient tous les messages d'erreurs qui sont survenus pendant l'exécution de l'appel de méthode WCF.

string TraceInfoMessage - cette propriété inclut les informations de traçage à propos de la demande qui a été effectuée. Par exemple, elle inclut le nom de la méthode, les paramètres de méthode, l'URL WCF qui a été utilisée, etc.

Conseils de dépannage

Le dépannage peut parfois être difficile à réaliser dans un système largement distribué tel que celui ci. Voici quelques conseils pour vous aider à démarrer :

  • Naviguez directement à la page de dispositions personnalisée. Il est souvent plus facile de voir quelles données sont en train d'être renvoyées, ou quels messages d'erreurs vous êtes en train de rencontrer, si vous naviguez tout simplement à la page personnalisée.
  • Activez la propriété « Show Debugging Information » dans le web part du CASI Kit. Elle vous indiquera quelles étaient toutes les valeurs de paramètre utilisées pour faire la demande, le temps qu'avait pris la demande, tout messages d'erreurs, etc.
  • Si vous voyez un message d'erreur du genre « secured fault », assurez-vous que vous avez ajouté la bonne empreinte numérique du certificat de signature de jetons du Security Token Service de SharePoint au web.config de votre application WCF, et que vous avez également ajouté le certificat SSL et tous les certificats racine qui le précèdent aux autorités racine de confiance dans SharePoint.

Les mises à jour

Mise à jour du 04/02/2011 : J'ai ajouté une solution appelée AzureConnectRegister.wsp au fichier compressé joint à cet article. Je vous recommande vivement de l'utiliser pour distribuer la classe de base du CASI Kit car il contient un récepteur de fonctionnalité qui enregistre une zone de journalisation ULS personnalisée. Sans cela, la journalisation utilisée dans la classe de base ne sera pas en mesure d'exécuter avec succès, et vous allez donc perdre toute journalisation. J'ai également inclus le code source pour cette fonctionnalité pour que vous puissiez voir quel code elle est en train d'utiliser pour enregistrer la zone de journalisation ULS personnalisée.
Mise à jour du 24/02/2011 : J'ai ajouté toutes les propriétés de débogage supplémentaires décrites ci-dessus.
Mise à jour du 06/03/2011 : Il y avait un problème avec la connexion à l'application WCF n'étant pas correctement fermée. Il aurait pu en résulter des problèmes périodiques de délai d'attente lorsque le web part du CASI Kit demandait des données de l'application WCF. Ce problème a été fixé. En outre, une valeur de 30 secondes est affectée par défaut aux propriétés SendTimeout et ReceiveTimeout, de sorte que s'il y avait des problèmes ils apparaîtraient plus rapidement que précédemment.
Mise à jour du 25/06/2011 : J'ai fixé un problème avec certains types de paramètres de méthode qui n'étaient pas correctement transtypés ; cela se traduisait par une erreur indiquant que la méthode n'avait pu être trouvée. Les types standards décrits ci-dessus sont pris en charge pour les paramètres de méthode : string, int, long, bool, et datetime. Les types personnalisés devraient être dé-sérialisés en une chaîne et ré-sérialisés coté serveur.
Mise à jour du 12/07/2011 : Pas de mises à jour de code, mais simplement un doux rappel. Si vous ajoutez votre web part à une page et cochez la case « Show Debug Information », et qu'ensuite il n'arrive pas à récupérer les données et vous indique qu'il a échoué dans sa tentative d'établir une confiance, il y a deux causes possibles. La première, vous n'avez pas correctement configuré la confiance dans le fichier web.config de l'application WCF. Je décris comment accomplir cela dans la deuxième partie de cette série à l'adresse http://blogs.technet.com/b/speschka/archive/2010/11/06/the-claims-azure-and-sharepoint-integration-toolkit-part-2.aspx. La deuxième, vous n'avez pas ajouté le certificat SSL ou un de ses certificats parent à la liste des autorités racine de confiance dans votre ferme SharePoint. J'ai décrit comment accomplir cela à l'adresse http://blogs.technet.com/b/speschka/archive/2010/02/13/root-of-certificate-chain-not-trusted-error-with-claims-authentication.aspx.

Conclusion

Bon, ceci était un long article, mais ce sera probablement le plus long de la série, car c'est ici que se trouve « le ciment » le plus significatif du CASI Kit.

Dans cet article, nous avons abordé l'un des livrables les plus importants du « framework », qui est la classe de base de contrôle personnalisé que vous utilisez pour effectuer votre connexion de SharePoint à votre application WCF hébergée dans Windows Azure. Nous avons vu les éléments suivants : ce qu'est la classe de base et comment l'utiliser dans votre projet, comment ajouter un nouveau contrôle personnalisé à une page dans le répertoire « _layouts », et quelques-unes des propriétés importantes à connaître dans la classe de base.

Dans le prochain article, je décrirai le web part qui est inclus dans le CASI Kit pour effectuer le rendu des données de votre application WCF en utilisant le contrôle personnalisé et la page de dispositions que vous avez développés au cours de cette étape.

Liens

Vous trouverez en pièce jointe de cet article, un fichier compressé qui contient la version Word de l'article en anglais, l'exemple de projet Visual Studio 2010 que l'auteur a créé et qui inclut l'assembly de la classe de base du CASI Kit, son contrôle personnalisé qui hérite de la classe de base du CASI Kit, ainsi que sa page de dispositions personnalisée.

Le projet CASI Kit sur CodePlex : ici

Remerciements

Je tiens ici à remercier Steve Peschka de m'avoir autorisé à traduire son article.
Je remercie xyz pour sa relecture technique et ses propositions.
Je remercie également abc pour sa relecture orthographique et ses propositions.