Comment migrer des ressources en bloc assets-migration-guide

Lors de la migration des ressources dans Adobe Experience Manager, il existe plusieurs étapes à prendre en compte. L’extraction des ressources et des métadonnées hors de la page en cours n’est pas traitée dans ce document, car elle varie considérablement selon la mise en œuvre. Ce document explique toutefois comment récupérer ces ressources dans Experience Manager, comment appliquer leurs métadonnées, générer des rendus et les activer pour publier des instances.

Prérequis prerequisites

Avant de suivre toute étape de cette méthode, consultez et mettez en œuvre les instructions du document Conseils relatifs à l’optimisation des performances des ressources. La plupart des étapes, telles que la configuration de tâches simultanées maximales, améliorent considérablement la stabilité et les performances du serveur lors de la charge. D’autres étapes, telles que la configuration d’un magasin de données basé sur les fichiers, sont beaucoup plus difficiles à exécuter une fois le système chargé avec des ressources.

Migrer vers Experience Manager migrating-to-aem

La migration des ressources vers Experience Manager se déroule en plusieurs étapes et doit être considérée comme un processus échelonné. Les phases de migration sont les suivantes :

Désactivation des workflows disabling-workflows

Avant de commencer la migration, désactivez les lanceurs du workflow Ressource de mise à jour de la gestion des ressources numériques. Il est préférable d’intégrer toutes les ressources dans le système, puis d’exécuter les workflows par lots. Si vous êtes déjà en production pendant la migration, vous pouvez planifier l’exécution de ces activités pendant les heures creuses.

Chargement des balises loading-tags

Vous avez peut-être déjà mis en place une taxonomie de balises que vous appliquez à vos images. Bien que la prise en charge des profils de métadonnées par des outils tels que CSV Asset Importer et l’assistance Experience Manager puisse automatiser le processus d’application des balises aux ressources, les balises doivent être chargées dans le système. La fonctionnalité Tag Maker des outils d’ACS AEM permet de renseigner les balises à l’aide d’une feuille de calcul Microsoft Excel chargée dans le système.

Assimilation des ressources ingesting-assets

Les performances et la stabilité sont des considérations importantes lors de l’ingestion de ressources dans le système. Parce que vous chargez une grande quantité de données dans le système, vous devez vous assurer que le système fonctionne de la manière la plus efficace possible afin de réduire le temps nécessaire et d’éviter de surcharger le système, ce qui peut entraîner un crash, en particulier dans les systèmes déjà en production.

Il existe deux approches pour charger les ressources dans le système : une basée sur les notifications push qui utilise HTTP et une basée sur les extractions qui utilise les API JCR.

Envoyer via HTTP pushing-through-http

L’équipe Managed Services d’Adobe utilise un outil appelé Glutton pour charger les données dans les environnements clients. Glutton est une petite application Java qui charge toutes les ressources d’un répertoire dans un autre répertoire d’un déploiement Experience Manager. À la place de Glutton, vous pouvez également utiliser des outils tels que les scripts Perl pour publier les ressources dans le référentiel.

L’utilisation de l’approche Push à l’aide du protocole HTTPS présente deux inconvénients :

L’autre approche d’ingestion de ressources consiste à extraire les ressources du système de fichiers local. Cependant, si vous ne pouvez pas obtenir un lecteur externe ou un partage réseau monté sur le serveur pour suivre une approche basée sur l’extraction, la publication des ressources sur HTTP est la meilleure option.

Récupération à partir du système de fichiers local pulling-from-the-local-filesystem

L’utilitaire Tools CSV Asset Importer d’ACS AEM extrait les ressources du système de fichiers et des métadonnées des ressources à partir d’un fichier CSV pour l’importation des ressources. L’API Experience Manager Asset Manager est utilisée pour importer les ressources dans le système et appliquer les propriétés des métadonnées configurées. Idéalement, les ressources sont montées sur le serveur via un montage de fichiers réseau ou via un lecteur externe.

