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   😦

SharePoint, Azure and Claims Integration for Developers

Session animée par Steve Peschka (Principal Architect) et James Petrosky (Solutions Architect)

L’intégration avec Azure possède quelques challenges comme la difficulté de récupérer des données, appliquer les autorisations SharePoint dans Azure, gérer la latence sans impacter l’expérience utilisateur, etc…

Le CASI Kit (Claims Azure SharePoint et I…) est là pour couvrir 3 scénarios :

  • Afficher des données depuis Azure
  • Récupérer des données pour les utiliser dans d’autres WebParts
  • Pas le temps de noter   😉

Comment fonctionne le CASI Kit ? Le client demande une page à SharePoint sur lequel est installé le CASI Kit. Ce kit communique avec Azure via des services WCF, ces services étant chargés de récupérer les données où elles sont (SQL Azure, On-Premise via AppFabric…).

Le kit est composé de 2 composants : 1 classe de base (composant ASP.NET) qui encapsule les connexions à Azure et le détails des contrats WCF et une WebPart qui s’occupe de récupérer les données de manière asynchrone pour les afficher.

Le kit comporte aussi de nombreux guides de bonnes pratiques pour créer des services WCF, héberger des services WCF dans Azure, règles de programmation, etc…

Parmi les guides, celui sur les services WCF et celui sur Azure aident les développeurs à écrire des services capables de fonctionner aussi bien On-Premise que dans Azure en respectant des règles de base pour assurer une maintenance simple. Des choses plus bas niveau comme les question autour des patchs nécessaires, de la gestion des certificats SSL et des DNS sont également inclus dans ce kit.

Une fois configurer correctement, le service WCF est capable de récupérer le jeton SAML de l’utilisateur pour effectuer les traitements adéquats en fonction de ce jeton.

Il est possible d’ajouter une PrincipalPermission sur une méthode pour déterminer quels rôles ont le droit d’appeler telle ou telle méthode du service WCF.

Dans ce cas, la méthode ne peut être utilisée qu’en conjonction avec SharePoint car le système de Claims de SharePoint crypte les données d’une certaine manière et qu’il n’est pas possible de contourner ce mécanisme.

La classe de base inclus dans le kit est fait pour les développeurs qui veulent créer de nouveaux contrôles, développer des applications qui appellent le service WCF, etc…

Cette classe de base doit être surchargée d’après les bonnes pratiques et quelles méthodes doivent être surchargées pour rendre la solution utilisable.

L’utilisation dans SharePoint se fait ensuite en 2 lignes à ajouter dans les layouts : ajouter une référence vers l’assembly du kit et ajouter le contrôle avec les bons paramètres (URL du service WCF, nom de la méthode…) à l’endroit où doivent apparaître les données.

Vu que tout ce qui concerne la connexion à Azure est géré par la classe de base, il n’y a aucune modification à faire dans le web.config même si des changements interviennent dans la chaine (changement d’URL, renommage de méthodes…).

La WebPart est très simple d’utilisation et à déployer car tout est compris dans le package (jQuery est compris dans lot). Le paramétrage de la WebPart (nom de la méthode du service WCF et paramètres à utiliser) se fait via les options classiques de SharePoint (ToolPart).

Pour partager des données issues d’Azure entre plusieurs WebParts, il suffit d’utiliser le cache ASP.NET pour les stocker et les récupérer.

Si l’on souhaite utiliser le kit dans Powershell ou via un job SharePoint, il y a un souci car il n’existe pas de contexte HTTP dans ces 2 cas. Dans ce cas il suffit de paramétrer la propriété SharePointClaimsSiteUrl pour permettre aux composants de fonctionner correctement.

Passons à la démo pour monter une solution de A à Z à partir du kit.

Une solution Visual Studio a été créé avec un minimum de choses. On commence par ajouter des références vers Microsoft.SharePoint, System.Web et System.XXX (pas eu le temps de noter) puis on ajoute une référence vers le service WCF déployé dans Azure.

