Dans une infrastructure du type « authoring – publishing », il arrive souvent qu’on ait recours au « Quick Deploy ». Pour ceux qui ne connaissent pas, le « Quick Deploy » permet de demander explicitement le déploiement d’une page de l’environnement « authoring » vers l’environnement « publishing ».

Dans ce cours, nous n’allons pas entrer dans les détails du « Quick Deploy » mais plutôt aborder un petit problème pouvant survenir lorsque l’on fait des « backup/restore » d’une base de données. Typiquement, la situation peut se présenter comme ceci :

Vous possédez 3 environnements : « Test », « Acceptance » et « Production » (architecture plutôt conventionnelle). Pour exécuter vos tests, vous faites un « backup » de la base de données de production et la restaurez sur chacun des environnements, ainsi vous disposez des dernières données et le test de vos solutions sont plus solides de cette manière. Selon moi, ceci est une bonne technique, mais elle va engendrer un problème dans le « Quick Deploy ». En effet, celui-ci ne fonctionnera plus. Nous allons maintenant voir la raison de ce disfonctionnement pour ensuite passer à sa résolution. Vous pouvez directement passer à la partie résolution si le « pourquoi du comment » ne vous intéresse pas.

Explication du problème

Pour bien comprendre le problème, il faut d’abord bien comprendre comment le « Quick Deploy » fonctionne. Pour cela, nous allons partir du point que vous possédez déjà un environnement avec un site pour lequel les « features » de publication sont activées. Ce site est lié à un « Quick Deploy » qui se chargera de déployer vos pages quand vous le désirez vers votre environnement de publication.

Lorsque vous activez les fonctionnalités de publication sur votre environnement « authoring », une liste cachée va être créée. Celle-ci sera accessible à l’url : http://votre-site/Quick%20Deploy%20Items. Cette liste va contenir une référence à chaque page de votre site pour lesquelles vous aurez demandé un déploiement rapide. Elle est principalement composée d’une colonne « JobId » qui va en fait contenir l’identifiant unique du « job » défini dans la centrale d’administration et d’une colonne « ItemUrl » qui va contenir l’url de l’élément à déployer.

L’exécution du job de déploiement rapide va être décomposée en plusieurs étapes :

- Le job va récupérer une référence au site auquel il est lié grâce à son « Path ».
- Il va ensuite regarder dans la liste « Quick Deploy Items » s’il existe des éléments pour lesquels le champ « JobId » contient le même « ID » que le job lui-même.
- S’il existe des items correspondant au critère cité ci-dessus, le job va les traiter et les supprimer de la liste.

Jusqu’à présent, il n’y a aucun risque de désynchronisation avec la base de données après restauration. Le problème se situe plutôt lors du clic sur le bouton « Quick Deploy » du « Ribbon ». Ce bouton va permettre de créer les éléments dans la liste « Quick Deploy Items » qui devront être utilisés par le job. Pour bien comprendre le problème, utilisons « Reflector » pour voir le code exécuté lorsque nous cliquons sur le bouton en question. Pour cela, il existe la classe « Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJob » contenant la méthode « AddQuickDeployObject ». La partie la plus importante de cette méthode étant la suivante :

Collection<Guid> enabledQuickDeployJobsForSite = GetEnabledQuickDeployJobsForSite(rootWeb.Site); SPList quickDeployItemsList = QuickDeploy.GetQuickDeployItemsList(rootWeb); foreach (Guid guid in enabledQuickDeployJobsForSite) { SPListItem item = quickDeployItemsList.AddItem(); item["Title"] = guid.ToString(); item["JobId"] = guid.ToString(); item["ItemType"] = (int) itemType; item["ItemUrl"] = itemUrl; item.Update(); }
SharePoint va donc récupérer une liste de « GUID » correspondant aux jobs liés à ce site et ensuite créer des éléments pour chacun d’eux. Autrement dit, il créera autant d’élément que de job pour la page à déployer. Regardons maintenant la fonction « GetEnabledQuickDeployJobsForSite » qui est appellée pour récupérer la référence aux « Quick Deploy Job » liés au site actuel. La partie la plus importante de cette fonction est :

