Les migrations Drupal: Comprendre le processus ETL

L’API Migrate est un système très flexible et puissant qui vous permet de collecter des données depuis différents emplacements et de les stocker dans Drupal. Il s’agit en fait d’un framework d’extraction, de transformation et d’alimentation (ETL) complet. Par exemple, il pourrait produire des fichiers CSV. Son utilisation principale, néanmoins, est de créer des entités de contenu Drupal : noeuds, utilisateurs, fichiers, commentaires, etc. L’API est documentée à fond et ses responsables sont très actifs dans le canal #migration en slack pour ceux qui ont besoin d’aide. Les cas d’utilisation de l’API de migration sont nombreux et varient considérablement. Aujourd’hui, nous commençons une série d’articles de blog qui couvriront différents concepts de migration afin que vous puissiez les appliquer à votre projet particulier.

Comprendre le processus ETL

L’extraction, la transformation et le chargement (ETL) est une procédure où les données sont collectées à partir de sources multiples, traitées en fonction des besoins de l’entreprise, et leurs résultats sont stockés pour une utilisation ultérieure. Ce paradigme n’est pas spécifique à Drupal. Les livres et les frameworks abondent sur le sujet. Essayons de comprendre l’idée générale en suivant une analogie de la vie réelle: la cuisson du pain. Pour faire du pain, il faut obtenir différents ingrédients: farine de blé, sel, levure, etc. (extraction). Ensuite, vous devez les combiner dans un processus qui implique le mélange et la cuisson (transformation). Enfin, lorsque le pain est prêt, vous le mettez sur des étagères pour l’exposer dans la boulangerie (chargement). Dans Drupal, chaque étape est réalisée par un plugin Migrate :

• L’étape d’extraction est fournie par des plugins sources.
• L’étape de transformation est fournie par des plugins de processus.
• L’étape de chargement est fournie par les plugins de destination.

Comme c’est le cas avec d’autres systèmes, Drupal core offre quelques fonctionnalités de base qui peuvent être étendues par des modules contribués ou du code personnalisé. Drupal est prêt à l’emploi et peut se connecter aux bases de données SQL, y compris les versions précédentes de Drupal. Il y a des modules contribués pour lire des fichiers CSV, des documents XML, des flux JSON et SOAP, des sites WordPress, des fichiers LibreOffice Calc et Microsoft Office Excel, des feuilles Google, et beaucoup plus.

La liste des plugins de processus de base est impressionnante. Vous pouvez concaténer des chaînes de caractères, exploser ou imploser des tableaux, formater des dates, encoder des URLs, rechercher des données déjà migrées, entre autres opérations de transformation. Migrate Plus offre plus de plugins de processus pour la manipulation de DOM, le remplacement de chaînes de caractères, la translittération, etc.

Le cœur Drupal fournit des plugins de destination pour les entités de contenu et de configuration. La plupart du temps, les cibles sont des entités de contenu comme les nœuds, les utilisateurs, les termes de taxonomie, les commentaires, les fichiers, etc. Il est également possible d’importer des entités de configuration telles que des définitions de champs et de types de contenu. Ceci est souvent utilisé lors de la mise à jour des sites de Drupal 6 ou 7 vers Drupal 8. Via une combinaison de plugins source, processus et destination, il est possible d’écrire des variations de produits Commerce, des Paragraphes, et plus encore.

Note technique : L’API de migration définit un autre type de plugin : id_map. Ils sont utilisés pour mapper les ID de source aux ID de destination. Cela permet au système de garder la trace des enregistrements qui ont été importés et de les annuler si nécessaire.

Les migrations Drupal : un processus en deux étapes

Effectuer une migration Drupal est un processus en deux étapes : écrire les définitions de migration et les exécuter. Les définitions de migration sont écrites au format YAML. Ces fichiers contiennent des informations sur la manière de récupérer les données à la source, de les traiter et de les stocker dans la destination. Il est important de noter que chaque fichier de migration ne peut spécifier qu’une source et une destination. Autrement dit, vous ne pouvez pas lire un fichier CSV et un flux JSON en utilisant le même fichier de définition de migration. De même, vous ne pouvez pas écrire, par exemple, aux nœuds et aux utilisateurs à partir du même fichier. Cependant, vous pouvez utiliser autant de plugins de processus que nécessaire pour convertir vos données du format défini dans la source au format attendu dans la destination.

Un projet de migration typique est constitué de plusieurs fichiers de définition de migration. Bien que ce ne soit pas obligatoire, il est recommandé d’écrire un fichier de migration par paquet d’entité. Si vous migrez des nœuds, cela signifie écrire un fichier de migration par type de contenu. La raison en est que les différents types de contenu auront des configurations de champs différentes. Il est plus facile d’écrire et de gérer les migrations lorsque la destination est homogène. Dans ce cas, un seul type de contenu aura les mêmes champs pour tous les éléments à traiter dans une migration particulière.

Une fois que toutes les définitions de migration ont été écrites, vous devez exécuter les migrations. La façon la plus courante de le faire est d’utiliser le module Migrate Tools qui fournit des commandes Drush et une interface utilisateur (UI) pour exécuter les migrations. Notez que l’interface utilisateur pour exécuter les migrations ne détecte que celles qui ont été définies comme entités de configuration à l’aide du module Migrate Plus. C’est un sujet que nous aborderons à l’avenir. Pour l’instant, nous allons nous en tenir aux mécanismes de définition des migrations du noyau Drupal. Les modules contribués comme Migrate Scheduler, Migrate Manifest et Migrate Run offrent des alternatives pour exécuter les migrations.

Saviez-vous que Drupal avait un framework ETL en place ? Saviez-vous qu’il existe déjà des plugins pour récupérer des données à partir de tant de sources ? Pouvez-vous penser à un cas d’utilisation où la destination ne serait pas la base de données Drupal ? Saviez-vous que la migration se fait en deux étapes ? Veuillez partager vos réponses dans les commentaires. Aussi, je vous serais reconnaissant de bien vouloir partager ce billet de blog avec vos amis et collègues. Demain, vous apprendrez à écrire et exécuter une migration de base.