Le Post Infeeny

Les articles des consultants et experts Infeeny

Archives Mensuelles: octobre 2011

SharePoint Conference 2011 : C’est fini !

Voilà qui conclut cette semaine à la SharePoint Conference 2011 à Anaheim. Celle-ci aura été intéressante dans l’ensemble même si comme de plus en plus souvent sur ces évènements à forte population (7500 personnes rappelons-le), le niveau des sessions est assez déséquilibré avec des choses formidables et d’autres plus que moyennes voir médiocres.

Vivement l’année prochaine à Las Vegas avec l’annonce du probable SharePoint 2013   ;–)

Le programme de l’après-midi va être un peu de tourisme à Los Angeles (Venice Beach, Santa Monica, Beverly Hills…) avant de reprendre l’avion demain dans la journée pour enchainer sur 11h de vol (mais ça le vaut bien).

Quelques photos souvenirs …

How Microsoft Built Academy, it’s social Video Platform

Session animée par Austin Winters

La session va aborder un sujet qui intéresse de plus en plus de monde aujourd’hui: comment intégrer un « Youtube » dans mon entreprise ?

On va pour ça prendre l’exemple d’Academy, la plateforme de partage de vidéos mise en place par Microsoft.

On commence par visionner une vidéo amusante sur notre sujet, histoire de détendre un peu l’atmosphère pour cette dernière session de la SharePoint Conference 🙂 .

Nous allons parler patterns, architecture et intégration de fonctionnalités sociales puis montrer que SharePoint 2010 peut parfaitement répondre à ce besoin.

Quelques composants clés d’une plateforme de partage vidéo dans SharePoint :

  • Les fonctionnalités communautaires et sociales
  • Le stockage de documents, l’affichage (ici les documents sets), la gestion
  • La taxonomie
  • Le moteur de recherche FAST
  • Le design de portail
  • Windows Media Services

On décrit maintenant le pattern d’un portail.

D’abord le publishing site. Sa gestion est faite côté client.

Puis le document center et l’intégration des documents sets offerte par SharePoint 2010.

Puis le stockage des données,  elles peuvent être stockées dans SharePoint ou utiliser le RBS.

Puis les services partagés, avec la taxonomie, la recherche, …

On reparle des documents sets et des fonctionnalités sociales offertes par SharePoint : tagging, rating, commentaires, my sites, …

Ensuite on aborde le sujet FAST qui permet de faire des recherches poussées sur les vidéos.

La WebPart de recherche FAST permet d’afficher des résultats de type vidéos liés au contexte de la page.

Un lab est disponible, pour ceux qui veulent se lancer dans l’aventure: http://aka.ms/podcasting .

On passe maintenant à une démo.

La collection de sites présentée reprend le pattern évoqué plus haut.

On voit un publishing site, un document center avec des documents sets, …

La Home Page des documents sets est customisée pour permettre l’affichage de la vidéo.

Ils ont fait le choix de supprimer le ribbon afin de simplifier la contribution pour les utilisateurs et de ne pas les  perdre dans une multitude de fonctionnalités dont ils n’ont pas besoin. L’un des seuls boutons présents est le bouton d’upload.

L’upload de vidéo déclenche la création d’un document set.

La home page du document set est complètement customisée. Elle ressemble à s’y méprendre à la page de visualisation d’une vidéo sur Youtube 🙂

On a un lecteur de vidéo, l’affichage d’informations comme son hauteur, sa durée, … les actions classiques comme l’envoi à un ami, une zone de commentaires, …

Un bouton visible uniquement par le contributeur permet de créer un aperçu de la vidéo à un moment précis. L’aperçu de la vidéo est stocké dans une bibliothèque est utilisé notamment dans les résultats de recherche. La vidéo est également stockée dans SharePoint mais le speaker insiste sur le fait qu’il s’agit d’une démo et que le chargement de vidéos depuis une base de données est  lourd.

Sur un environnement de production il faut absolument la stocker sur un serveur dédié. Ca permet par exemple le streaming.

On voit ensuite les différentes modifications apportées à l’affichage des résultats de recherche.

On définit les éléments utiles pour la gestion de vidéos : les metadonnées, l’encoding live, le transfert, la contribution des utilisateurs…

Un graphe présente le process depuis l’arrivée des vidéos vers SharePoint jusqu’à la sortie vers les supports tels que tv, xbox, dvd, ipad, …

Le graphe en 3 mots :

Create -> Manage(SharePoint) -> Experience (medias)

On voie ensuite le process d’upload,  avec les bases de données etc…

Les medias sont stockés sur des serveurs, les metadonnées dans des bases de contenu. SharePoint fait le lien entre tout ça.

Le moteur d’encodage met à jour les métadonnées automatiquement à partir d’un fichier vidéo.

SharePoint ne gère pas directement l’affichage de la vidéo, il charge juste, par exemple, un contrôle SilverLight qui lui va rechercher la vidéo sur un serveur distant.

On peut même faire appel à une plateforme de streaming externe pour le stockage des vidéos.

Retour à une démo sur Academy…

On voit comment les pages sont construites.

Ils utilisent beaucoup la fenêtre modale fournie avec SharePoint 2010 pour la navigation et l’affichage des vidéos.

On voit les différentes fonctionnalités présentes sur la page du document set : I like it, génération du code html pour l’intégration dans un autre site, … pour faire simple, tout ce qu’il y a sur Youtube.

Il montre en détail les métadonnées du document set : la taxonomie est très utilisée !