On ajoute ensuite une classe qui hérite de la classe de base du kit (AzureConnect.WcfConfig).

On surcharge ensuite la méthode ExecuteRequest et on écrit le code pour appeler la méthode adéquate du service WCF.

On ajoute maintenant une page ASPX dans le répertoire LAYOUTS de SharePoint, cette page allant servir de proxy aux WebParts pour effectuer les appels au contrôle du kit, qui sera lui même en charge d’aller récupérer les données sur Azure. Cette page est là pour éviter les problèmes de cross-domain car le contrôle utilie jQuery qui nécessite pour bien fonctionner, que tous les composants soient hébergés sur le même domaine DNS.

On compile et on déploye la solution sur la ferme SharePoint, on édite la page d’accueil du site et on ajoute la WebPart qui est censée affichée les données et fournie dans le kit.

On édite les propriétés de la WebPart pour spécifier le nom de la page située dans LAYOUTS qui va être utilisée, on valide les modifications et là miracle, les données issues d’Azure apparaissent   😉

La WebPart affiche les données issues du token SAML et fournies par le système de Claims de SharePoint et l’on voit effectivement toutes les données correspondant à l’utilisateur (login, firstname, lastname…).

Le code source de la démo présentée sera mis à disposition sur le blog de Steve Peschka dans quelques jours – http://blogs.technet.com/b/speschka.

Autre annonce importante, le code source du CASI Kit sera accessible sur Codeplex très bientôt suite à la demande de quelques clients aux USA – http://casikit.codeplex.com.

Le CASI kit à l’air intéressant mais il est dommage qu’on ai pas du tout vu dans la démo ou même abordé dans les slides, comment paramétrer le système de Claims de SharePoint pour que tout cela fonctionne.

Integrating Social Networks into SharePoint Internet Sites

Session animée par Brian Rodriguez et Ryan Sockalosky (Microsoft)

A ce jour, plus de 750 Millions d’utilisateurs dans le monde sont sur les réseaux sociaux.

73% de la population Américaine se connecte aux réseaux sociaux et 50% des utilisateurs le font tous les jours.

Les réseaux sociaux servent à faire la promotion des sociétés/marques/produits via des groupes dédiés sur Facebook.

Mais l’inverse est aujourd’hui de plus en plus présent où les réseaux sociaux s’intègrent sur les sites des marques (Facebook avec son « Like », Twitter et et « Tweet this »…).

Que peut-on faire pour intégrer les réseaux sociaux dans son site ?

La première fonctionnalité concerne le partage d’information qui permet de remonter des données de son site sur un réseau  social.

L’intégration de Facebook est simple grâce aux plugins mis à disposition sur le site dédié aux développeurs et un simple script JS plus une balise HTML permettent de le mettre en œuvre.

Pour intégrer le protocole OpenGraph de Facebook, il suffit d’ajouter des balise META dans ses pages et pour intégrer des statistiques d’utilisation (Facebook Insights) c’est la même chose (balises META).

Pour Twitter, l’intégration se passe comme pour Facebook avec un fichier JS et une balise HTML à intégrer dans ses pages.

Des solutions plus globales telles que AddThis.com permettent d’intégrer plusieurs réseaux sociaux en une seule opération.

1ère démo pour montrer comment, sur un site présentant un catalogue de produits, l’intégration de Twitter et Facebook a été mise en œuvre.

On voit que les boutons « Tweet this » et « Like » ont été intégrés et que les systèmes d’authentification sont gérés automatiquement.

L’intégration a été faite ici par le développement d’une WebPart mais cela pourrait être fait plus simplement avec une Content Editor WebPart. La WebPart développée ici propose dans le menu de paramétrage de la WebPart, des options spécifiques accessibles aux webmasters pour influer sur le comportement du bouton Facebook.

L’intégration de Twitter a été fait de la même manière avec une WebPart développée spécifiquement pour l’occasion et qui contient des paramètres pour influer sur le comportement du bouton « Tweet this ».

Si on veut que les boutons soient disponibles en permanence, il suffit de les inclure dans la MasterPage ce qui a été fait ici et on nous montre avec SharePoint Designer, où se trouve le code correspondant au composant en question (également développé pour l’occasion).

Petit passage dans Visual Studio pour regarder le code de la WebPart Facebook et notamment le fait que si la page est en mode Edit ou en mode Display, elle n’affiche pas la même chose.

Retour dans SharePoint Designer pour voir les balises META qui ont été ajoutées dans le header de la page pour intégrer le protocole SocialGraph. On voit notamment comment récupérer le titre de la page (via les contrôles standard de SharePoint) pour les insérer comme valeur de la balise META adéquate.

Retour aux slides pour parler de l’intégration d’outils conversationnels (en temps réel parfois) pour permettre aux internautes de discuter sur le contenu du site visité. Ces outils apportent une forte valeur ajoutée au site et apportent une certaine crédibilité aux sites qui les utilisent.

2ème démo sur l’intégration d’outils conversationnels au sein d’un site. Une nouvelle fois, une WebPart spécifique a été développée pour laisser des commentaires sur une page, commentaires connectés à Facebook. Cette WebPart est insérée dans la page et on voit que les internautes peuvent générer des fils de discussion sur la page actuellement visitée.

Même chose avec la WebPart qui affiche les messages postés en temps réel sur le channel Twitter dédié à la SharePoint Conference #SPC11.

Retour aux slides pour évoquer le stockage de contenus sur les réseaux sociaux comme par exemple sur YouTube.

Cela permet d’augmenter la visibilité et la réutilisation, permet aux internautes de suivre l’activité de l’entreprise sans visiter le site, etc…

L’exemple de Twitter est pris pour expliquer comment fonctionne les API REST qui permettent d’envoyer du contenu sur la plateforme.

Nouvelle démo pour montrer un composant qui a été développé pour envoyer du contenu dans Twitter. On commence par aller enregistrer son application sur Twitter via le formulaire dédié à cet effet. C’est la 1ère étape obligatoire pour pouvoir envoyer ou lire du contenu via les API et qui donne en échange du formulaire, des clés de cryptage à utiliser dans son application pour communiquer avec les serveurs de Twitter.

Plutôt que d’enregistrer les clés de cryptage dans son code ou dans le web.config, on utilise le « Secure Store Service » de SharePoint afin de stocker des données sous la forme clé/valeur.

Un autre exemple d’application des API qui est montré est de publier sur Twitter via un workflow personnalisé (qui utilise donc les API), aussitôt qu’une page est approuvée dans le site.

Une tâche de workflow a été développée pour l’occasion, rendue disponible dans SharePoint Designer et l’on voit comment utiliser cette action au sein de l’assistant de workflow de SharePoint Designer.

La session se termine en passant en revue le code du composant permettant de récupérer les données depuis le « Secure Store » et l’activité de workflow.

Pour rendre disponible l’activité de workfow dans SharePoint Designer, il faut créer un fichier XML portant l’extensions .actions dans lequel sont référencés différentes choses comme l’assembly hébergeant le code ou le titre des options qui seront ajoutées dans le ruban de SharePoint Designer.

What’s new in SQL Server « Denali », Analysis Services & PowerPivot

Session animée par T.K Anand (Principal Group Program Manager)

Analysis Services dans Denali est une évolution du produit qui reprend les forces qui ont fait son succès jusqu’ici.

SSAS embrasse aussi bien les modèles relationnels que multidimensionnels pour avoir une plateforme BI unifiée.

Un des pans importants de la BI sur Denali sera le « BI Semantic Model (BISM) » qui permet de partager un même modèle (accès aux données, structures…) pour tous les utilisateurs (individus, équipes et IT).

1ère démo pour montrer la conception d’un modèle sous Visual Studio 2010.