CacheManager manager = CacheManager.GetManager(site); if (manager.RootWebItemCache.ContainsKey("QuickDeployJobsKey")) { str = manager.RootWebItemCache["QuickDeployJobsKey"] as string; } else { str = site.RootWeb.Properties["QuickDeployJobs"]; manager.RootWebItemCache["QuickDeployJobsKey"] = str; }
En gros, ce bout de code va simplement permettre de récupérer la liste des « ID » de tous les jobs liés au site actuel. Comme vous pouvez le constater, un système de cache est utilisé, mais ce n’est pas le plus important ici. En effet, ce qui est importe c’est de voir que cette liste d’ID est en fait simplement contenue dans la propriété « QuickDeployJobs » du site racine de la « site collection ». En effet, lorsque vous créez un « path » dans votre centrale d’administration et que le site auquel le « path » est lié est de type publishing, un « Quick Deploy Job » est automatiquement crée mais désactivé. Lorsque vous allez activer ce job, celui-ci va faire la liste des « jobs » liés au site (s’incluant dans cette liste) et va la sauver dans la propriété « QuickDeployJobs » du site racine de la collection de site. Cela permet de ne pas toujours devoir refaire une requête vers les jobs existants pour voir lesquels sont liés au site contenant la page à déployer.

C’est une bonne technique, mais c’est là que le problème intervient. En effet, en production, des « Quick deploy jobs » ont été créés avec un certain « ID » et ces « ID » ont été sauvés dans la propriété du site racine. Lorsque vous aller faire un « backup » de votre base de données pour ensuite la restaurer sur votre environnement de « test », cette propriété va également être restaurée. Cependant, les jobs existants en « test » n’auront pas le même « ID » que ceux contenus dans la propriété du site. En effet, la base de données d’administration, n’a pas été restaurée elle, donc la propriété web contient une référence à des jobs qui n’existent pas sur cet environnement. Résultat : lorsque les jobs liés à votre site de test vont s’exécuter, ils ne trouveront aucun également dans la liste « Quick Deploy Items » correspondant à eux-mêmes, donc, rien ne sera déployé.

Maintenant que nous avons identifié le problème, nous allons pouvoir le solutionner plus facilement.

Résolution

Le code suivant peut être utilisé pour solutionner ce problème.

const string prefix = "<?xml version=\"1.0\" encoding=\"utf-16\"?><ArrayOfGuid xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\">"; using (SPSite site = new SPSite("http://pc-media")) { var qdJobs = ContentDeploymentJob.GetAllQuickDeployJobs().Where( qd => qd.IsQuickDeployJob && qd.IsEnabled && qd.Path.SourceSiteCollection == site.ServerRelativeUrl ); string newValue = qdJobs.Aggregate( new StringBuilder(prefix), (val, qdJob) => val.AppendFormat("<guid>{0}</guid>", qdJob.Id.ToString("D")), val => val.Append("</ArrayOfGuid>").ToString() ); bool allowUnsafeUpdates = site.RootWeb.AllowUnsafeUpdates; site.RootWeb.AllowUnsafeUpdates = true; site.RootWeb.Properties["QuickDeployJobs"] = newValue; site.RootWeb.Properties.Update(); site.RootWeb.AllowUnsafeUpdates = allowUnsafeUpdates; }
La valeur de cette propriété est en fait du XML. Nous commençons donc par déclarer une variable « prefix » qui va contenir la déclaration de XML. Ensuite, nous allons récupérer tous les « jobs » de déploiement liés à ce site en ne gardant que les « Quick deploy » activés. Nous utilisons ensuite la méthode « Aggregate » pour constituer la valeur de la propriété. Ce n’est qu’un ensemble d’élément « guid » contenant les « ID » des jobs liés à ce site. Une fois que nous avons cette valeur, nous la plaçons dans la propriété « QuickDeployJobs » du site racine. Ainsi, les références sont rétablies et lorsque vous demandez le déploiement d’une page, les bons « ID » sont utilisés.

Télécharger