Archives de catégorie : SharePoint Server

Utiliser les Patterns and Practices et le modèle des Apps pour déployer vos sites dans SharePoint Online ou on-premise

Introduction

Créer efficacement des sites personnalisées pour répondre aux besoins de nos clients c’est une des raisons de l’existence de SharePoint. Microsoft se concentre de plus en plus vers des déploiements dans le cloud, alors nous aurons inévitablement besoin d’avoir un modèle de déploiement qui est viable et facilement réalisable à la fois sur O365 et on-premise.

Dans cette optique, je me suis penché sérieusement sur la question afin de mieux comprendre les différentes techniques de déploiement de sites ainsi que leurs avantages et inconvénients.

Le déploiement de sites personnalisés dans SharePoint a évolué au cours des dernières versions et avec l’arrivé du modèle des Apps, il est évident qu’une façon de faire uniformisé s’impose. Une des techniques consiste à utiliser le modèle de Apps pour déployer vos sites.

Différentes techniques de déploiement de sites personnalisés

Avant d’entrer dans le vif du sujet, voyons un bref résumé des techniques qui s’offrent à nous pour effectuer le déploiement :

  • Modèles Web (Web Templates)
    • Seulement disponible au niveau de la collection de site dans O365
    • Difficile à maintenir à jour
  • Définitions de site (Site Definitions)
    • Non supporté dans O365
    • Beaucoup d’impact lors des mises à jours
  • Solutions de ferme personnalisées
    • Non supporté dans O365
    • Complexe à mettre en place et à maintenir
  • Création de structure de site avec Powershell
    • Complexe à mettre en place et à maintenir
  • Agrafage de fonctionnalités (Feature stappling)
    • Seulement disponible au niveau de la collection de site dans O365

Changement d’orientation de la part de Microsoft

Les modèles web (Web Templates) ont été, jusqu’à dernièrement, un excellent mécanisme fournis par Microsoft pour créer des centaines de sites d’équipes avec leurs propres personnalisations (bibliothèques, vues, WebPart, etc…) en addition à un modèle de site « out of the box ».

Cependant, lors d’une conférence au TechEd Europe 2014 (30 Octobre) Microsoft a annoncé ceci :

  • Éviter d’utiliser des définitions de site et des modèles Web
  • Éviter les pages maîtres personnalisées
  • Éviter d’utiliser le code XML déclaratif

siteProvisioning_NoSiteDef

Lien vers le vidéo

La raison derrière ce changement est, à mon avis, que Microsoft tente de faire d’Office 365 une plate-forme de développement qui n’est pas onéreuse à faire fonctionner et en même temps de fournir un service qui n’est pas trop complexe.

Maintenant, si on utilise des modèles Web nous ne bénéficieront pas des derniers changements pour chaque mise à jour de Microsoft. On parle ici d’une « taxe de personnalisation » que vous devez payer si vous utilisez des modèles Web.

Réaction face à ce changement d’orientation

J’évite volontairement de vous parler de l’orientation qui consiste à éviter les pages maître personnalisés et le code XML déclaratif car je ne suis pas complètement en accord avec ce changement. Je partage l’opinion de Chris O’Brien, il y aura toujours place à la personnalisation dans un site Intranet et le code XML déclaratif est encore supporté à 100% dans O365!

Tout comme nous n’avons pas immédiatement abandonné les solutions de fermes lors de l’arrivé du modèle des Apps, les modèles Web continueront sans doute d’être utilisé pour plusieurs scénarios pour où vous ne voudriez PAS de ces derniers changements provenant des mises à jour de Microsoft.

Cependant, je considère que pour les site d’équipe ainsi que pour les sites de projets, il n’est plus favorable d’utiliser un modèle Web et il serait plus approprié d’utiliser le modèle des Apps pour déployer vos sites afin d’éviter cette taxe de personnalisation!

Le modèle des Apps pour déployer vos sites

Le diagramme suivant illustre le déploiement de collections de site en utilisant le modèle des Apps ainsi qu’une approche asynchrone :

 

siteProvisioning_Remote

  1. Lorsqu’un utilisateur a besoin d’une nouvelle collection de site, il remplis les métadonnées requises dans le formulaire de création
  2. L’information est stockée dans un endroit centralisé
  3. Si requis, on peut y associer des flux d’approbation
  4. Les requêtes approuvées sont traitées par une tâche planifié distante. Ex : Une tâche planifié hébergé dans un serveur applicatif qui lance un script PowerShell ou une application console
  5. Le déploiement du site est réalisé en fonction des métadonnées fournis en utilisant le CSOM
  6. Une notification est envoyé à l’utilisateur pour lui informer de la création de la collection de site.

Le principe de cette technique consiste à sortir le code permettant d’effectuer le déploiement à l’extérieur de SharePoint afin d’avoir un faible couplage avec la plateforme. Cette technique fonctionne dans O365 ainsi qu’on-premise. Un des avantages est qu’il n’est pas nécessaire de déployer de fonctionnalités dans la ferme pour effectuer le déploiement. En plus de cela, il n’y a plus de dépendances avec des packages de solutions à l’intérieur des bases de données de contenu alors on pourrait uniquement restaurer celles-ci en cas de disaster recovery.

Fonctionnement technique

  1. Aller sur le site GitHub de OfficeDevPnp à l’adresse https://github.com/OfficeDev/PnP
  2. Cliquer sur le bouton « Download zip » et choisir un emplacement
  3. Extraire le Zip et aller dans le répertoire PnP-master\PnP-master\Samples\Provisioning.OnPrem.Async
  4. Ouvrir Provisioning.OnPrem.Async.Console.sln avec Visual Studio
  5. Vous retrouverez la méthode principale ProcessSiteCreationRequest
[...]

private static string ProcessSiteCreationRequest(ClientContext ctx, ListItem listItem)
{

 //get the base tenant admin urls
 string tenantStr = ConfigurationManager.AppSettings["SiteCollectionRequests_SiteUrl"];

 // Resolve root site collection URL from host web. We assume that this has been set as the "TenantAdminSite"
 string rootSiteUrl = tenantStr.Substring(0, 8 + tenantStr.Substring(8).IndexOf("/"));

 //Resolve URL for the new site collection
 var webUrl = string.Format("{0}/sites/{1}", rootSiteUrl, listItem["SiteUrl"].ToString());
 var tenantAdminUri = new Uri(rootSiteUrl);
 string realm = TokenHelper.GetRealmFromTargetUrl(tenantAdminUri);
 var token = TokenHelper.GetAppOnlyAccessToken(TokenHelper.SharePointPrincipal, tenantAdminUri.Authority, realm).AccessToken;
 using (var adminContext = TokenHelper.GetClientContextWithAccessToken(tenantAdminUri.ToString(), token))
 {
 // Set the time out as high as possible
 adminContext.RequestTimeout = int.MaxValue;

 var tenant = new Tenant(adminContext);
 var properties = new SiteCreationProperties()
 {
 Url = webUrl,
 Owner = listItem["AdminAccount"].ToString(),
 Title = listItem["Title"].ToString(),
 Template = listItem["Template"].ToString(),
 };

 //start the SPO operation to create the site
 SpoOperation op = tenant.CreateSite(properties);
 adminContext.Load(op, i => i.IsComplete);
 adminContext.RequestTimeout = int.MaxValue;
 adminContext.ExecuteQuery();
 }

 // Do some branding for the new site
 SetThemeToNewSite(webUrl);

 return webUrl;
}

[...]

Afin d’uniformiser la manière de faire entre O365 et on-premise, vous remarquerez qu’on utilise la même notion de « Tenant« .

Une fois le code déployé, vous aurez un interface comme celui-ci pour saisir l’information concernant la collection de site à créer :

siteProvisioning_UI

Cette information sera ensuite sauvegardée dans une liste :

siteProvisioning_List

Finalement, l’application console que vous aurez lancé manuellement ou via une tâche planifié se chargera de créer la collection de site à partir de cette liste.

Pour plus d’information consulter ce vidéo qui présente en détail le fonctionnement du code et du processus.

Office Development Patterns & Practices (PnP)

En plus de fournir le code pour déployer des sites, le site d’Office PnP présente une série d’exemples et de scénarios sur les bonnes pratiques qui utilise le modèle des Apps.

Les exemples et scénarios utilisent les méthodes qui sont recommandées par l’équipe Office 365 et la majorité s’applique à :

  • Office 365 Multi Tenant (MT)
  • Office 365 Dedicated (D)
  • SharePoint 2013 on-premises

Voici quelque références pour les différents sites relié à Office PnP :

Conclusion

Le modèle des Apps pour déployer vos sites peut être la bonne solution dans une situation et peut ne pas l’être dans une autre. Le plus important est d’avoir une bonne compréhension des diverses techniques pour ensuite prendre une décision éclairé selon vos besoins. Le choix de votre technique de déploiement de site aura un impacte à long terme sur vos coûts de mise en place et de maintenance. J’aime bien la technique asynchrone proposé par Office PnP car il est possible de l’utiliser dans O365 ainsi que on-premise et de plus, l’utilisateur n’a pas besoin d’attendre dans son navigateur car il reçoit une notification à la fin du traitement.

Qu’est-ce que vous pensez de cette technique de déploiement de sites ?

Références

Building a async provisioning model par Office PnP

Office365 Developer Patterns and Practices par Vesa Juvonen

Provisioning site collections using SP App model in on-premises with just CSOM par Vesa Juvonen

Site provisioning techniques with SharePoint apps par Bert Jansen et Vesa Juvonen

Transforming Your SharePoint Full Trust Code to the SharePoint App Model  par Vesa Juvonen et Steve Walker

Developing for Office 365 – thoughts on use of custom master pages and web templates par Vesa Juvonen

Site provisioning techniques and remote provisioning in SharePoint 2013 par Chris O’Brien

L’effort de Microsoft au sujet de l’extensibilité d’Office 365 par Sébastien Levert

Problème de redirection lors de l’enregistrement d’une page Wiki dans SharePoint 2013 Foundation

Introduction

Tout juste avant les vacances, un de mes collègues Achraf Loudiy m’a demandé assistance avec un problème lorsqu’il ajoutait des pages Wiki contenant des caractères accentués dans le URL de la page. Puisqu’on a passé un nombre considérable d’heures sur cette problématique, j’ai décidé d’en faire une SharePointerie.

Détail de la problématique

Dans SharePoint Foundation 2013, suite à l’enregistrement d’une page Wiki dans la bibliothèque «Pages de site» , une redirection est effectué vers une page qui n’existe pas.

Pour reproduire le problème :

  1. Créer une page Wiki contenant au moins un caractère accentué (Ex : PageAccentué).
  2. Sauvegarder la page.
  3. Naviguer vers Contenu du site -> Bibliothèque « Pages de site ».
  4. Accéder à la page Wiki en mode « Édition ».
  5. Sauvegarder la page. (Vous serez alors redirigé vers une page inexistante).

Début des investigations

Lorsqu’on m’a énoncé cette problématique, j’ai immédiatement fais le test sur mon environnement O365 ainsi que sur ma VM SharePoint 2013 On-Premise. Cependant je n’ai pas réussi à reproduire le problème.

J’ai donc recommandé à mon collègue de procéder à l’installation du Service Pack 1 ainsi que des derniers CU dans son environnement SharePoint 2013 Foundation. Malheureusement, toujours le même problème suite à l’installation des mise à jours et Google ne nous est pas d’une grande utilité peu importe les mots-clés utilisés.

C’est là qu’on a commencé à déboguer avec Fiddler. Plus en détail voici le détail des traces :

fiddler_MDS

(200 – OK) http://sp2013/sites/sharepointerie/SitePages/PageAccentu%C3%A9.aspx

(200 – OK) http://sp2013/sites/sharepointerie/_layouts/15/start.aspx

(404 – Page Not found) http://sp2013/sites/sharepointerie/_layouts/15/start.aspx#/SitePages/PageAccentu%C3%83%C2%A9.aspx

Il y a clairement un changement au niveau de l’encodage du URL une fois que la page est redirigé par /_layouts/15/start.aspx.

Avant : PageAccentu%C3%A9.aspx

Après : PageAccentu%C3%83%C2%A9.aspx

Jusqu’à maintenant on sait que :

  • Lorsqu’on passe par la bibliothèque via le menu de gauche pour accéder à la page, une section « /_layouts/starts.aspx » est ajouté au URL.
  • Lorsqu’on accède directement à la page sans passer par le menu de gauche, la page s’ouvre correctement.

On a alors un « workaround » mais malgré tout, j’ai continué d’investiguer pour trouver une meilleure solution.

Cette fois-ci Google a été mon ami après avoir recherché « /_Layouts/15/Start.aspx redirect problem » je suis tombé sur cette page qui parle de la fonctionnalité Minimal download strategy (MDS).

MDS_Enabled

Cette fameuse fonctionnalité de site m’avait déjà causé des problèmes alors on a décidé de la désactiver pour voir si ça corrigerait le problème (Paramètres de site – Fonctionnalités de site).

MDS_Disabled

Une fois désactivé, voici le résultat des traces dans Fiddler :

fiddler_MDS_Disabled

(200 – OK) http://sp2013/sites/sharepointerie/SitePages/PageAccentu%C3%A9.aspx

Lors de la sauvegarde de la page, le URL ne comprend plus la section « /_layouts/starts.aspx » et on est maintenant redirigé vers la bonne page.

Fonctionnalité Minimal Download Strategy (MDS)

Minimal Download Strategy (MDS) est une nouvelle technologie dans SharePoint 2013 qui réduit la quantité de données ayant le navigateur pour télécharger lorsque les utilisateurs naviguer d’une page à une autre dans un site SharePoint. Lorsque les utilisateurs accèdent à un site prenant en charge MDS, le client traite uniquement les différences (ou delta) entre la page actuelle et à la page demandée.

MDS utilise un fichier .aspx (start.aspx) pour vos page, avec le URL courant encodé dans le texte suivi du hashmark (‘#’).

Donc en gros, cette fonctionnalité a pour but d’optimiser l’expérience de l’utilisateur en gagnant du temps de traitement.

Cependant, comme on a pu le voir dans les traces de Fiddler, le URL encodé final est différent lorsque la fonctionnalité MDS est activé.

Solution

On a donc créé un modèle de site avec la fonctionnalité MDS désactivé par défaut afin de ne plus avoir cette fâcheuse redirection.

Je n’ai pas réussi à trouver pourquoi l’encodage des URL est différent lorsque cette fonctionnalité est activé.

Sans MDS: PageAccentu%C3%A9.aspx (PageAccentué.aspx)

Avec MDS : PageAccentu%C3%83%C2%A9.aspx (PageAccentué.aspx)

Vous avez des idées ?

Conclusion

Je l’ai dit souvent et je vais probablement le dire encore, SharePoint c’est avant tout une application Web alors il ne faut pas hésiter à la déboguer avec des outils de développement Web (Fiddler, IE Toolbar, etc…). Bien que la fonctionnalité MDS a pour but d’améliorer les performances, dans le cas suivant, je crois que la meilleure alternative est de la désactiver.

Références

Minimal Download Strategy (MDS)

Redirection avec le MDS

À quoi sert /_layouts/starts.aspx dans SharePoint 2013