Une fois le modèle publié sur un serveur SSAS, il est possible depuis SharePoint de créer un nouveau classeur Excel avec PowerPivot pour analyser les données.

On voit qu’on peut aussi lancer « Crescent » et que le modèle de données est identique à celui accessible depuis PowerPivot.

Retour aux slides pour en dire plus sur BISM et aborder la migration des applications existantes sur Denali.

Tous les UDM des anciennes versions de SQL Server deviendront des BISM. Pour les nouvelles applications, l’utilisateur créera directement un BISM.

Les BISM pourront être exploités par Crescent, Excel, PowerPivot, SharePoint (PerformancePoint, Excel Services…) et des applications tierces (une API est à disposition pour attaquer le référentiel).

Les sources de données peuvent être des bases relationnelles, de applications LOB, des fichiers, des services Odata ou des services hébergés dans le Cloud.

2ème démo pour faire un tour plus détaillé de PowerPivot.

Suite aux retours des utilisateurs de la version actuelle, de nouvelles fonctionnalités ont été ajoutées dans Excel pour simplifier la vie des utilisateurs.

On voit notamment un zone affichant les résultats importants du classeur (nommée « Calculation Area ») et un nouvel assistant graphique pour définir des KPI (définir les seuils d’objectifs, de réalisation…).

Il est désormais possible de voir, à la mode diagramme de base de données dans SQL Server, les relations entre toutes les sources du classeur Excel.

Dans SQL Server Management Studio, on peut restaurer un BISM depuis un classeur PowerPivot et dans Visual Studio, on peut créer un BISM également depuis un classeur PowerPivot.

Depuis Visual Studio, on retrouve tout un tas d’assistant permettant de gérer son modèle (création de partitions, gestion de la sécurité…).

Sur la gestion de la sécurité, il est possible de créer des rôles et de restreindre l’accès aux données via des expressions DAX (ex: rôle Sales Europe ne peut accéder qu’aux données dans la colonne Zone = ‘Europe’).

Dans Management Studio, on peut définir sur les propriétés de son modèle, un mode de requêtage sur les modèles pour déterminer sur les données sont mises en cache ou interrogées à chaque fois (DirectQuery).

Denali intègre désormais une console Powershell permettant de réaliser toutes les tâches d’administration possibles.

Retour aux slides pour voir les 3 piliers sur lesquels a été conçu BISM à savoir flexibilité, richesse et évolutivité (montée en charge).

Pour construire un BISM, il existe pour le moment uniquement 2 types de projets dans Visual Studio mais cela peut changer si des clients demandent d’autres choses comme la possibilité de récupérer les anciens modèles de SSAS 2008.

Les 2 modèles dans Visual Studio permettent de créer des projets en mode tabulaire ou multidimensionnel.

DAX et MDX peuvent être utilisés pour implémenter la logique métier au sein des BISM.

Vetipaq et DirectQuery sont utilisés pour l’accès aux données et MOLAP et ROLAP sont utilisés pour stocker les données.

Quelqu’un dans la salle demande s’il est possible de créer un modèle programmatiquement et la réponse est non, il n’existe pas d’API pour créer un modèle.

La session touche à sa fin avec un slide présentant la liste des fonctionnalités qui seront offertes dans la version RTM de Denali. La liste étant tellement grande que je vous invite à vous retourner vers le fichier PPT de la session pour avoir la liste complète   😉

Application lifecycle management : automated builds and testing for SharePoint projects

Session animée par Chris O’Brien & Mike Morton

Dans cette session, nous allons voir comment automatiser les builds de solutions et mettre en place des tests unitaires sous SharePoint.

Les challenges des gros projets: il y a beaucoup de dépendances entre les projets (code, features, timer jobs, …). Les déploiements restent assez complexes (il y n’y a pas de rollback de sur les wsp nativement), et les tests unitaires dans le monde de SharePoint ne sont pas très courants.

