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.

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

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.