Concepts clés de la migration sélective

Dernière modification : samedi 1 mai 2010

S’applique à : SharePoint Foundation 2010

Dans cet article
Sélection de contenu pour l'exportation
Package de migration de contenu (.cmp)
Identité des objets
Reparentage
Gestion des types de contenu
Gestion des flux de travail

Cette rubrique d'aide décrit plusieurs concepts clés qui sont importants dans la migration sélective.

Sélection de contenu pour l'exportation

Une fois que la première migration complète a eu lieu et que les sites source et de destination sont établis, la migration sélective s'appuie sur la logique de votre code personnalisé pour les critères de sélection qui déterminent quels éléments sont sélectionnés pour la migration et quand. Également appelée « sélection aléatoire », il s'agit du processus par le biais duquel des éléments spécifiques de la collection de sites source sont migrés vers la collection de sites de destination selon des critères de sélection qui sont spécifiés dans le code personnalisé.

Dans le scénario de base, la logique d'un module de code associé à un travail du minuteur s'exécute selon une planification périodique (par exemple, toutes les 24 heures à 3 h 00) ; le module examine les cachets de date ou les journaux des modifications (ou les deux), puis sélectionne et exporte uniquement les fichiers qui ont été modifiés depuis la dernière migration.

L'opération s'appuie sur l'identité des objets dans les collections du site source et du site de destination. Au moment de l'importation, la destination reconnaît les objets par leurs identificateurs GUID, puis met à jour leurs fichiers correspondants en conséquence.

Package de migration de contenu (.cmp)

Le package de migration de contenu est un fichier compressé cabinet (.cab) qui utilise l'extension de fichier .cmp. Le fichier package de migration (.cmp) regroupe les données pour l'exportation à partir du site source, avec les données de structure du site et de dépendance, et les stocke sous forme de fichiers XML compressés et sérialisés.

Pendant que l'opération d'exportation compresse les données de site par défaut, vous pouvez substituer ce comportement et exporter des fichiers non compressés en remplaçant la propriété FileCompression par false. Cette propriété appartient à l'objet SPDeploymentSettings.

Lorsque vous utilisez la compression de fichiers, vous devez spécifier le nom du fichier de migration du contenu compressé (.cmp) à l'aide la propriété BaseFileName sur l'objet SPExportSettings. La propriété FileLocation spécifie l'emplacement du fichier compressé sur le serveur source.

Par défaut, les fichiers .cmp sont limités à 24 Mo, bien que vous puissiez modifier cela à l'aide de la propriété FileMaxSize. Lorsque des données de site dépassent la limite de 24 Mo, elles sont séparées en deux ou plusieurs fichiers de migration. Cependant, quand un seul fichier dépasse la taille de fichier maximale, l'opération redimensionne le fichier .cmp pour prendre en charge cette taille. Vous pouvez avoir n'importe quel nombre de fichiers .cmp.

Identité des objets

Les objets SharePoint sont identifiés par leur GUID sur le serveur source. À l'importation, par défaut, les objets sont affectés d'un nouveau GUID au moment de l'importation vers la destination. Pour prendre en charge les scénarios de migration sélective, cependant, vous devez modifier la valeur par défaut et conserver l'identité de l'objet que vous exportez. Cela est très important, car le seul moyen pour que les fichiers mettent correctement à jour leurs versions correspondantes sur le site de destination est que la destination reconnaisse l'objet par son GUID d'identification.

Vous pouvez conserver l'identité de l'objet en affectant à la propriété RetainObjectIdentity de l'objet SPImportSettings la valeur true.

La conservation de l'identité des objets doit être utilisée avec soin et dans des scénarios limités. Elle prend généralement en charge un scénario de publication dans lequel la source et un ou plusieurs serveurs de destination sont des images miroir ; par exemple, quand un serveur de développement ou de test migre des mises à jour vers un ou plusieurs serveurs de production.