Comme les ressources n’ont pas besoin d’être transmises sur un réseau, les performances globales sont considérablement améliorées et cette approche est généralement considérée comme la plus efficace pour charger des ressources dans le référentiel. En outre, comme l’outil prend en charge l’ingestion de métadonnées, vous pouvez importer toutes les ressources et métadonnées en une seule étape plutôt que de créer une seconde étape pour appliquer les métadonnées via un autre outil.

Traitement des rendus processing-renditions

Après avoir chargé les ressources dans le système, vous devez les traiter via le workflow Ressource de mise à jour de la gestion des ressources numériques, afin d’extraire les métadonnées et de générer les rendus. Avant d’effectuer cette étape, vous devez dupliquer et modifier le workflow Ressource de mise à jour de la gestion des ressources numériques pour l’adapter à vos besoins. Le workflow prêt à l’emploi contient de nombreuses étapes qui peuvent ne pas vous être nécessaires, telles que la génération de PTIFF Dynamic Media ou l’intégration du InDesign Server.

Après avoir configuré le workflow en fonction de vos besoins, vous disposez de deux options pour l’exécuter :

Activation des ressources activating-assets

Pour les déploiements comportant un niveau de publication, vous devez activer les ressources vers la ferme de publication. Bien qu’Adobe recommande d’exécuter plusieurs instances de publication, il est plus efficace de répliquer toutes les ressources sur une seule instance de publication, puis de cloner cette instance. Lorsque vous activez un grand nombre de ressources, après avoir déclenché une activation d’arborescence, vous devrez peut-être intervenir. En effet, lors du déclenchement des activations, les éléments sont ajoutés à la file d’attente des tâches et des événements Sling. Une fois que la taille de cette file d’attente commence à dépasser environ 40 000 éléments, le traitement ralentit considérablement. Une fois que la taille de cette file d’attente dépasse 100 000 éléments, la stabilité du système commence à en pâtir.

Afin de contourner ce problème, vous pouvez utiliser Fast Action Manager pour gérer la réplication des ressources. Celle-ci fonctionne sans utiliser les files d’attente Sling, ce qui réduit les frais tout en diminuant la charge de travail pour empêcher la surcharge du serveur. Un exemple d’utilisation de Fast Action Manager pour gérer la réplication est présenté sur la page de documentation de la fonctionnalité.

D’autres options permettant de transférer des ressources vers la batterie de serveurs de publication incluent l’utilisation de vlt-rcp ou oak-run, qui sont fournis en tant qu’outils dans le cadre de Jackrabbit. Une autre option consiste à utiliser un outil open-source pour votre infrastructure Experience Manager, à savoir Grabbit, qui se targue d’être plus rapide que vlt.

Pour toutes ces approches, notez que les ressources de l’instance de création ne s’affichent pas comme ayant été activées. Pour gérer le marquage de ces ressources avec le bon statut d’activation, vous devez également exécuter un script pour les marquer comme activées.

Clonage de la publication cloning-publish

Une fois les ressources activées, vous pouvez cloner votre instance de publication pour créer autant de copies que nécessaire pour le déploiement. Le clonage d’un serveur est relativement simple, mais il y a quelques étapes importantes à retenir. Pour cloner la publication :

Activation des workflows enabling-workflows

Une fois la migration terminée, les lanceurs des workflows Ressource de mise à jour de la gestion des ressources numériques doivent être réactivés pour prendre en charge la génération des rendus et l’extraction des métadonnées pour une utilisation quotidienne continue du système.

Migration entre les déploiements Experience Manager migrating-between-aem-instances

Bien que ce ne soit pas aussi courant, vous devez parfois migrer de grandes quantités de données d’une instance Experience Manager à une autre, par exemple, lorsque vous effectuez une mise à niveau de Experience Manager, que vous mettez à niveau votre matériel ou que vous migrez vers un nouveau centre de données, comme avec une migration AMS.

Dans ce cas, vos ressources sont déjà renseignées avec des métadonnées et des rendus sont déjà générés. Vous pouvez simplement vous concentrer sur le déplacement des ressources, d’une instance à une autre. Lors de la migration entre les déploiements d’Experience Manager, procédez comme suit :