Le Post Infeeny

Les articles des consultants et experts Infeeny

Out of the Sandbox and into the cloud : build your next SharePoint App on Azure

Session animée par Andrew Connell

Visiblement sa réputation le suit : plus une seule place dans la salle. J’ai bien fait d’arriver tôt !

Le sommaire : solutions Sandbox, création d’applications avec SharePoint Solutions, SharePoint et Azure, scénarios

Petit rappel des avantages des solutions Sandbox :

  • Déploiement sans l’intervention  de l’IT
  • Permet à l’IT de monitorer l’utilisation des ressources sur  les serveurs
  • Isole le code custom du code SharePoint (exécution dans un process différent)
  • Les erreurs n’affectent pas le site Host

Mais aussi des limitations :

  • Limitation de l’API
  • Pas d’appels distants vers des Web services, des flux ATOM, des bases de données
  • Limité à la site collection courante
  • Pas d’accès à l’objet Page

Il faut savoir que les ressources sont monitorées et le throttling automatique (temps de chargement trop long à SharePoint arrête l’exécution).

Pour parer aux limitations :

  • Full trust proxies : Une librairie de ressources est déployée avec un solution de ferme trust qui peut être appelée depuis la Sandbox
  • Utilisation de Javascript, etc (pas d’exécution côté serveur)

Les 2 types de solutions permettent de customiser SharePoint : on peut faire plein de  choses en Sandbox finalement J .

Pour la gestion de bases de données conséquentes, pour du e-commerce ou autre, SharePoint n’est certainement pas la meilleure solution.

Les contraintes de la Sandbox empêchent de gérer les sources de données trop complexes.

La solution : déplacer la logique business côté Azure et exécuter les processus lourds côté Azure

On accède à des systèmes bas niveau côté Azure et on utilise l’authentification ACS.

Les avantages du couple « SharePoint – Azure » :

  • Facilite l’extensibilité des applis
  • Proxy vers des données dans le cloud
  • Coûts de stockage plus faibles : SharePointà 5$/GB, Azureà0.15$/GB !!!
  • Azure peut être utilisé par d’autres applications
  • Centraliser les logiques business dans Azure

On peut utiliser une solutions Azure dans SharePoint avec  :

  • La WebPart content editor (oui oui vous avez bien entendu J)
  • Une WebBart Sandboxée
  • BCS / le types de contenus externes
  • La recherche

Pour permettre aux solutions azure d’interagir avec SharePoint, on peut utiliser :

  • SharePoint client object model (csom)
  •  REST
  • Authent côté SharePoint: Classique ou Claims

Andrew Connell présente quelques exemples de scénarios, du plus simple au plus complexe…

Scénario simple :

– Une IFrame dans SharePoint!

Scénario moyen :

– Côté client avec JS/JQuery

– BCS avec SharePoint Designer

Scénario complexe :

BCS avec du code custom

– Services Azure custom (avec utilisation de certificats)

– Azure Access Control Services

– Azure attaque SharePoint avec CSOM, REST ou des webservices

On débute la démo…

Des images sont stockées sur Azure Blob Storage.

Un site Web Azure consomme ces images et une base SQL azure via un connecteur.

SharePoint attaque le site Azure  et le connecteur vers la base.

Après avoir créé une règle de pare feux dans Azure pour autoriser SharePoint à s’y connecter, on lance Visual Studio.

Un petit coup d’œil aux services partagés de Azure.

On consulte les données de la base et les images associées (dans le Azure Blob Storage) ainsi qu’une liste SharePoint avec des données similaires (liste avec approbation).

On constate aussi que les éléments approuvés sont listés sur le site Web Azure.

Comment est-ce possible ?

Retour à Visual Studio. La solution contient plusieurs projets : du SharePoint et du Azure.

Le projet Azure regroupe les services pour l’accès aux données et la partie paramétrage pour se connecter à la base SQL et à SharePoint (adresses des sites, usernames, passwords, chaine de connexion, …)

On met en pratique les scénarios évoqués précédemment.

Scénario simple :

Une WebPart contient une IFrame affiche les données depuis une page du site web Azure

Scénario moyen :

Dans une WebPart content editor, on utilise du javascript (JQuery+JSon) pour attaquer le service azure et afficher les données.

Scenario complexe :

On retrouve une page aspx (côté Azure) qui attaque SharePoint pour importer dans Azure puis modifie l’état des items SharePoint (approbation)pour indiquer qu’ils ont été importés.

La récupération des items SharePoint est faite avec CSOM (l’authent se fait avec un cookie container récupéré depuis un webservice SharePoint en lui envoyant le username et le password)

On utilise les services SharePoint pour récupérer les images stockées dans SharePoint et les importer dans le Blob Azure.

L’exemple n’est pas très pertinent mais nous montre les différentes possibilités d’interaction.

Sujet intéressant. La difficulté de communication entre SharePoint et Azure réside finalement dans l’authentification.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :