Ceci est une série d'articles à propos de laquelle je suis plutôt enthousiaste, et j'espère que tout compte fait vous le serez aussi. Je travaille depuis plusieurs mois sur un nouveau « framework » permettant de connecter SharePoint et Windows Azure, ainsi que d'incorporer l'identité basée sur les revendications d'une manière qui permette à votre identité d'être transmise de façon transparente indépendamment des limites des applications et même des centres de données. L'aboutissement de cet effort - désormais connu sous le nom de CASI (Claims, Azure, and SharePoint Integration) Kit - est une combinaison d'instructions et de lignes directrices, d'assembly de classe de base, de web part et d'exemples d'applications. Ensemble, ces éléments vous permettront de créer des applications WCF qui prennent en charge les revendications et de les héberger dans le cloud Windows Azure.

Langage/Outil/Technologie : SharePoint 2010, Windows Azure, CASI Kit.

Commentez ce tutoriel : Commentez

- Titre : Le CASI (Claims, Azure and SharePoint Integration) Kit

- Auteurs : Steve Peschka, Deepin Prayag

- Parution : 21 janvier 2013

- Licence : Copyright © 2013 Steve Peschka. CDATA[Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 € de dommages et intérêts. Droits de diffusion permanents accordés à Developpez LLC. Cette page est déposée à la SACD.

Sommaire

- Traduction

- Introduction

- Le CASI Kit : Partie 5 - Exemples d'applications

- Utilisation du contrôle dans d'autres web parts

- Utilisation du contrôle dans une tâche

- C'est dans la boîte !

- Conclusion

- Liens

- Remerciements

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 5.

Introduction

Ceci est la cinquiè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 avez 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 5 - Exemples d'applications

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 rendre cette application WCF capable de prendre en charge les revendications, et finalement comment la modifier pour la transférer vers et l'intégrer à Windows Azure. Dans la troisième partie de la série, nous avons abordé l'un des livrables les plus importants du « framework », la classe de base de contrôle personnalisé que vous avez utilisée pour effectuer la connexion de votre site SharePoint à votre application WCF hébergée dans Windows Azure. Nous avons vu, au cours de cette partie, 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. La quatrième partie a documenté le web part, conçu spécifiquement pour fonctionner avec le contrôle personnalisé que vous avez créé et ajouté dans la page de dispositions dans la troisième partie de la série et inclus dans le CASI Kit, et a décrit son utilisation dont un cas d'utilisation typique, ses différentes propriétés, etc.

Dans cet article, je vais examiner les deux autres scénarios principaux pour ce kit - en utilisant votre contrôle personnalisé que vous avez créé dans la troisième partie pour récupérer des données Azure et les stocker dans le cache ASP.NET pour être utilisés avec d'autres contrôle, et en l'utilisant dans une tâche SharePoint - dans le cas présent, un travail du minuteur SharePoint personnalisé.

Utilisation du contrôle dans d'autres web parts

L'un des principaux scénarios qui avait besoin d'être pris en charge était d'utiliser le « framework » CASI Kit afin de récupérer des données pour être utilisées dans d'autres web parts SharePoint. Il reste, toutefois, l'autre objectif de conception qui était de ne pas introduire d'appels de routine côté serveur vers des points de terminaison WCF distants potentiellement latents. Pour tenter de gérer ces deux besoins divergents, la classe de base implémente la prise en charge de la récupération des données et de leur stockage dans le cache ASP.NET de façon directe. Cela vous permet de développer d'autres web parts personnalisés et de suivre un schéma assez simple :

Vérifiez pour voir si vos données sont dans le cache ASP.NET.

1. Si tel est le cas, récupérez-les de là ;

2. Si tel n'est pas le cas :

1. créez une instance du contrôle personnalisé ;

2. affectez ServerCache à OutputType, et des valeurs appropriées à ServerCacheName et ServerCacheTime ;

3. appelez la méthode ExecuteRequest et obtenez les données.

Pour commencer, démarrez un nouveau projet Visual Studio - dans le cas présent, je présumerai Visual Studio 2010 de sorte a pouvoir créer un projet SharePoint 2010. Obtenez la configuration de votre projet pour créer un nouveau web part, et vous devez ensuite ajouter deux références - l'une à la classe de base du CASI Kit et l'autre au contrôle personnalisé que vous avez écrit dans la troisième partie. Veuillez noter que si vous n'ajoutez pas une référence à la classe de base du CASI Kit, alors lorsque vous essaierez de définir l'une des propriétés de votre contrôle, Visual Studio la soulignera avec un trait ondulé rouge et vous signalera qu'il ne peut pas trouver la propriété. Si vous voyez ce genre d'erreur, vous saurez alors que vous n'avez pas encore ajouté la référence à la classe de base du CASI Kit.

Une fois vos références définies, vous pouvez écrire le code approprié, quel qu'il soit, pour votre web part. Lorsque vous arrivez au stade où vous devez récupérer des données d'Azure - peut être du contenu, peut être des informations de configuration, etc. - voici un exemple de comment le schéma décrit ci-dessus est implémenté :

string CACHE_NAME = "AzureConfigConsumerCacheSample";

int CACHE_TIME = 10;

//create a var of the type of configuration data we want to retrieve

AzureWcfPage.CustomersWCF.Customer[] Customers = null;

//look for our item in cache

if (HttpContext.Current.Cache[CACHE_NAME] != null)

{

//if we find, it cast it to our type and pull it out of cache

Customers =

(AzureWcfPage.CustomersWCF.Customer[])

HttpContext.Current.Cache[CACHE_NAME];

}

else

{

//if it's not in cache, then retrieve it and put it into cache

//create an instance of the control

AzureWcfPage.WcfDataControl cfgCtrl = new AzureWcfPage.WcfDataControl();

//set the properties to retrieve data

cfgCtrl.WcfUrl = "https://azurewcf.vbtoys.com/Customers.svc";

cfgCtrl.OutputType = AzureConnect.WcfConfig.DataOutputType.ServerCache;

cfgCtrl.ServerCacheName = CACHE_NAME;

cfgCtrl.ServerCacheTime = CACHE_TIME;

cfgCtrl.MethodName = "GetAllCustomers";

//execute the method

bool success = cfgCtrl.ExecuteRequest();

if (success)

{

//get the strongly typed version of our data

//the data type needs to come from the control we are creating

Customers =

(AzureWcfPage.CustomersWCF.Customer[])cfgCtrl.QueryResultsObject;

//if you wanted the Xml representation of the object you can get

//it from QueryResultsString

string stringCustomers = cfgCtrl.QueryResultsString;

}

else

{

//there was some problem; plug in your error handling here

}

}

Jetons un coup d'œil à une partie de ce code un peu plus en détails. Tout d'abord, il est important de comprendre que dans votre nouveau web part, vous n'avez pas besoin d'ajouter une référence de service au point de terminaison WCF. Tout cela est encapsulé dans votre contrôle personnalisé, de sorte que vous puissiez utiliser les types de retour de votre application WCF, qui sont exposés via le contrôle personnalisé. Cette ligne de code illustre cela :

//create a var of the type of configuration data we want to retrieve

AzureWcfPage.CustomersWCF.Customer[] Customers = null;

Dans cet exemple, AzureWcfPage est mon assembly de contrôle personnalisé. CustomersWCF est le nom que j'ai donné à ma référence de service WCF. Customer est le type de classe que ma méthode WCF renvoie. Tout cela s'intègre dans mon nouveau web part lorsque j'ajoute ma référence à l'assembly de contrôle personnalisé.

La première vérification que j'effectue est de voir si mes données sont dans le cache ; si tel est le cas, j'effectue simplement un transtypage de ces données vers le tableau des instances de Customer que j'avais stockées dans le cache précédemment. Si les données ne sont pas dans le cache, alors écrivez simplement les sept lignes de code nécessaires pour créer une instance de mon contrôle personnalisé et récupérer les données. Vous devez :

1. créer une nouvelle instance du contrôle ;

2. définir les propriétés WcfUrl, MethodName, OutputType, ServerCacheName et ServerCacheTime ;

3. appeler la méthode ExecuteRequest.

C'est tout. Si la méthode s'exécute avec succès, alors la valeur de retour à partir de l'application WCF est stockée dans le cache ASP.NET, de sorte que la prochaine fois que ce code s'exécutera, il y trouvera l'élément. Entre-temps, je peux effectuer un transtypage de ma variable locale Customers vers la propriété QueryResultsObject du contrôle personnalisé, puis, avec les données, faire tout ce dont a besoin mon web part. De façon générale, cela devrait être relativement rapide et facile à implémenter pour la plupart des développeurs de web parts.

Utilisation du contrôle dans une tâche

À présent, je vais décrire comment utiliser le contrôle personnalisé que vous avez développé dans la troisième partie pour récupérer du contenu et/ou des données de configuration à partir d'Azure, afin d'être utilisés dans une tâche. Dans cet exemple, j'ai écrit un travail du minuteur SharePoint personnalisé au sein duquel je vais récupérer des données à partir d'Azure. Le schéma est relativement similaire au web part décrit ci-dessus, mais dans le cas présent, à l'instar de nombreuses tâches, vous ne disposez pas de HttpContext, donc le cache ASP.NET ne peut être utilisé. Dans ce cas, OutputType sera définie à None, car elle n'a pas besoin d'être rendue sur une page et elle n'a pas besoin d'être stockée dans le cache ; à la place, nous allons simplement extraire la valeur directement à partir de QueryResultsObject et/ou QueryResultsString. Voici un exemple de code correspondant à cela - il s'agit de code provenant de la substitution de la méthode Execute dans ma classe de travail du minuteur personnalisé :

SPWebApplication wa = (SPWebApplication)this.Parent;

//create an instance of the control

AzureWcfPage.WcfDataControl cfgCtrl = new AzureWcfPage.WcfDataControl();

//set the properties to retrieve data

cfgCtrl.WcfUrl = "https://azurewcf.vbtoys.com/Customers.svc";

cfgCtrl.OutputType = AzureConnect.WcfConfig.DataOutputType.None;

cfgCtrl.MethodName = "GetAllCustomers";

//since there's no Http context in a task like a timer job, you also need to

//provide the Url to a claims-enabled SharePoint site.  That address will be used

//to connect to the STS endpoint for the SharePoint farm

cfgCtrl.SharePointClaimsSiteUrl = wa.Sites[0].RootWeb.Url;

//execute the method

bool success = cfgCtrl.ExecuteRequest();

//check for success

if (success)

{

//now retrieve the data and do whatever with it

AzureWcfPage.CustomersWCF.Customer[] Customers =

(AzureWcfPage.CustomersWCF.Customer[])cfgCtrl.QueryResultsObject;

string AzureResults = cfgCtrl.QueryResultsString;

//this is where you would then do your tasks based on the data you got from Azure

foreach(AzureWcfPage.CustomersWCF.Customer c in Customers)

{

Debug.WriteLine(c.Email);

}

Debug.WriteLine(AzureResults);

}

else

{

//do something to log the fact that data wasn't retrieved

}

Voici un peu plus d'explications sur ce code. Le travail du minuteur est un travail dont l'étendue porte sur une application Web, donc je commence par obtenir une référence au SPWebApplication pour lequel ce travail est en train d'être exécuté en faisant référence à la propriété Parent. Je crée ensuite le contrôle personnalisé réalisé dans la troisième partie et je définis les propriétés minimales dont j'ai besoin pour récupérer les données à partir d'Azure. Dans la ligne de code suivante, je dois définir la propriété SharePointClaimsSiteUrl. Comme je l'ai expliqué dans la troisième partie, lorsque la classe de base du CASI Kit s'exécute via la méthode ExecuteRequest, elle vérifie pour voir si elle dispose d'un HttpContext disponible. Si tel est le cas, elle utilise ce contexte pour déterminer l'URL du site SharePoint actuel et établit la connexion au Security Token Service de SharePoint par le biais de ce site. Comme je l'ai décrit ci-dessus, toutefois, lorsque votre code est en train de s'exécuter dans une tâche, vous ne disposez généralement pas de HttpContext. Dans ce cas, la classe de base ne peut pas déterminer quelle URL elle devrait utiliser pour se connecter au Security Token Service de SharePoint, donc, dans ce cas nous devons lui fournir l'URL d'un site d'une application Web prenant en charge les revendications. Le code du travail du minuteur dans cette implémentation présume qu'il sera exécuté uniquement pour des applications Web prenant en charge les revendications, c'est donc la raison pour laquelle j'obtiens la référence à l'application Web actuelle, à laquelle je passe ensuite simplement l'URL de la première collection de sites. Peu importe la collection de sites utilisée, du moment qu'elle fait partie d'une application Web prenant en charge les revendications.

Une fois que j'ai défini la propriété SharePointClaimsSiteUrl, je peux alors appeler la méthode ExecuteRequest, comme vu précédemment. Si elle s'exécute avec succès, je peux alors extraire mes données du contrôle directement via les propriétés QueryResultsObject et/ou QueryResultsString.

Les projets de web part et de travail du minuteur sont inclus dans le fichier compressé joint à cet article.

C'est dans la boîte !

Espérons que vous comprenez bien à présent en quoi consiste le CASI Kit et comment vous pouvez l'utiliser pour vous connecter assez facilement aux données hébergées dans une application WCF, sur site ou dans le cloud, tout en ayant la possibilité de passer le jeton d'identité de l'utilisateur indépendamment des limites des applications et même des centres de données. En résumé, le schéma est relativement facile à implémenter :

1. Créez une application WCF « frontend » pour votre contenu et/ou vos données de configuration. Rendez la capable de prendre en charge les revendications et transférez-la éventuellement vers le cloud. Si vous le désirez, implémentez des décisions en matière de permissions affinées basées sur les revendications et sur l'identité de l'utilisateur appelant.

2. Écrivez un contrôle personnalisé qui hérite de la classe de base du CASI Kit. Substituez une méthode et écrivez cinq lignes de code. Ajoutez le contrôle à une simple page de dispositions et effectuez le déploiement.

3. Ajoutez le web part à une page, définissez une ou plusieurs propriétés et commencez à effectuer le rendu de vos données WCF. Utilisez éventuellement le contrôle pour récupérer du contenu ou des données de configuration dans un web part personnalisé ou une tâche personnalisée, telle qu'un travail du minuteur personnalisé.

C'est à peu près tout. J'espère que le CASI Kit vous permettra de connecter sans difficulté et sans mystère votre ferme SharePoint aux données stockées aux quatre coins du monde. Il fonctionnera tout aussi bien pour récupérer des données de configuration ou de personnalisation, ainsi que du contenu proprement dit à afficher dans vos sites SharePoint. Et vous disposez désormais de la flexibilité nécessaire pour appliquer la sécurité implémentée dans votre organisation indépendamment des limites des applications et même des centres de données. J'ai eu beaucoup de plaisir à élaborer, à concevoir et à développer ce projet, et j'espère que cela vous sera utile. Bien entendu, il s'agit d'une première version et je suis sûr qu'il y aura plusieurs trucs que nous pourrons améliorer.

Conclusion

Dans cet article nous avons brièvement examiné quelques exemples d'applications illustrant quelques autres scénarios pour utiliser le contrôle personnalisé que vous avez construit dans la troisième partie dans d'autres cas de figures communs.

Dans le prochain et dernier article de cette série, je vous donnerai 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.

Liens

Vous trouverez en pièce jointe de cet article, un fichier compressé qui contient la version Word de l'article en anglais et les projets de web part et de travail du minuteur.

- CASI Kit Partie 5.zip

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.

Le CASI (Claims, Azure and SharePoint Integration) Kit

Partie 5 - Exemples d'applications

Auteurs

| Steve Peschka | Deepin Prayag |