Puis le process d’upload de la vidéo vers un dossier. C’est le champ DocumentID qui est utilisé pour nommer le fichier sur le file system.

L’aperçu de la vidéo est envoyé vers un serveur de fichiers et la vidéo vers un serveur de streaming.

Beaucoup de choses sont fournies OOTB comme le rating par exemple, les statistiques de consultations …

On peut pluger des outils du marché pour avoir des statistiques supplémentaires.

Les mysites sont également très customisés. Ils ressemblent à une page de profil Youtube.

On peut vraiment faire des choses très poussées avec la vidéo sous SharePoint si on met en place l’infrastructure qui va avec.

Je vous recommande d’aller voir le podcast car la session était très intéressante 🙂 .

Best practices for creating Publishing Page Layouts

Session animée par Geoffrey Edge

Nous allons aborder dans cette session les bonnes pratiques pour la création de page layouts dans SharePoint.

  • On commence par le sommaire :
  • Le moteur de rendu des pages publishing
  • Les différences entre masterpage et page layouts
  • Les composants d’un page layout
  • L’impact du contenu et du design du site sur les page layouts
  • Les exemples avec le site brembo ou sharepoint.microsoft.com
  • La création des page layouts
  • Le déploiement

Le moteur de rendu fonctionne de la manière suivante : le navigateur requête la page, le page layout est recupéré, la masterpage est récupérée, les contrôles présents dans le page layout génèrent le rendu des champs de la page.

On nous rappelle la différence entre la masterpage, qui constitue la structure commune à toutes les pages, du page layout, qui charge des contrôles dans les zones prévues (PlaceHolders).

Le contenu d’un page layout :

  • Les zones de webparts
  • Les contrôles des champs
  • Les div, …
  • Le css
  • Le code behind (parfois)
  • La navigation de contenu (différent de la navigation du site)
  • Les textes et images non éditables.

On commence la première démo.

On nous présente un exemple de page avec un branding très poussé. Ca ne ressemble pas vraiment à un site SharePoint.

Les éléments qui  n’appartiennent pas à un page layout :

  • La navigation de site
  • Le branding commun
  • Les éléments du head

Nous abordons ensuite l’impact du site.

Les besoins du site définissent les best practices.

Le type de site impacte les page layouts, le nombre de pages, l’audience cible du site, la templatisation.

On évoque différents types de sites : micro sites, les brochures, les knowledge bases, les sites de eCommerce, les sites corporate et bien d’autres…

L’emplacement des pages définit ce qui est dans le layout. Les pages « top level » on peut de champs en général.

Plus on descend dans la hiérarchie, plus les pages sont structurées.

Page d’accueil -> page de catégorie -> page de contenu

Une nouvelle démo nous permet de mettre en évidence tout ça.

On voit la structure de la home page d’un site, puis des pages de contenus (produits), …

Concernant la création des page layouts, on peut utiliser Visual Studio ou Sharepoint Designer.

On voit un autre exemple de site qui n’a aucun champ sur sa home, que des zones de webparts.

Sur la page de catégories, idem, il n’y pas de champs par contre sur les pages de produits, plein de champs.

Il est important de limiter ce que peuvent faire les contributeurs et de ne leur laisser l’accès qu’aux éléments qu’ils sont sensés modifier.

Un petit tour sur Brembo a présent.

On fait une démo avec quelques best practices.

Sur une page, on a beaucoup de jQuery et notamment un slide show. Les images sont stockées dans une librairie avec des métadonnées sur les images (temps d’affichage, ordre, ..)

Il conseil l’utilisation de la dataform webpart et de jQuery. La dataform webpart est capable d’agréger des données.

