Tras iniciar un proceso de migración de M1 a M2 para uno de nuestros clientes, durante la planificación, surgió la duda de cómo realizar la migración de datos (clientes, pedidos, atributos, etc…) desde una versión del framework a la otra.
Durante el análisis realizado para ejecutar esta acción se barajaron varias opciones.
- Crear un desarrollo a medida para realizar la migración de la información deseada.
- Hacer uso de una extensión de terceros que agilizara la tarea.
- Hacer uso de la propia extensión Data Migration Tool que ofrece el framework de Magento en su versión 2.
Tras valorar cada una de las opciones e investigar y hacer uso de la documentación oficial del framework decidimos optar por la tercera opción.
¿Por qué? Es una herramienta nativa que tiene soporte oficial, fácil de extender y sobre la cual se tiene control de las diferentes acciones que se realizan durante el proceso de migración.
Ya se tenía una base desde la que partir, por lo cual la primera opción quedó descartada, y al ser una extensión propia del framework y por la facilidad para extender que tiene, también se descartó la segunda opción.
¿Qué es Data Migration Tool?
Se trata de una herramienta de migración de datos de una versión del framework a otra a través de una interfaz de línea de comandos (CLI).
Esta herramienta verifica y comprueba la relación entre las BBDD de M1 y M2, realizando un seguimiento de la transferencia de datos de una BBDD a la otra.
La conexión entre ambas BBDD se realiza a nivel de un fichero de configuración de la herramienta, que además permite definir los diferentes pasos a ejecutar durante el proceso de migración.
Esta herramienta funciona en tres modos:
- Migración de ajustes de configuración. Se traspasarán las diferentes configuraciones que se necesitan mantener desde una versión del framework a la otra. Muy útil a la hora de conservar las configuraciones de diferentes extensiones sin la necesidad de añadirlas de forma manual.
- Migración masiva de los principales datos (clientes, cestas, pedidos, atributos…).
- Transferencia de actualizaciones de datos incrementales que se realicen en la BBDD de M1 mientras se realiza el proceso de migración. En este último modo se migrará la información actualizada de una BBDD a la otra.
Para dar solución a las necesidades de nuestro cliente se realizaron diferentes modificaciones a nivel de la configuración de pasos en la herramienta, ya que además, por requisito del cliente, únicamente era necesario realizar el traspaso de los datos de los clientes.
En este caso en particular teníamos el hándicap de que no se trataba de una BBDD vacía para M2, siendo lo ideal para un proceso de migración.
¿Y por qué se debe hacer una migración desde M1 a un M2 con una BBDD de datos vacía? Por la propia transferencia de atributos (clientes, productos…) ya que se trasladan los atributos de la tabla eav_attribute desde una versión del framework a la otra.
Aquí llegamos a la elección de esta herramienta para realizar el proceso de migración, ya que dado el nivel de configuración que nos permite y su facilidad para extender, nos facilitaba el partir con una BBDD de M2 en la que ya habíamos creado algunos atributos para cliente.
Extender la herramienta
Cómo habíamos comentado, por necesidad del proyecto y del cliente, únicamente se requería la migración de clientes.
De base, la herramienta de migración de datos ya viene con una serie de pasos preconfigurados, además del mapeo de unas tablas de M1 a M2 en la que se transferían atributos (cliente y producto), configuraciones, términos del buscador, pedidos, cestas, etc…
Dada que esta información no era requerida, sino que simplemente queríamos traspasar los datos de los clientes (las diferentes tablas de customer_entity, por ejemplo, customer_entity_varchar) se hicieron ajustes en la configuración.
Para la configuración, la documentación oficial nos daba diferentes opciones, y por usabilidad y la necesidad que teníamos de extender optamos por configurar la extensión en un módulo propio, es la opción que más se adapta a las necesidades del proyecto.
Por lo tanto, creamos el módulo W2e_Migration para hacer de esqueleto de nuestra configuración de la herramienta, quedando un árbol de directorios y archivos como mostramos en la siguiente captura.
El primer directorio con el que nos encontramos dentro de etc define el tipo de migración que vamos a realizar ya que se trata de una versión de M1 y M2 de Open Source, y a continuación se configura el directorio con la versión de M1 desde la que se va a realizar la migración, añadiendo los ficheros de configuración necesarios.
En la estructura del vendor de la herramienta podemos encontrar las diferentes opciones.
En nuestro caso, usamos para ambas versiones del framework la versión Open Source, y como decíamos, la versión de M1 desde la que partimos es la 1.7.0.2, por lo tanto, es el directorio que extendemos para configurar.
Configuración
Tras extender la herramienta creando los directorios anteriores, bajo la ruta opensource-to-opensource > 1.7.0.2 crearemos el fichero de configuración config.xml.
Podemos realizar una copia del fichero de configuración original del vendor de Magento y luego lo iremos adaptando a nuestras necesidades.
Cómo habíamos visto, la herramienta realiza la conexión entre las dos versiones del framework a través de las BBDD, y en este fichero es dónde se configura dicha relación.
Se hace la distinción entre origen y destino, indicando bajo la etiqueta source los datos de conexión de la BBDD de M1 (es el origen de la migración) y bajo la etiqueta destination la los datos de conexión de la BBDD de M1.
En caso de que las tablas en M1 tengan un prefijo se indican con la opción source_prefix, en caso de que sea en M2 donde se hace uso del prefijo para el nombre de las tablas se haría uso de la etiqueta destination_prefix.
Añadiendo la información de conexión en el fichero de configuración ya se podrá iniciar el proceso de migración desde una versión del framework a la otra.
El fichero de configuración trae una serie de pasos establecidos que se ejecutan secuencialmente y afectan a diferentes tablas.
Cada paso es configurable en función de los requerimientos, como habíamos comentado, en nuestro caso, únicamente era necesario migrar los datos de los clientes, sin migrar atributos eav, ni pedidos, ni cesta, ni cualquier otro dato, y para ello, seguimos realizando la personalización del fichero config.xml.
Revisando el fichero, y adaptándolo a nuestras necesidades, haciendo referencia de nuevo a los tres modos de funcionamiento de los que hace uso la herramienta, encontramos los siguientes pasos.
Sistema/Configuración
Dados los requerimientos, y por las necesidades del proyecto, no hacemos uso de este primer paso que incluye el fichero de configuración, por lo que lo comentamos para que no se transfieran de una BBDD a la otra las configuraciones e información de las diferentes tiendas.
2. Datos
Dentro del modo de datos encontramos los diferentes pasos encargados de transferir la siguiente información de una BBDD a la otra.
- Atributos EAV
- Atributos de cliente (a sus respectivas tablas de customer_entity, customer_entity_varchar…)
- Datos de las diferentes tablas definidas dentro del fichero map.xml, que permite la configuración de diferentes tablas que no hagan referencia a las entidades por defecto de M1, ya sean tablas personalizadas por desarrollos hechos a medida, etc…
- URL Rewrite
- Valoraciones
- Precios
- Pedidos
- Inventario
Adicionalmente incluye un paso de post procesamiento de datos que se encarga de limpiar registros de la base de datos al terminar la migración de datos. Realiza una búsqueda de atributos que no contengan valores y se descartan una vez que se ha realizado el proceso de datos.
Se hace especial mención a este paso ya que fue necesario comentarlo y crear un paso personalizado.
En este enlace a la documentación de Magento se puede encontrar toda la información sobre cómo crear un paso personalizado en caso de que sea necesario.
3.Delta
Migración de datos incrementales, en caso que durante la ejecución del proceso se hubiera registrado datos nuevos en la BBDD de M1, al ejecutarse este paso, se realizaría una migración de estos datos a la BBDD de M2.
Adaptación a los requerimientos
Partimos de una migración parcial de datos, únicamente se trasladarán los datos de clientes, y además, la BBDD de M2 no está vacía, se habían creado atributos personalizados de clientes, por lo tanto, existe una disparidad entre las diferentes tablas de customer_entity de M1 y M2, ya que los id’s de los atributos son diferentes y al hacer el traspaso de migración los id’s de los atributos no coinciden.
¿Cómo solucionamos esto haciendo uso de la herramienta de migración de datos de Magento?
Previamente habíamos comentado por qué habíamos elegido finalmente esta herramienta para afrontar el requerimiento de migración de datos, y este es uno de los motivos, la facilidad para poder mapear los atributos desde el origen (source) hacia el destino (destination).
En la captura en la que mostrábamos la estructura de nuestra extensión personalizada desde la que extendemos la herramienta veíamos diferentes directorios y archivos, hemos hablado ya de la elección del directorio opensource, de la versión elegida (1.7.0.2), y del archivo de configuración (config.xml).
Además de estos directorios y del fichero de configuración, podíamos encontrar otros ficheros XML de configuración.
Vemos que dentro del directorio de la versión de M1 a migrar tenemos el fichero de configuración ya mencionado (config.xml) y el fichero map.xml, y es porque son ficheros de configuración para esta versión específica de M1, para otras versiones los archivos pueden variar por las diferencias a nivel de estructura de BBDD.
En este caso vemos que los ficheros map-customer.xml e ignore-value-attribute-code.xml se encuentran fuera del directorio de la versión de M1 a migrar.
Fichero map.xml
Nos permite hacer un mapeo personalizado a nivel general entre tablas y diferentes columnas de tablas entre M1 y M2.
Las posibilidades que nos ofrece este fichero son las siguientes.
- Cambiar nombre de tablas al migrar desde M1 a M2.
- Cambiar nombres de campos de tablas al migrar desde M1 a M2.
- Ignorar tablas o campos para no migrar desde M1 a M2.
- Adaptar la migración de datos de M1 a un campo específico de M2.
Este fichero se usa a nivel general, en nuestro caso, hacemos uso del fichero para evitar que se migren algunas tablas de M1 a M2, por ejemplo sales_flat_order, sales_flat_quote, etc… y algunas tablas custom de desarrollos personalizados realizados en M1.
Tiene un formato sencillo que nos permite diferenciar entre el origen (source) y el destino (destination), y optar por las estrategias de migración adecuadas para cada punto.
Para nuestro caso de uso necesitábamos ignorar las tablas desde el origen, por lo que lo indicamos en el fichero map.xml de la siguiente manera.
- Con la etiqueta source indicamos que la acción se realiza en el origen.
- Con la etiqueta document_rules indicamos que se trata de una regla a nivel de tabla. En la configuración de la migración hacemos referencia a las tablas como document, siguiendo la sintaxis de la propia herramienta.
- Con la etiqueta ignore indicamos que queremos ignorar la migración, y al hacer uso de la etiqueta document anidada a ignore le indicamos la tabla que debe ignorar.
Definiéndolo como hemos indicado en los puntos anteriores lo que evitamos es que se migren los datos de cualquier tabla de affiliate al indicar el asterisco.
En caso de querer ignorar una tabla en específico indicaremos su nombre completo, por ejemplo, index_process.
En este enlace a la documentación oficial se podrá obtener más información acerca del uso del fichero para la realización del mapeo general de datos.
Una vez configurado y adaptado a nuestras necesidades, debemos indicar en el fichero config.xml la ruta del fichero map.xml para que tenga en cuenta las configuraciones generadas en el documento.
Fichero map-customer.xml
Como habíamos comentado, el fichero map.xml se usaba a nivel de mapeo general de tablas, columnas y conversión de datos de M1 a M2, pero para cubrir nuestras necesidades era necesario hacer uso de algunos ficheros más.
A nivel de tablas de clientes (customer_entity, customer_entity_varchar…) necesitábamos realizar un mapeado de los atributos que ya teníamos en M2 al realizar la migración, y esto era posible haciendo uso del fichero map-customer.xml
No sólo da la posibilidad de convertir los ID’s de los atributos de M1 a M2, si no que además también posibilita convertir los valores de dichos atributos.
Por ejemplo, se había creado el atributo default_payment para cliente, existía discrepancia entre el ID del atributo entre M1 y M2 además de los valores que se le habían dado al selector.
Para solucionarlo, se realiza un mapeo de los id’s de atributo y de sus valores, para que de esa forma pudieran ser accesibles desde la ficha de cliente en M2.
Al igual que el fichero map.xml tiene una sintaxis simple, y haciendo uso de las siguientes etiquetas conseguimos transformar los id’s de los atributos y sus valores al realizar la migración desde M1 a M2.
- Con la etiqueta source indicamos que la transformación se hace desde el origen hacia el destino.
- Con la etiqueta transform indicamos que se va a realizar un mapeo de valores.
- Con la etiqueta field indicamos la tabla y el campo del que queremos modificar su valor.
- Con la etiqueta handler indicamos la clase de la que se hará uso para realizar la acción de convertir los valores.
- Anidada dentro de la etiqueta handler indicamos a través de la etiqueta params la acción que se va a realizar, que en este caso es un mapeo de valores y lo indicamos con el atributo value en forma de array, siendo el valor de la izquierda el que tiene en la BBDD de origen (M1) y el valor de la derecha será el que debe tomar en la BBDD destino (M2), por ejemplo, modificamos la columna attribute_id de la tabla customer_entity_text convirtiendo el valor para el atributo 649 a 185.
Con el valor del atributo se sigue el mismo patrón, lo que en lugar de referenciar a la columna attribute_id, se referencia a la columna value.
En este enlace a la documentación oficial de Magento podrán encontrar más información acerca de las posibilidades que ofrece el fichero de mapeo para mapear valores, cambiar campos, etc
Fichero ignore-value-attribute-code.xml
Otra de las casuísticas que debíamos cumplir en base a los requerimientos, era ignorar la migración de datos que no estuvieran en uso para evitar “ensuciar” la nueva BBDD con dichos valores.
Se nos presentaba otra problemática que debíamos resolver extendiendo la herramienta nativa de Magento 2 para migraciones.
Cómo habíamos comentado al principio, habíamos decidido hacer uso de esta herramienta por la facilidad que nos ofrecía a la hora de extender y adaptar a nuestras necesidades, cubriendo todos los requerimientos que teníamos.
La herramienta nos daba la posibilidad de crear pasos personalizados para que se pudieran ejecutar secuencialmente durante el proceso, además de crear un documento con formato XML personalizado para tener en cuenta los valores que debíamos ignorar.
Al principio habíamos comentado que uno de los pasos era el post procesado de datos, y que de forma nativa la herramienta incluía al final del modo de datos.
Para cubrir nuestras necesidades, comentamos el paso por post procesado de datos que venía por defecto, creando uno totalmente personalizado, siguiendo la siguiente ruta de directorios y creación de clases.
Además de esto, se debe indicar el paso y la clase de la que se hará uso para el procesamiento de los datos, y esto se debe hacer a nivel de fichero de configuración, que como ya sabemos, se encuentra con el nombre config.xml dentro del directorio etc de la versión del framework desde la que vamos a iniciar la migración.
Al tratarse de un proceso de post procesado no es necesario verificar la integridad de los datos ya que se realiza en los pasos posteriores al migrar los datos a las tablas correspondientes.
Su definición en el fichero de configuración es simple, con la etiqueta step indicamos que se trata de un nuevo paso, añadiendo un nuevo título con el atributo title que nos ayudará a identificarlo durante el proceso de migración en la consola.
Al tratarse de un paso utilizado durante el modo de datos debemos configurarlo bajo dicho paso.
A modo de recordatorio, la herramienta funciona en tres modos.
- Sistema
- Datos
- Delta
Al tratarse de un procesado de datos indicamos nuestro paso personalizado en el modo data.
La funcionalidad que añadimos con la creación de este nuevo paso es la de ignorar los valores para aquellos atributos que no existan en M2, y para hacerlo de una forma sencilla y que sea amigable para Magento, seguimos las prácticas de las que hacen uso en la herramienta, y para ellos creamos el fichero ignore-value-attribute-code.xml.
Este fichero es inyectado en la clase IgnoreEavAttributeValueData, indicándolo en el constructor de la clase.
La herramienta trae sus propias funciones para leer los documentos, además de interpretar su contenido.
En el fichero creado indicamos los diferentes atributos a ignorar con la siguiente sintaxis.
Y de esa forma, con una función personalizada de la clase IgnoreEavAttributeValueData leemos los valores del grupo ignore y podemos tratar los datos en forma de array.
Esta recopilación de id’s de atributos es tratada en la clase Data que definimos en el paso personalizado, y de esta manera, limpiamos los registros innecesarios en la BBDD de Magento 2.
El único inconveniente que encontramos al hacer uso de esta herramienta es que para eliminar valores por ID’s de atributos sin hacer uso de la migración de la tabla EAV debía hacerse tras el procesado, pero no implicaba mayor problemática y con esta solución realizada a medida con un desarrollo personalizado la BBDD quedaba únicamente con los valores que se requerían.
Resumiendo, la herramienta de migración de datos de Magento 2 ofrece flexibilidad y facilidad para extender, por lo que cuando se requiere de modificaciones o de hacer frente a diferentes hándicaps por motivos del proyecto debería ser tomada en cuenta.
En este último enlace se tiene acceso a toda la documentación, dónde se explica en detalle su funcionalidad y sus especificaciones técnicas, siendo de gran ayuda a la hora de realizar desarrollos a medida.