Les problèmes inhérents aux projets conséquents : le tracking (difficile de garder une trace des deploiements/correctifs, les développeurs sont nombreux), la difficulté de garder un environnement à jour par rapport à celui des autres développeurs, les builds inconsistants…

On nous présente maintenant la recette magique pour parer à ces difficultés.

D’abord, il faut automatiser la compilation des assemblies et des wsp.

Il faut utiliser un contrôleur de sources (TFS par exemple) et prendre l’habitude des commenter les check-in pour faciliter les retours arrières.

Il faut aussi penser à incrémenter automatiquement le numéro de version des assemblies, c’est plus facile pour le tracking des déploiements/des correctifs.

Les wsp doivent être déployés sur des machines de tests, pas sur les machines des développeurs.

Il faut faire des tests unitaires afin d’empêcher le build en cas d’échec d’un test unitaire.

Quelques ingrédients : TFS Team Build Workflow pour définir l’ordonnancement des étapes, Powershell pour déploiement des wsp, Remote Powershell pour exécuter des actions sur des serveurs distants (commande « Invoke-Command »).

On doit se poser la question : quand déclencher les builds ? Manuellement, schedulé, à chaque check in…

Le Workflow des étapes du build doit être cutomisé.

On passe maintenant à une démo.

Tout ce que nous allons voir ici nécessite l’édition Team Build de Team Foundation Server.

On ouvre Visual Studio (qui est planté au passage J), on crée une Build definition dans laquelle on définit  les triggers (manuel, schedulé, …) pour savoir quand builder, on définit les chemins d’accès aux ressources, on définit ensuite le contrôleur de build utilisé. ..

Replantage mais le coupable est IE cette fois ci. On kill le process !

On définit maintenant le dossier de sortie, la solution utilisée, s’il s’agit d’un build debug ou release (meilleur pour les performances sur un environnement de production), les arguments à envoyer à notre build (ici packaging=true) pour builder le wsp en plus des assemblies.

Maintenant, on sélectionne un template de  build/workflow ( fichier xaml). Un certain nombre de templates sont déjà présents dans TFS. Un designer de workflow permet de définir les étapes (exécution de code par exemple). Très intuitif tout ça J

Un agent est visible dans la barre des tâches pour consulter rapidement l’état des builds.

On lance le build et visualise les logs des builds directement depuis Visual Studio.

Après cette démo, nous passons aux tests unitaires.

Les tests unitaires peuvent être assez poussés : générer des bouts de code (pour envoyer des données), générer des cliques pour ajouter une webpart à une page, …

Retour à une démo…

Ce que nous allons voir nécessite la version Ultimate ou Premium de Visual Studio.

On crée un « Test project » dans VS. Les possibilités sont nombreuses : un test qui exécute du code, un autre enregistre nos  actions (par exemple un clique sur un bouton du ribbon.

Il est même possible de sélectionner des éléments html dans la page et d’indiquer la valeur qu’ils doivent avoir après le clique: par exemple, le message de succès qui doit apparaitre sous le ribbon.

On lance le test, VS clique tout seul, le message apparait… succès!

Nous avons ensuite droit à quelques exemples de codes Powershell qui font des appels distants, des builds de wsp…

On passe en revue toutes les possibilités des tests unitaires. Si un test échoue, on peut par exemple avoir un screenshot du navigateur au moment de l’échec ou même une vidéo, …

Il est possible de faire quasiment ce que l’on veut: exécuter SPDisposeCheck sur la solution ou tout autre utilitaire.

Les tests unitaires peuvent être exécutés avec MSTest.exe.

Les best practices :

  • Mettre en place ce process dès le début du projet (trop compliqué et couteux à mettre en place après coup)
  • Faire des builds automatiques le plus souvent possible pour avoir un feedback rapide

Pour conclure, les builds automatiques et les tests unitaires représentent un réel intérêt pour que la réalisation du projet se passe sans encombre, même si leur mise en place augmente sensiblement la durée des développements.