On aborde rapidement le framework de la modal dialog. Elle est uttilisée pour certains contenus. (natif ave SharePoint en appelant SP.UI.ShowModal().

On explique ensuite l’EditModePanel qui permet de gérer les metadonnées de la page non visibles (tags, titre, …). Par exemple, un DelegateControl peut être utilisé pour afficher les valeurs de la balise meta à partir de ces tags.

On voit également l’utilisation de la ContentQuery webpart qui requête certaines pages en fonction d’une metadonnée de l’EditModePanel.  Elle est recommandée pour l’affichage de news par exemple.

Puis on passe la home page du site sharepoint.microsoft.com en mode édition pour voir comment elle est construite.

Concernant les templates, il faut faire attention à en limiter le nombre disponible pour ne pas « perdre » le contributeur.

Pour terminer la session nous parlons de la création des types de contenu et des page layouts.

Il existe plusieurs techniques pour la création de types de contenu: SharePoint Designer, Visual Studio, code, Powershell…

Quelques plugins pour Visual Sudio : Comunity kit for SharePoint, caml.net.intellisense (pratique 🙂 )

Une dernière démo nous montre les différentes techniques.

Il existe aussi plusieurs techniques pour créer des page layouts : SharePoint Designer, Visual Studio , les 2 !

SharePoint Designer : facile, pour les non développeurs, peux flexible, pages déghostées

Visual Studio : plus flexible, réservé aux développeurs.

L’idéal est de designer la page dans Designer puis copier dans Visual Studio pour packager.

Cette session ne nous dévoile finalement pas grand-chose alors qu’il s’agissait d’une session niveau 300.

Localizing SharePoint Solutions

Session animée par Mike Ammerlaan

Nous allons parler ici de la localisation des solutions SharePoint et des éléments  utiles pour la mettre en place.

Le sommaire de la session : la localisation pour les utilisateurs, la localisation pour les solutions full trust, la localisation pour les solutions Sandbox.

SharePoint 2010 supporte la Multilangual User Interface (MUI). Les sites peuvent gérer autant de langues qu’il y a de language packs installés sur le serveur.

Par défaut,  la langue utilisée est celle du navigateur de l’utilisateur mais ce comportement pet être overridé.

On peut utiliser les variations pour les scénarios de sites internet multilingues.

On a langue principal du site, puis les langues additionnelles (en fonction des language packs installés).

Si le site ne supporte pas la langue préférée de l’utilisateur, SharePoint affiche la langue par défaut du site.
Certains éléments du site ne peuvent pas être localisés : les documents, les contenus, …

Après avoir décrit les différentes ressources présentes sur un site, on nous présente ceux pouvant être gérés par la MUI et ceux qui ne peuvent pas.

Les contrôles sont compatibles MUI par défaut.

Les titres des listes, des webparts, … sont compatibles MUI mais peuvent être modifiés par l’utilisateur.

Les contenus ne sont pas compatibles MUI.

Lorsque l’utilisateur choisit sa langue préférée, l’information est stockée dans la UserInfoList de la collection de sites. Il peut choisir une langue différente par collection.

Nous mettons en pratique tout ça en modifiant la langue courante. On constate que certains éléments ne sont pas traduits.

On nous présente la fonctionnalité « export translation » qui permet d’exporter un fichier resx .

On peut alors le modifier et le réimporter depuis l’interface du site pour localiser certains éléments.

Nous passons maintenant à la différence entre les solutions full trust et les Sandbox.

Pour chacune, nous voyons comment localiser les éléments suivants: les pages, les assemblies, les scripts et les fichiers xml.
D’abord, les solutions Full Trust.

Pour les pages :

  • On déploie les fichiers resx dans le dossier AppGlobalResources de la web application
  • On déploie les resources dans le dossier 14\Resources

Pour les assemblies :

  • On déploie dans AppGlobalResources et on utilise HttpContext.GetglobalResourceObject()

Pour les scripts :

  • On déploie les fichiers js dans les dossiers  1033-1036-10… dans le 14
  • Soit on fait 1 fichier js par langue pour les ressources + 1 fichier js pour les fonctions
  • Soit on fait 1 copie du fichier js pour chaque langue (moins recommandé)

Pour les fichiers xml :

  • On déploie les resources dans le dossier 14\Resources
  • On déploie les resources dans le dossier  Feature\Resources
  • On utilise la syntaxe suivante :  $Resources : …

Pour le packaging il y a 2 techniques :

  • 1 gros wsp qui contient tout
  • 1 core wsp + des wsp language packs

On met tout ça en pratique dans Visual Studio…

Après avec créé des fichiers de resx et montré leur appel, on  voit comment gérer les resources dans du Javascript avec l’utilisation de SP.ClientContext.WebLanguage.

On passe ensuite aux cas des solutions Sandbox.

Problèmes des solutions Sandbox, on ne peut pas déployer sur le file system du serveur, donc oubliez les fichiers resx dans 14\resources…

Pour les pages :

  • On déplace la logique coté client (js)
  • On utilise les resx OOTB
  • On fait une page différente par langue

Pour les assemblies :

  • On localise les assemblies

Pour les scripts :

  • Idem aux solutions full trust

Pour les fichiers xml

  • On déploie les fichiers resx dans le dossier de la feature

La session s’achève avec une démo de la solution Sandbox.

Il présente, entre autre, la création de dll localisées.

Advanced BI Visualizations using Visio Services

Session animée par A.J Briant (Product Manager) et Christopher Hopkins

La session démarre par un rappel sur ce qu’est Visio Services et qui permet d’afficher des diagrammes pouvant être connectés à des données et rafraichis.

Dans un contexte BI, les fonctions de « Data Linking » et « Data Graphics » offertes par Visio seront cruciales car ce sont elles qui vont permettre de se connecter et d’afficher des choses jolies.

1ère démo montrant un diagramme Visio affichant une carte des USA (composée de plusieurs formes), ou chaque élément de la carte peut être connecté à une source de données.

On voit comment connecter la carte à un classeur Excel qui est hébergé dans SharePoint. Une fois la source sélectionnée, un tableau apparaît dans Visio et il suffit de sélectionner la ligne qui nous intéresse, la glisser sur la forme (un état des USA dans l’exemple) voulue et automatiquement les 2 éléments sont liés. Cela signifie que si la ligne du classeur Excel change, le diagramme Visio sera mis à jour.

Plutôt que d’afficher les données sous forme de texte, on peut faire du color coding de la forme en fonction de valeurs. Cela est utile notamment pour la gestion de KPI.

D’autres formes sont ajoutés à la carte (des bulles de texte) pour afficher le libellé et la valeur (sous forme d’une gauge) des lignes associés à l’état à laquelle la forme est associée (on utilise les liens de formes de Visio). On continue de faire un peu de cosmétique en associant des formules de calcul.

On insère ensuite une légende au sein du diagramme pour indiquer à quoi correspondent les couleurs, les plages de valeurs de chaque couleur, etc…

Pour sauvegarder le document dans SharePoint, il suffit d’utiliser l’option du même nom dans le menu fichier en faisant attention à bien choisir « Web Drawing » comme type de fichier (sinon le fichier ne sera pas utilisable dans Visio Services).

Retour aux slides pour récapituler tout ce qui a été fait dans la démo.

Passons maintenant au rafraîchissement des données qui peut être fait sur le client ou sur le serveur. Sur le serveur, il faut noter que les données sont mises en cache pour chaque utilisateur (cela signifie que 2 utilisateurs pourraient voir des données différentes si les données ont été modifiées durant le temps ou le 1er et le 2ème utilisateur ont demandé au serveur d’afficher le fichier Visio).

Quand on utilise à la fois un schéma Visio et un classeur Excel, l’utilisateur a besoin d’avoir les droits de lecture sur les 2 fichiers pour que la solution fonctionne.

Un petit tour rapide sur l’architecture en place pour que tout cela fonctionne. La partie intéressante du schéma concerne la possibilité de développer des « Data Adapter » et d’utiliser un API quand on a besoin d’utiliser des sources de données non standard (comprendre pas SQL ou Excel).

2ème démo pour métro un l’add-in Visio nommé SharePoint Network Topology (celui là même envoyé par Emmanuel aujourd’hui à la liste de diffusion SharePoint).

Cet add-in consiste en un job SharePoint qui va récupérer des données sur la ferme SharePoint à intervalles réguliers, les compiler dans un schéma Visio et stocker le schéma dans une bibliothèque  de documents (la collection et la bibliothèque sont définies depuis l’administration centrale).

Il est aussi possible d’utiliser des listes SharePoint comme sources de données, ce que l’on nous montre en créant un nouveau schéma. Si l’on souhaite utiliser des listes externes (via BCS), c’est également possible et il existe un add-in pour cela (le speaker mettra le lien sur son blog si ce n’est pas déjà fait).

Retour aux slides pour évoquer l’API Visio Services qui se présente sous la forme « ECMAScript Object Model ». Ces API permettent de savoir tout ce que l’utilisateur fait comme interaction avec un schéma (clic, déplacement de la souris…) afin de pouvoir réagir en conséquence.

3ème démo montrant l’utilisation de l’API où dans un site SharePoint affichant un schéma de plans de bureaux, on peut sélectionner dans une WebPart des options, qui colorent les bureaux d’une certaine manière, superposent des éléments sur le schéma, etc…

Les démonstrations s’enchainent pour montrer les capacités de mise en forme (ex: gestion de la 3D) associées à l’utilisation de l’API.

Multi-Tenancy with SharePoint 2010

Session animée par Spencer Harbar (Entreprise Architect)

Nous commençons par introduire la notion de multi-tenancy qui revient à vouloir isoler les données, les services et la gestion de plusieurs clients mais sur un environnement mutualisé.

Si on comparait cela à la vie de tous les jours, ce serait un immeuble avec des parties communes (escaliers, portes…) et des éléments propres à chaque personne (l’appartement).

Office 365, des hébergeurs classiques et des Clouds privés proposent ce genre de service mais il est possible de le faire OnPremise (very risky indeed comme l’indique le speaker dans son slide).

La notion de multi-tenancy dans SharePoint 2010 a été implémentée pour être utilisée dans Office 365 à la base.

Le multi-tenancy n’est pas juste une Feature à activer mais beaucoup d’éléments sont impactés (authentification, abonnements, profils…).

Un premier concept qui existait déjà sur SharePoint 2007, les Host Named Site Collection, a été enrichi sur SharePoint 2010 pour supporter les chemins d’accès gérés, les certificats SSL, etc…

Pour séparer les collections des clients, il faut créer des groupes logiques (appelés des Subscriptions) qui ne peuvent être activés que via l’API ou Powershell. Chaque Subscription possède un identifiant unique de type GUID pour l’identifier dans le système.

Les services applicatifs de SharePoint peuvent être partitionnés pour gérer le multi-tenancy mais il faut le faire lors de la configuration de la ferme car cela ne peut être changé ultérieurement (sauf en détruisant et recréant les services).

Les services devant être partitionnés sont ceux stockant des données (recherche, profils…). Ceux ne stockant pas de données n’ont pas besoin d’être partitionnés voir ne supportent pas le partitionnement (cf. photo).

Dans la mesure du possible, il vaut mieux désactiver les développements spécifiques voir les interdire. Le mode sandbox est là pour couvrir certains besoins et tout ce qui ne rentre pas dans une sandbox pourra poser des soucis sur un environnement mutualité.

Les grandes étapes de configuration sont :

  • Configurer les pré-requis côté infrastructure
  • Créer les WebApplications
  • Provisionner les services Applications
  • Créer des lots de Features
  • Provisionner les tenants

1ère démo pour montrer comment configurer la ferme qui a été installée au préalable.

Pour cela on commence par passer en revue un script Powershell qui va se charger de créer une WebApplication avec tous les éléments nécessaires (authentification, base de données, collection de site racine…).

D’autres scripts Powershell finisse de créer les éléments avec dans l’ordre les services Applications, le BCS, le Secure Store et Word Automation.

On voit que depuis l’administration centrale, certains services applications ne sont pas administrantes via les menus classiques, il faut aller dans l’administration des tenants pour accéder aux infos (ex: BCS et Metadata Store).

On passe ensuite à la définition des permissions sur les services applications (toujours via Powershell), on démarre le service de profils utilisateurs et on fini par configurer la recherche.

Retour aux slides pendant que la recherche se configure car cela prend plusieurs minutes.

Les pré-requis côté infrastructure concernent le réseau, le DNS, ActiveDirectory (notamment une OU pour chaque client), la ferme SharePoint et les comptes de services.

Les slides montrent les extraits importants des scripts Powershell qui ont été exécutés dans la démo précédente (les slides seront sur le réseau MCNEXT dans le courant de la semaine prochaine).

Retour à la démo pour vérifier que la recherche a finie d’être configurée, ce qui est le cas vu que la démo a bien été préparée   😉

On créer maintenant un Feature Pack dans lequel on défini toutes les features qui seront disponibles pour le tenant auquel sera affecté le pack.

On termine la configuration par le provisioning du tenant en spécifiant le nom, le mail, le feature pack devant être utilisé, la WebApplication associée, les MySite, un Content Type Hub…

Une fois que tout est configuré, on voit que l’on peut accéder aux services sans soucis (le people picker ne fait apparaître que les gens de l’OU du tenant, le TermStore est vide et on peut commencer à créer des termes, etc…).

On voit notamment qu’un site a été créé lors du processus de configuration des tenants (1 site par client), pour accéder aux options d’administration propres à chaque société.

Retour aux slides pour donner quelques trucs et astuces.

Le mode multi-tenancy ayant été à la base pensé pour Office 365, il faut suivre les mêmes recommandations d’usage pour l’implémenter OnPremise sinon il y aura de gros soucis.

Parmi les choses à ne pas faire, utiliser le multi-tenancy parce qu’on a vu que ça existait que ça a l’air cool. Il faut en avoir l’utilité avant de le mettre en œuvre.

De fortes contraintes sont imposées pour installer le multi-tenancy donc il faut bien réfléchir aux éléments qui impacteront le réseau de l’entreprise (ex: la structure AD) avant de se lancer dans l’installation.

FAST, PerformancePoint et Project Server ne sont pas supportés.

L’utilisation du mode d’authentification par Claims et plus que recommandée (voir obligatoire).

Il faut aussi savoir que l’implémentation du multi-tenancy requiert souvent du développement additionnel pour par exemple créer des interfaces permettant d’administrer la solution (plutôt que de tout faire via Powershell).

Service Application Partitioning

Service Application Partitioning

Building Business Applications on Azure using Office 365 and Windows Azure AppFabric

Session animée par Tony Meleg (Microsoft)

En général une application est constituée d’entités et de données, de formulaires avec de la logique, d’informations, de contenus et de processus

Pour construire une application, on a besoin d’outils (Visual Studio), de langages (C#), de Frameworks (SharePoint est considéré comme tel) et des services (bases de données, rapports, messagerie, cache, workflow, planification…)

Qu’est-ce qu’Office 365 apporte pour répondre aux besoins exprimés ci-dessus ? Et bien il offre toutes les briques nécessaires pour construire une application (cf. la photo prise montrant les connexions entre les différentes briques)

La suite de la session va permettre d’entrer plus en détail sur les différents concepts exposés dans le slide précédent

Quelle est la stratégie sous-jacente ici pour construire les futures applications ?

On peut continuer à héberger les applications comme aujourd’hui (OnPremise) ou bien utiliser le Cloud. Il doit également être possible d’utiliser n’importe quel langage, de virtualiser les applications (pour les rendre facilement portable) et de viser le concept de PaaS (Platform as a Service) pour utiliser des Clous privés ou publics

Parlons maintenant de la virtualisation et de la différence de IaaS (Infrastructure as a Service) avec PaaS (Platform as a Service)

Une application nécessite beaucoup de briques fonctionnelles différentes, qui souvent sont découpées fonctionnellement pour pouvoir faire évoluer une brique indépendamment des autres. Ce signifie qu’un nombre très important de machines est requis pour mettre en œuvre une application, ce qui représente un coût important.

La virtualisation est là pour répondre à ces besoins en réduisant le coûts car un serveur correspond à 1 fichier VHD, ce serveur embarquant tous les composants nécessaires au fonctionnement de l’application

IaaS est du coup familier aux développeurs qui ont le contrôle sur ce qui est déployé, les machines virtuelles sont portables, il n’y a aucune différence avec le développement classique et SharePoint Online est là pour héberger des services tels que la collaboration

IaaS propose généralement une bibliothèque de machines virtuelles prêtes à l’emploi pour créer des serveurs web, des serveurs SQL… Il ne reste qu’à configurer les composants spécifiques à l’application (structure de base de données, binaires de l’application…), dupliquer les machines pour assurer une montée en charge importante, configurer de l’équilibrage de charge et le tour est joué (ça à l’air simple dit comme ça   ;-))

Oui mais la partie provisioning de base de données, gestion de la sécurité, gestion des contenus des sites web… est plutôt du ressort de PaaS donc comment faire cohabiter le 2 ?

PaaS propose différents rôles qui peuvent être utilisés en combinaison avec IaaS, notamment le rôle de stockage de données qui peut être partagé par plusieurs clients, dupliqué, sauvegardé et restauré, etc…

Dans le modèle PaaS, chaque service est multi-tenant (utilisé par client) et non dépendant de la machine sur laquelle s’exécute l’application. Les clients fournissent les éléments de l’application et ne s’occupent jamais de la partie infrastructure. Le fait de découper une application en différents rôles permet de maximiser les ressources utilisées et de pouvoir déplacer un bout de son application plus facilement.

Quelques règles doivent êtres respectées pour faire du PaaS :
– Les applications doivent être faiblement couplées aux services et pouvoir s’exécuter sur plusieurs machines en parallèle
– 2 instances ne doivent jamais être connectées l’une à l’autre directement
– Une instance peut planter sans prévenir et l’application doit gérer ce cas comme étant « normal » et continuer de fonctionner

Azure propose de faire du PaaS en proposant des rôles de type web, stockage, SQL et reporting pour créer des applications web. SharePoint Online propose les services de collaboration, site Internet… D’autres fonctionnalités comme les worker rôles, la gestion du trafic, le fourniture de contenus (CDN) et la connexion inter-applications sont également offerts par Azure.

Pour créer des applications avec des fonctionnalités avancées, on peut aussi utiliser les briques suivantes:
– Access Control pour gérer l’authentification et l’identité des utilisateurs
– Caching pour stocker des données en mémoire plutôt qu’en base de données (pour améliorer les performances)
– Service Bus pour interconnecter les applications, notamment faire un mix entre des applications Azure d’autres hébergées sur le système d’information de l’entreprise
– Integration (pas encore disponible à ce jour, en version CTP mais arrive prochainement)
– WebServices + Workflow (workflow en cours de développement, CTP à accès privé en cours)

On passe maintenant en revue le fonctionnement des briques décrites ci-dessus. Plutôt que de vous faire un long discours, je vous laisse vous référer aux articles MSDN/Technet sur le sujet qui seront beaucoup plus complets que ce que je pourrais écrire ici et les explications données par le speaker restent assez générales.

Enfin une démo alors que la session se termine dans 5mn. Une application Silverlight est hébergée dans SharePoint Online et utilise Service Bus pour soumettre des commandes à un service WCF hébergé le portable du speaker. Une application console fait office de service WCF et on voit que lorsqu’on interagit dans SharePoint avec l’application Silverlight, les commandes sont transmises à l’application console.

Même style de démonstration avec les Topics AppFabric pour montrer le principe de publish/subscribe de cette partie de AppFabric. Des commandes sont envoyées depuis l’application Silverlight, puis celles-ci sont récupérées depuis des applications console faisant office d’abonnés.

Une nouvelle fois et malgré un niveau 300, la session est restée assez généraliste et nous n’avons pas vu comment arriver aux résultats démontrés. Nous voyons juste que cela fonctionne sans plus de détails  😦

The inside scoop: How the SharePoint Dev Team Troubleshoots Performance and Reliability

Session animée par Corey Roussel

La session débute par un comparatif entre la façon dont les formulaires étaient créés dans le passé et maintenant.

Les formulaires nécessitaient forcément du code, les changements étaient coûteux.

Alors que maintenant avec SharePoint, n’importe qui peut créer ses formulaires sans aucun développement. On ne peut bien sûr pas faire ce que l’on veut de cette manière mais c’est quand même bien 🙂

N’importe qui peut faire son site maintenant !

Il parle de la culture « dogfood » de Microsoft. Je n’ai pas trop compris le concept… En tout cas ils ont énormément de projets à gérer en parallèle et de mises à jour à gérer.

Comment font-ils pour monitorer tout ça ?

On commence par parler de code, avec la classe SPMonitoredScope qui permet de capturer les performances pour des parties de code spécifiques.

On peut, par exemple, logger le fait qu’une partie de code mette plus d’un certain laps de temps à s’exécuter. Il montre un exemple de code…

A ne pas utiliser à tout bout de champ cependant ! Ça peut ralentir les performances…

Les administrateurs en sont assez friands, ça leur permet d’identifier rapidement les codes custom qui viennent dégrader leur plateforme.

On passe ensuite au Developer Dashboard.

Il est bien car tout n’est pas forcément visible dans les logs et qu’il permet de cibler une page particulière.

Petite démo du Developer Dashboard…

Si on utilise le SPMonitoredScope, les informations qu’il renvoie sont directement visibles dans une des zones du Developer Dashboard.

On décrit ensuite précisément les éléments présents dans le Developer Dashboard.

Il peut être activé de plusieurs manières : à partir du Developer Dashboard Quicklaunch Control présent dans la page, avec le paramètre « ?developerdashboard=true » passé dans l’url, en paramétrant le serveur, …

Par contre, il ne permet pas de visualiser les informations sur les opérations exécutées  coté client.

Les MasterPages custom doivent l’intégrer ainsi qu’éventuellement le Quicklaunch Control.

On passe ensuite la base de données d’Usage & Logging.

Nous avons : les statistiques du Developer Dashboard, l’exécution des timer jobs, les event logs, les requêtes SQL…

L’inconvénient, c’est qu’SQL est couteux à l’usage.

On parle maintenant de SharePoint Diagnostic Studio 2010 qui est maintenant disponible en téléchargement.

Nous avons droit à une petite démo… de nombreux graphiques, des stats, des camemberts, …

Effectivement on peut visualiser vraiment beaucoup d’informations! On passe en revue les différents onglets de l’outil.

Il y a des informations sur les performances, les requêtes SQL, le nombre de requêtes par utilisateur, Le nombre de requêtes par site, …

C’est bien pour détecter les bugs mais pas forcément pour le monitoring car c’est un outil qui nécessite des actions manuelles.

On parle donc maintenant d’automatisation et de monitoring.

Ne pas laisser l’humain faire le job d’un robot ! Il faut automatiser/scripter les  tâches répétitives et continues.

Il est possible scripter pour exporter vers un data warehouse, on peut utiliser les tâches planifiées de windows, envoyer des mails automatiques, …

On peut utiliser SQL  Query Profiler pour récupérer les informations de SharePoint Diagnostic Studio 2010.

On passe à une démo dans SQL Management Studio  avec différentes requêtes pour récupérer des informations depuis les bases de log de SharePoint.

La session termine avec pas loin de 30 min d’avance ! Tant pis, ça laisse plus de temps à l’assemblée pour les questions…

Performance Tuning SharePoint 2010

Session animée par Eric Shupps

Notre speaker  un énorme chapeau de cowboy. Il fait visiblement honneur à son surnom de « SharePoint cowboy ».

Nous n’aborderons pas ici l’aspect programmation mais plutôt l’administration.

Le sommaire de la session :

  • L’infrastructure : le réseau,  les serveurs, les bases de données
  • La configuration : la mise en cache, la compression, le throttling, les locks
  • Les pages : la customisation, le branding, les listes
  • Les outils

On commence par l’infrastructure.

Premier problème rencontré sous SharePoint, les nombreux accès aux bases de données, ce qui engendre une dégradation progressive des performances.

Il est important de séparer le trafic des serveurs de bases de données du trafic des serveurs Web. Il est mieux qu’ils soient sur de réseaux différents.

Nous avons droit à un beau graphique représentant l’architecture idéale.

Concernant le serveur exécutant le moteur de recherche, il est mieux qu’il se crawl lui-même plutôt qu’il crawle les serveurs Web ce qui génère du trafic inutile sur le réseau.

Pour déterminer l’architecture à utiliser, il est important d’estimer les fonctionnalités les plus importantes pour notre plateforme.
Les opérations de lecture demandent plus de serveurs Web.

Les opérations d’écriture nécessitent plus de serveurs de bases de données.

Les opérations  de recherche nécessitent plus de serveur d’applications.

D’un point de vue géographique, il faut garder à l’esprit que les distributions globales nécessitent des fermes locales.

Notre cowboy nous montre ensuite les impacts des différents types d’opérations sur les bases de données. Le plus gros consommateur est la recherche, vient ensuite la collaboration puis les requêtes de contenu…

Les développeurs et les administrateurs ont tout intérêt à travailler ensemble pour faire les bons choix plutôt que de se rejeter la faute mutuellement en cas de problème.

Pour estimer la quantité de documents d’un site, voici la formule magique: ((DxV)xS)+(10kbx(L+(VxD)))
D = nombre de documents
S = taille des documents
V = nombre de versions
L = éléments de liste

Il ne faut également pas oublier que les analytics peuvent être conséquentes et doivent être isolées des autres données.
Une base de contenu doit idéalement être limitée à 200go (max supporté : 4to)

Une base de données peut représenter volume énorme de données : il faut isoler le crawl du temp.

Un point important : configurer l’auto growth manuellement !!!

D’autres points importants : isoler les logs de transactions, faire des backups réguliers, défragmenter, utiliser des quotas….

On attaque ensuite le sujet de la mise en cache.

Les bons développeurs doivent utiliser le cache pour les données !

On parcourt quelques exemples de codes à éviter.

De nombreux caches sont disponibles sous SharePoint: l’output cache, le blob cache, le db caching…

On passe à présent à la démo

Nous voyons qu’en activant la feature publishing sur un site, il est possible de paramétrer l’output cache et des profils de cache.

Petit tour dans Visual Studio pour tester la charge du serveur. De nombreux indicateurs sont disponibles. On se concentre sur le temps de chargements des pages.

On active le blob cache pour voir l’impact sur les performances. Ici, les images et les css sont copiés sur le file system. Faire attention au dossier qu’on a paramétré pour le blob cache. Il ne faut pas copier les fichiers n’importe où.

Effectivement les temps de réponse sont beaucoup plus rapides  !
Ensuite, on active l’output cache dans le paramètres de la collection de sites. C’est encore plus rapide !!! On a diminué de 70% les temps de chargement.

On aborde maintenant la compression IIS.

Elle diminue la taille des fichiers qui transitent sur le réseau mais, attention, elle augmente l’utilisation du cpu. Il faut y aller doucement.

On peut définir pour quels types de fichiers on veut l’activer. C’est très utile pour les fichiers comme le core.js par exemple qui est relativement lourd.

Nous voyons un exemple de script pour l’activer.

Le throttling et les locks permettent de limiter le nombre de données remontées par les requêtes. C’est configurable, il peut être désactivé pour les administrateurs ou pendant des périodes précises.

Le byte rate throttling contrôle, lui, la vitesse de téléchargent des fichiers comme les flashs ou les vidéos.

On illustre tout ça avec une démo.

Ça n’améliore les performances mais ça évite les problèmes en cas de requête remontant de nombreux éléments.

On passe maintenant aux pages.

Dans SharePoint, les pages contiennent beaucoup de contrôles. Il faut faire attention à ce que font les contrôles et à la quantité des données qu’ils consomment, surtout pour les accès en base.

Quand on customise une page depuis SharePoint Designer, cette page est copiée en base (deghost), ce qui implique des accès en base supplémentaires. Au passage, Eric nous donne son avis sur SharePoint Designer. Pour résumer ses propos, c’est nul ! Et toute la salle applaudit ! 🙂

Il ne fait pas oublier que lorsqu’on customise une page, les performances diminuent de 10% en moyenne. Ne pas hésiter à cliquer sur « reset to site définition », tant pis pour les modifications effectuées… !

Concernant le branding, il recommande d’utiliser une masterpage mini pour commencer, de minimifier les fichiers, d’utiliser des images split avec css (il y a des outils pour ça), de privilégier la copie des fichiers sur le file system plutôt que sur des emplacements virtuels (librairies), de regrouper les css en un seul fichier plutôt qu’en plusieurs.

Concernant les listes, ce n’est pas parce qu’on peut faire qu’il faut faire !!! Faire attention aux requêtes. Les Webparts Listview utilisent maintenant du xslt mais il faut tout de même faire du code custom pour les affichages de listes très larges.

Plus de 5000 ligne dans une liste c’est beaucoup (c’est la limite de throtthle par défaut). Plus il y a de  colonnes, plus il y a de lignes SQL. Beaucoup de lignes SQL peuvent diminuer les performances de 35%.

Utiliser le Remote Blob Cache pour éviter le stockage de gros fichiers en base.

Pour finir, nous passons en revue quelques outils, notamment le Developer Dashboard qui permet d’avoir des informations au chargement de la page : voir les requêtes qui passent, les contrôles, les temps d’exécution de chaque élément…

La session s’achève avec une démonstration du Developer Dashboard.

Developing LOB Connectors in SQL Azure and Business Connectivity Services

Session animée par Scot Hillier (MVP SharePoint)

La session commence par introduire ce qu’est SQL Azure et apparemment, ce serait une base de données SQL dans le Cloud   😉

1ère démo pour montrer comment créer une base de données SQL Azure. Pour la 1ère fois depuis que j’assiste à des conférences, la démo n’est pas réalisée en Live mais elle a été enregistrée sous forme d’un screencast qui est lu dans Windows Media Player et commenté en Live.

On commence par aller dans console Azure pour demander d’activer la fonctionnalité SQL Azure puis on demande ensuite de créer un serveur SQL en choisissant le continent sur lequel héberger celui-ci. Durant le processus de création du serveur, il est possible de créer des règles de firewall pour autoriser certaines adresses IP à administrer l’instance depuis SQL Server Management Studio.

Une fois le serveur créé, on peut créer une base de données et sélectionner quelle taille sera donnée à celle-ci. La taille affectée influe sur combien vous paierez tous les mois donc attention à bien évaluer la taille.

On peut ensuite utiliser SQL Server Management Studio pour administrer l’instance, de la même manière que si le serveur de base de données était hébergé sur le réseau local.

Vu que SQL Azure peut être administrer depuis la console SQL, il est possible de générer des scripts de bases de données hébergée On-Premise et d’exécuter ces scripts sur les bases Azure pour créer la structure et importer des données (c’est ce qui est montré dans la vidéo). Il faut toutefois faire attention car certaines fonctionnalités disponibles sur les bases locales, ne sont pas disponibles sur le Cloud (ex: PAD_INDEX) donc il peut être nécessaire de faire du ménage dans les scripts générés.

Pour copier les données entre les 2 bases de données (locale et dans Azure), un projet SSIS est créé dans Visual Studio puis exécuté.

Retour aux slides pour présenter Business Connectivity Services (BCS) et plus particulièrement l’architecture derrière avec la notion de connecteurs qui sont les sources de données peut être manipulées par la plateforme.

Si jamais on souhaite connecter une source de données non prévues à la base avec SharePoint, il est possible de développer ses propres connecteurs BCS (ex: développer un connecteur pour Exchange Server).

Pour manipuler une source de données BCS dans SharePoint, il suffit de créer une « External List » et chose intéressante, il est possible de synchroniser ces listes avec Outlook 2010 pour travailler en mode déconnecté.

Il est également bon de noter que BCS n’a pas nécessairement besoin de SharePoint pour fonctionner car une partie des composants sont embarqués dans Office. Cela permet notamment de pouvoir faire communiquer directement Office avec un système LOB (ex: une base SQL Azure).

2ème démo (toujours pré-enregistrée) montrant comment stocker les informations d’authentification pour SQL Azure, dans le référentiel « Secure Store Service » de SharePoint. C’est la même chose que ce qui a été montrée dans la session sur l’intégration des réseaux sociaux dans les sites Internet.

Retour aux slides pour introduire les « External Content Types » qui vont permettre de définir à quelle source de données se connecter et quelles opérations seront autorisées ou non sur cette source de données.

Pour créer un « External Content Type », il est possible d’utiliser SharePoint Designer ou Visual Studio.

3ème démo enregistrée sur l’utilisation de SharePoint Designer pour créer un « External Content Type » qui se connectera à la base SQL Azure.

Grâce l’assistant de SharePoint Designer, on voit qu’il est possible d’utiliser le « Secure Store Service » paramétré précédemment, pour récupérer les informations d’authentification  pour se connecter à la base SQL Azure créée lors de la 1ère démo.

Une fois le type de contenus créé, il suffit dans SharePoint, de créer une « External List » et de lui associer le type de contenu créé précédemment pour pouvoir manipuler les données stockées dans la base de données SQL Azure. En fonction des paramètres sélectionnés lors de la création du type de contenus, il est possible d’effectuer plus ou moins d’opérations (création, modification, suppression…).

Si on demande, via le bouton présent dans le ruban, de connecter la liste à Outlook, alors celle-ci est synchronisée avec Outlook et utilisable directement pour être mise à jour. Cela fonctionne notamment car dans l’exemple présent, le type de contenus externe avait été défini comme utilisant un modèle de liste « Contact » comme base.

Retour aux slides pour montrer l’équivalent de SharePoint Designer mais au sein de Visual Studio et pour indiquer qu’il est possible de développer ses propres connecteurs sous la forme d’assemblé .NET.

Session très décevante car il n’a pas du tout été question de développer des connecteurs, mais simplement de paramétrer BCS dans SharePoint pour se connecter à une base SQL Azure   😦