Si vous créez un nouveau site dont vous savez à l'avance qu'il recevra des mises à jour de fichiers de façon régulière (par exemple, en provenance d'un serveur de développement ou de test), vous pouvez activer un lien entre les deux en effectuant d'abord une migration complète de la source vers un site complètement vierge, mais avec RetainObjectIdentity ayant la valeur true. Il est très important ensuite de ne jamais modifier la destination. La migration initiale établit la hiérarchie en miroir et les mappages ; toute modification apportée à la destination peut interrompre la liaison. Si cette relation est interrompue, votre seul recours consiste à supprimer la destination, puis à rétablir la liaison comme à l'origine.

Les bases de données de contenu n’autorisent pas les GUID ou les noms de fichiers dupliqués ; vous devez donc être prudent lors de l’implémentation de cette propriété. Ne conservez pas l’identité des objets lorsque vous mettez simplement à jour des fichiers sur le serveur de destination, étant donné que l’opération d’importation ne peut pas déterminer si un fichier est nouveau ou mis à jour, et place donc une copie dupliquée du fichier sur la destination.

Cela se produit car le processus de migration utilise les identificateurs GUID, mais en descendant uniquement jusqu'au niveau de la collection d'éléments. En dessous de ce niveau, c'est-à-dire, pour les fichiers individuels, le système utilise le nom du fichier. Par conséquent, l'importation copie tout simplement la version mise à jour du fichier existant et laisse l'original intact, en créant éventuellement des doublons. Lorsque le serveur de destination rencontre ensuite des noms de fichiers dupliqués, il ne peut pas résoudre l'ambiguïté et devient instable.

Pour prendre en charge la suppression sur le site (une fonction qui supprime les versions antérieures d'éléments stockés sur le serveur source lorsque la migration met à jour et supprime le même fichier sur la destination), la propriété RetainObjectIdentity doit avoir la valeur true.

Reparentage

À présent prenons un scénario très différent. Au lieu d'un scénario de publication, dans lequel les objets sur le serveur source doivent mapper vers leurs fichiers équivalents sur le serveur de destination, imaginez un scénario dans lequel vous souhaitez placer à un emplacement différent dans la hiérarchie de destination un élément de sous-site Web ou de liste spécifique faisant l'objet d'une migration. Pour gérer ce besoin très courant, vous reparentez l'objet (ou les objets) lors de l'importation.

Il est important de noter que, comme nous avons pu le voir dans la section sur la conservation de l’identité de l’objet, si vous ne conservez pas l’identité de l’objet, un objet migré aura besoin d’un nouveau parent spécifié à l’importation. Peu importe si la collection de sites de destination est la même que la collection source ou même qu’elle se trouve dans la même base de données que la collection source. Peu importe également si la collection de sites destination se trouve sur la même batterie de serveurs ou sur une batterie différente que la collection de sites source.

Si vous exportez un élément à partir d'une base de données sans exporter son parent, l'élément exporté devient orphelin dans le package de migration de contenu, ce qui n'est pas nécessairement un problème. Un package peut contenir plusieurs objets orphelins.

Avoir des objets orphelins dans le package de migration n'est pas un problème, car la méthode d'importation permet de définir un nouveau parent pour chacun de ces objets orphelins. C'est ce que signifie le terme « reparentage ». Toutefois, des objets qui sont exportés avec leurs objets parents conservent leurs relations au cours de la migration. Par conséquent, si par exemple, vous exportez le site Web A et que le site Web B est un sous-site de A, vous ne pouvez changer que le parent du site A. Le site A restera le parent de B.

Il existe deux façons de reparenter des objets orphelins lors de l'importation. Dans la première, vous importez tous vos objets orphelins dans le même sous-site Web, tandis que dans l'autre vous affectez des objets parents individuellement à chaque orphelin.

Reparenter en important tous les orphelins dans le même sous-site Web

Vous pouvez reparenter vos objets orphelins simplement en les important tous dans le même sous-site Web. Toutefois, cela ne fonctionne que si tous les objets orphelins sont destinés au même sous-site. Par exemple, il s'agit de la méthode recommandée si vous avez exporté deux ou plusieurs objets liste ou bibliothèque de documents et que vous souhaitez tous les importer dans le même sous-site Web. Cela fonctionne même si les objets d'exportation proviennent de sites source différents. Voici un exemple de code exécutant cela. Les propriétés WebUrl et RetainObjectIdentity sont à noter particulièrement.

SPImportSettings settings = new SPImportSettings(); 
settings.SiteUrl = "https://localhost:2001"; 
settings.WebUrl = "https://localhost:2001/MyDestinationWeb"; 
settings.FileLocation = @"c:\export"; 
settings.FileCompression = false; 
settings.RetainObjectIdentity = false; 

SPImport import = new SPImport(settings); 
import.Run();

Dans l'exemple ci-dessus, la propriété WebUrl définit le site (SPWeb) qui devient le nouveau parent de tous les objets orphelins du package d'exportation.

Notez aussi que la propriété RetainObjectIdentity a la valeur false. Ceci est important, car la conservation de cette propriété avec la valeur False (qui est la valeur par défaut) provoque l'affectation d'un nouveau GUID aux objets orphelins, ce qui est essentiel pour reparenter ces objets.

Reparenter en affectant de nouveaux objets parents individuellement

L'affectation de nouveaux parents aux objets orphelins individuellement est beaucoup plus souple que la méthode précédente, mais requiert également un codage plus important. Dans cette approche, vous devez intercepter l'opération d'importation pour attribuer un nouveau parent à chaque objet orphelin après que l'opération ait constitué la liste de tous les objets orphelins du package de migration. Vous pouvez effectuer cette opération en implémentant un gestionnaire d'événements personnalisé, comme dans l'exemple suivant :

static void OnImportStarted(object sender, SPDeploymentEventArgs args) 
{ 
   SPSite site = new SPSite("https://localhost:2001"); 
   SPWeb web = site.RootWeb; 

   SPImportObjectCollection rootObjects = args.RootObjects; 
   foreach (SPImportObject io in rootObjects) 
   { 
      io.TargetParentUrl = web.Url; 
   } 

   web.dispose();
   site.dispose();
}  

Cette approche utilise la collection RootObject des arguments événement pour agréger tout, puis reparenter tous les objets orphelins. En fait, cela ressemble beaucoup à ce que nous avons fait lorsque nous avons importé tous les objets dans le même sous-site Web, c’est-à-dire que nous avons défini un site spécifique (SPWeb) en tant que nouveau parent de tous les objets orphelins inclus. Notez cependant comment vous pouvez étendre la logique dans le gestionnaire d’événements, par exemple pour affecter des parents différents aux différents orphelins en fonction du type d’objet, comme illustré ici :

static void OnImportStarted(object sender, SPDeploymentEventArgs args) 
{ 
   SPSite site = new SPSite("https://localhost:2001"); 
   SPWeb web = site.RootWeb; 
   SPList list = web.Lists["MyDocLib"]; 

   SPImportObjectCollection rootObjects = args.RootObjects; 
   foreach (SPImportObject io in rootObjects) 
   { 
      if (io.Type == SPDeploymentObjectType.ListItem) 
      { 
         io.TargetParentUrl = list.RootFolder.ServerRelativeUrl;
      } 
      if (io.Type == SPDeploymentObjectType.List) 
      { 
         io.TargetParentUrl = web.Url; 
      } 
      ... 
   } 
 
   web.dispose();
   site.dispose();
}  

Il y a ici une souplesse importante. En plus du reparentage en fonction du type d'objet, vous pouvez au lieu de cela examiner l'TargetParentUrl d'origine, par exemple, pour obtenir l'emplacement source et l'inclure ensuite dans votre logique du reparentage.

L'exemple de code ci-dessous illustre la façon de raccorder le gestionnaire d'événements à l'opération d'importation. Pour cela, vous pouvez procéder comme suit :

static void ImportDocLibItem() 
{ 
   SPImportSettings settings = new SPImportSettings(); 
   settings.SiteUrl = "https://localhost:2001"; 
   settings.FileLocation = @"c:\deployment5"; 
   settings.FileCompression = false; 
   settings.RetainObjectIdentity = false; 

   SPImport import = new SPImport(settings); 

   EventHandler<SPDeploymentEventArgs> eventHandler = new EventHandler<SPDeploymentEventArgs>(OnImportStarted); 
   import.Started += eventHandler; 

   import.Run(); 
} 

Notez que vous devez enregistrer le gestionnaire d'événements avec la classe d'importation avant de commencer l'opération d'importation.

Il existe plusieurs autres gestionnaires d'événements que vous pouvez enregistrer et utiliser pendant l'importation ; ceux-ci sont présentés plus en détail sur le site Web MSDN :

https://msdn.microsoft.com/fr-fr/library/microsoft.sharepoint.deployment.spimport_events.aspx (éventuellement en anglais)

Des événements similaires peuvent également être inscrits pour l'exportation, si nécessaire :

https://msdn.microsoft.com/fr-fr/library/microsoft.sharepoint.deployment.spexport_events.aspx (éventuellement en anglais)

Gestion des types de contenu

Les opérations de migration qui utilisent les commandes d’exportation et d’importation incluent vos fichiers de schéma de définition des types de contenu dans le package d’exportation. Toutefois, dans les cas où les définitions de types de contenu contiennent des références à des fonctionnalités SharePoint personnalisées, vous devez installer et configurer manuellement sur l’ordinateur de destination la fonctionnalité à laquelle le type de contenu fait référence. Les références aux définitions de type des fonctionnalités natives de l’environnement du serveur SharePoint seront restaurées automatiquement.

Au démarrage de l'opération d'importation, vous obtiendrez un message d'avertissement signalant l'identité des fonctionnalités personnalisées pour lesquelles des références doivent être recréées. Vous devez résoudre ces références une fois l'importation terminée.

Pour plus d'informations sur les types de contenus, voir Types de contenu. Pour plus d'informations sur les fonctionnalités SharePoint, voir Utilisation des fonctionnalités.

Gestion des flux de travail

Les flux de travail ne sont pas inclus dans les packages d'exportation, donc lorsque vous configurez initialement une cible de migration, vous devez copier les flux de travail personnalisés que vous avez sur le serveur de destination et reconfigurer la table d'association des flux. Cela inclut la création (ou la restauration sur la destination) des fichiers de définition des flux de travail.

Bien entendu, la restauration manuelle de vos flux de travail personnalisés sur la destination de migration est nécessaire uniquement lorsque vous configurez initialement votre serveur de destination. Par la suite, lors des migrations sélectives dans un scénario de publication, il est préférable que les flux de travail soient exclus du package de migration.

Pour plus d'informations sur la gestion des flux de travail, voir :

• Introduction aux flux de travail dans SharePoint Foundation

• Flux de travail dans SharePoint Foundation