Kit de ressources CASI - Partie 1

Ceci est le premier volet d’une série d’articles de blog que je suis impatient de vous faire découvrir, car j’espère qu’ils répondront pleinement à votre attente.  Je travaille depuis ces derniers mois sur une nouvelle infrastructure de connexion entre SharePoint et Windows Azure, ainsi que sur la manière d’incorporer l’identité basée sur les revendications de sorte que votre identité puisse être transmise de façon transparente indépendamment des limites des applications et même des centres de données.  Ces efforts ont permis d’aboutir au Kit CASI (Claims, Azure, and SharePoint Integration), qui rassemble de l’aide, un assembly de classe de base, un composant WebPart et des exemples d’applications.  Utilisés conjointement, ces éléments vous permettent de créer des applications WCF qui prennent en charge les revendications et peuvent être hébergées dans le nuage Windows Azure.  La classe de base sert de liant entre Azure, les revendications et SharePoint.  Le composant WebPart est un outil « prêt à l’emploi » qui vous permet de connecter simplement les données d’Azure à votre site SharePoint.  Le composant WebPart travaille de manière asynchrone avec un appel côté client pour éviter à votre site Web de devoir s’arrêter lorsqu’un certain nombre d’appels côté serveur sont effectués à partir de vos pages SharePoint vers un service nuage potentiellement latent.  Cela s’apparente à du « Plug-and-Play nuage », comme vous allez pouvoir le découvrir.

Voici un peu plus de détails sur les articles de blog à venir et sur le contenu que je vais traiter :

·         Partie 2 :  dans le prochain article, j’aborderai la partie aide du Kit CASI.  Il faut commencer par faire de WCF la partie frontale de l’ensemble de vos données, qu’il s’agisse de jeux de données, de contenu XML, de classes personnalisées ou simplement de contenu HTML.  Dans une première phase, nous faisons du service WCF standard un service prenant en charge les revendications. Cela nous permet de faire passer le jeton d’utilisateur de SharePoint, indépendamment des limites des applications ou des centres de données, vers nos applications WCF personnalisées.  Dans une deuxième phase, j’énumère toutes les actions à effectuer pour transférer l’application WCF classique d’un emplacement local à un emplacement hébergé dans Windows Azure.  Une fois ce travail terminé, la partie principale est en place pour assurer la prise en charge de plusieurs applications, plusieurs centres de données avec l’authentification intégrée.

·         Partie 3 :  article décrivant l’assembly de kit de ressources personnalisé qui permet de connecter votre application WCF prenant en charge les revendications dans le nuage et votre batterie de serveurs SharePoint.  J’expliquerai comment utiliser l’assembly, je décrirai le contrôle personnalisé, plutôt simple à créer (environ 5 lignes de code), et j’indiquerai comment héberger ce contrôle dans une page du répertoire _layouts afin de récupérer des données et d’effectuer leur rendu dans un composant WebPart.  L’intégralité du code source de l’exemple de contrôle personnalisé et de la page du répertoire _layouts sera également publiée.

·         Partie 4 :  ici, je traiterai du composant WebPart inclus dans le Kit CASI.  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 nuage, et les afficher ensuite dans le composant WebPart.  Il dispose également de raccordements intégrés afin que vous puissiez le personnaliser un peu et utiliser vos propres fonctions JavaScript pour effectuer le rendu des données.

·         Partie 5 :  dans la dernière partie de cette série d’articles, je décrirai brièvement quelques exemples d’applications qui illustrent d’autres scénarios d’utilisation du contrôle personnalisé que vous aurez créé lors de la troisième partie.  L’un de ces scénarios consiste à tirer parti du contrôle pour récupérer des données utilisateur ou des données de configuration, les stocker dans le cache ASP.NET, puis les utiliser dans un composant WebPart personnalisé.  L’autre scénario consiste à tirer parti du contrôle personnalisé pour récupérer des données en provenance d’Azure afin 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.

J’espère avoir éveillé votre curiosité.  Je vous invite donc à consulter ce site pour prendre connaissance des articles et des exemples de code qu’il contient.

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 1