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

Ceci est le premier d'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 ces derniers 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 - à partir d'ici 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. La classe de base sera utilisée pour fournir tout « le ciment » à Azure et les revendications, qui les connecte à SharePoint. Le web part vous donne un moyen « prêt à l'emploi » facile pour connecter simplement les données d'Azure à votre site SharePoint. Ah, en passant il accomplit cela de manière asynchrone avec un appel côté client pour que votre site Web ne soit pas paralysé pendant qu'un certain nombre d'appels côté serveur sont effectués à partir de vos pages SharePoint vers un service cloud potentiellement latent. À ce jour, c'est ce qui se rapproche le plus du « plug and play cloud » que vous allez pouvoir trouver.

Voici un peu plus de détails sur les articles à venir et le contenu sur lequel je m'attarderai :

• Partie 2 : dans le prochain article, j'aborderai 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 faisons de votre service WCF standard 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 : ensuite ce sera un article qui 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 : ici, je m'attarderai sur 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 : dans la cinquième partie de cette série, j'examinerai brièvement 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.

Espérons que cela suffise pour vous mettre en appétit. Dans la deuxième partie de cette série, nous allons, comme indiqué ci-dessus, nous pencher sur comment utiliser une application WCF personnalisée comme « frontend » pour les données et le contenu, comment rendre l'application capable de prendre en charge les revendications, et comment apporter des modifications supplémentaires afin de pouvoir transférer l'application vers le cloud Windows Azure.

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.