Kit de ressources CASI - Partie 5
Kit de ressources CASI - Partie 5
Ceci est la cinquième partie d’une série en cinq parties consacrée au Kit CASI (Claims, Azure and SharePoint Integration). La partie 1 était une vue d’ensemble qui présentait l’intégralité de l’infrastructure et de la solution, et qui décrivait les objectifs de la série. La partie 2 a expliqué comment créer vos applications WCF, comment en faire des applications prenant en charge les revendications, puis comment les intégrer à Windows Azure. La partie 3 a décrit la classe de base qui permet de raccorder votre site SharePoint aux données Azure, via l’ajout d’un nouveau contrôle personnalisé à une page dans le répertoire _layouts. La partie 4 a documenté le composant WebPart inclus dans le Kit CASI et a décrit son utilisation, ses différentes propriétés, etc. Dans ce dernier article, je décris les deux autres scénarios principaux relatifs à ce kit, en utilisant le contrôle personnalisé créé dans la troisième partie pour récupérer les données Azure et les stocker dans le cache ASP.NET de sorte qu’elles soient accessibles aux autres contrôles, et en utilisant également ce contrôle dans une tâche SharePoint (dans le cas présent, un travail du minuteur SharePoint personnalisé).
Utilisation du contrôle dans d’autres composants WebPart
L’un des principaux scénarios à prendre en charge était l’utilisation de l’infrastructure du Kit CASI pour la récupération de données utilisables dans d’autres composants WebPart SharePoint. L’autre objectif de conception é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 manière directe. Cela vous permet de développer d’autres composants WebPart personnalisés et de suivre un modèle assez simple :
1. Vérifier si vos données se trouvent dans le cache ASP.NET.
a. Si tel est le cas, les récupérer à partir de cet emplacement
b. Sinon :
i. Créer une instance du contrôle personnalisé
ii. Affecter ServerCache à OutputType, et affecter les valeurs appropriées à ServerCacheName et ServerCacheTime
iii. Appeler la méthode ExecuteRequest et obtenir les données
Tout d’abord, démarrez un nouveau projet Visual Studio : dans le cas présent, nous utilisons Visual Studio 2010 pour pouvoir créer un projet SharePoint 2010. Configurez votre projet pour créer un composant WebPart, puis ajoutez deux références, l’une à la classe de base du Kit CASI et l’autre au contrôle personnalisé que vous avez écrit au cours de la troisième partie de ce blog. Notez que si vous n’ajoutez pas de référence à la classe de base du Kit CASI, lorsque vous essayez de définir l’une des propriétés de votre contrôle, Visual Studio la souligne avec un trait ondulé rouge et vous signale que la propriété est introuvable. Si vous voyez ce type d’erreur, cela signifie que vous n’avez pas encore ajouté de référence à la classe de base du Kit CASI.
Une fois vos références définies, vous pouvez écrire le code approprié pour votre composant WebPart. Lorsque vous devrez récupérer des données d’Azure (contenu, informations de configuration, etc.), suivez l’exemple ci-dessous relatif au mode d’implémentation du modèle décrit plus haut :
string CACHE_NAME = "AzureConfigConsumerCacheSample";
int CACHE_TIME = 10;
//crée une variable dont le type est celui des données de configuration à récupérer
AzureWcfPage.CustomersWCF.Customer[] Customers = null;
//recherche notre élément dans le cache
if (HttpContext.Current.Cache[CACHE_NAME] != null)
{
//s’il existe, il est converti vers notre type et extrait du cache
Customers =
(AzureWcfPage.CustomersWCF.Customer[])
HttpContext.Current.Cache[CACHE_NAME];
}
else
{
//s’il n’est pas dans le cache, il est récupéré et mis en cache
//crée une instance du contrôle
AzureWcfPage.WcfDataControl cfgCtrl = new AzureWcfPage.WcfDataControl();
//définit les propriétés pour la récupération des données
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";
//exécute la méthode
bool success = cfgCtrl.ExecuteRequest();
if (success)
{
//obtient la version fortement typée de nos données
//le type de données doit provenir du contrôle que nous créons
Customers =
(AzureWcfPage.CustomersWCF.Customer[])cfgCtrl.QueryResultsObject;
//si vous voulez la représentation XML de l’objet, vous pouvez l’obtenir
//à partir de QueryResultsString
string stringCustomers = cfgCtrl.QueryResultsString;
}
else
{
//un problème s’est produit ; placez votre gestion des erreurs ici
}
}
Examinons une partie du code un peu plus en détails. Tout d’abord, vous devez bien comprendre que dans votre composant WebPart, vous n’avez PAS besoin d’ajouter de référence de service au point de terminaison WCF. Tout est encapsulé dans votre contrôle personnalisé, ce qui vous permet d’utiliser les types de renvoi de votre application WCF, qui sont exposés via le contrôle personnalisé. Cette ligne de code en est l’illustration :
//crée une variable dont le type est celui des données de configuration à récupérer
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 renvoyé par ma méthode WCF. Tout cela s’intègre dans mon nouveau composant WebPart lorsque j’ajoute ma référence à l’assembly de contrôle personnalisé.
En premier lieu, je vérifie si mes données sont dans le cache ; si tel est le cas, j’effectue simplement une conversion de type (transtypage) vers le tableau des instances de Customer stockées précédemment. Si les données ne sont pas dans le cache, il suffit d’écrire 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 :
a. Créer une instance du contrôle
b. Définir les propriétés WcfUrl, MethodName, OutputType, ServerCacheName et ServerCacheTime
c. Appeler la méthode ExecuteRequest
C’est tout. Si la méthode s’exécute correctement, la valeur renvoyée à partir de l’application WCF est stockée dans le cache ASP.NET ; par conséquent, la prochaine fois que le code s’exécutera, il y trouvera l’élément. Pendant ce temps, je peux effectuer une conversion de type (transtypage) de ma variable locale Customers en propriété QueryResultsObject du contrôle personnalisé, puis utiliser les données en fonction des besoins du composant WebPart. Tout cela doit être relativement rapide et facile à implémenter pour la plupart des développeurs de composants WebPart.
Utilisation du contrôle dans une tâche
À présent, je vais expliquer 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, et m’en servir 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 en provenance d’Azure. Le modèle est assez similaire au composant WebPart décrit ci-dessus, mais dans le cas présent, à l’instar de nombreuses tâches, vous ne disposez pas de HttpContext ; par conséquent, il est impossible d’utiliser le cache ASP.NET. OutputType a la valeur None, car il n’a pas besoin d’être rendu sur une page, ni d’être stocké dans le cache ; à la place, nous extrayons simplement la valeur directement à partir de QueryResultsObject et/ou QueryResultsString. Voici l’exemple de code correspondant. Il s’agit du code relatif à la substitution de la méthode Execute dans ma classe de travail du minuteur personnalisé :
SPWebApplication wa = (SPWebApplication)this.Parent;
//crée une instance du contrôle
AzureWcfPage.WcfDataControl cfgCtrl = new AzureWcfPage.WcfDataControl();
//définit les propriétés pour la récupération des données
cfgCtrl.WcfUrl = "https://azurewcf.vbtoys.com/Customers.svc";
cfgCtrl.OutputType = AzureConnect.WcfConfig.DataOutputType.None;
cfgCtrl.MethodName = "GetAllCustomers";
//comme il n’y a pas de contexte Http dans une tâche telle qu’un travail du minuteur, vous devez également
//fournir l’URL d’un site SharePoint prenant en charge les revendications. Cette adresse permet de
//se connecter au point de terminaison STS de la batterie de serveurs SharePoint
cfgCtrl.SharePointClaimsSiteUrl = wa.Sites[0].RootWeb.Url;
//exécute la méthode
bool success = cfgCtrl.ExecuteRequest();
//vérifie si l’exécution est réussie
if (success)
{
//récupère les données pour les utiliser en fonction des besoins
AzureWcfPage.CustomersWCF.Customer[] Customers =
(AzureWcfPage.CustomersWCF.Customer[])cfgCtrl.QueryResultsObject;
string AzureResults = cfgCtrl.QueryResultsString;
//point d’exécution de vos tâches en fonction des données récupérées à partir d’Azure
foreach(AzureWcfPage.CustomersWCF.Customer c in Customers)
{
Debug.WriteLine(c.Email);
}
Debug.WriteLine(AzureResults);
}
else
{
//action visant à enregistrer dans un journal la non-récupération des données
}
Voici un peu plus d’explications sur ce code. Le travail du minuteur est un travail dont l’étendue porte sur l’application Web ; par conséquent, je commence par obtenir une référence au SPWebApplication pour lequel ce travail est exécuté en faisant référence à la propriété Parent. Je crée ensuite le contrôle personnalisé décrit dans la troisième partie et je définis les propriétés minimales nécessaires 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 indiqué dans la troisième partie, lorsque la classe de base du Kit CASI s’exécute via la méthode ExecuteRequest, elle vérifie s’il existe un HttpContext disponible. Si tel est le cas, elle utilise ce contexte pour déterminer l’URL du site SharePoint actuel et établit une connexion au service STS SharePoint via ce site. Comme je l’ai décrit ci-dessus, lorsque votre code exécute une tâche, vous ne disposez généralement pas de HttpContext. Dans ce cas, la classe de base ne peut pas déterminer l’URL à utiliser pour se connecter au service STS SharePoint ; par conséquent, 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 est censé s’exécuter UNIQUEMENT pour des applications Web prenant en charge les revendications ; c’est 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 appeler la méthode ExecuteRequest, comme nous l’avons vu précédemment. Si elle s’exécute correctement, je peux extraire mes données du contrôle directement via les propriétés QueryResultsObject et/ou QueryResultsString.
Les projets de composant WebPart et de travail du minuteur sont inclus dans le fichier zip joint à cet article.
En conclusion
Ceci était le dernier article de la série. J’espère que vous comprenez mieux à présent en quoi consiste le Kit CASI et comment vous pouvez l’utiliser pour vous connecter facilement aux données hébergées dans une application WCF, sur site ou dans le nuage, 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 modèle est relativement facile à implémenter :
1. Créez une application WCF frontale pour votre contenu et/ou vos données de configuration. Rendez l’application capable de prendre en charge les revendications et transférez-la éventuellement vers le nuage. Si vous le souhaitez, implémentez des décisions en matière de permissions affinées en fonction des revendications et de l’identité de l’utilisateur appelant.
2. Écrivez un contrôle personnalisé qui hérite de la classe de base du Kit CASI. Substituez une méthode et écrivez cinq lignes de code. Ajoutez le contrôle à une simple page de disposition, puis effectuez le déploiement.
3. Ajoutez le composant WebPart à une page, définissez une ou plusieurs propriétés, puis démarrez 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 composant WebPart personnalisé ou une tâche personnalisée (par exemple un travail du minuteur personnalisé).
C’est à peu près tout. J’espère que le Kit CASI vous aidera à connecter plus facilement votre batterie de serveurs SharePoint aux données stockées dans le monde entier. Il représente également une solution idéale pour récupérer des données de configuration ou de personnalisation, ainsi que du contenu à afficher dans vos sites SharePoint. 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. Je suis heureux d’avoir pu apporter ma contribution à la planification, à la conception et au développement de ce projet, et j’espère que cela vous sera utile. Bien entendu, il s’agit d’une version 1 qui nécessite probablement de nombreuses améliorations ; par conséquent, n’hésitez pas à ajouter des commentaires sur ces articles. Je les consulterai régulièrement afin de m’en inspirer pour la prochaine version majeure.
Ceci est une version localisée d’un article de blog. Vous trouverez la version originale sur The Claims, Azure and SharePoint Integration Toolkit Part 5