Migración de datos de negocio
CMA se puede utilizar para efectuar una migración dirigida de entidades maestras seleccionadas y sus datos de transacciones relacionados de un entorno a otro. Por ejemplo, para la migración de un subjuego de cuentas y sus datos relacionados para la realización de pruebas.
En los puntos siguientes se resaltan las diferencias clave entre los datos de negocio y los datos de configuración, que hacen necesario tener en cuenta consideraciones especiales a la hora de diseñar las migraciones de datos de negocio:
-
Por lo general, la migración de datos de negocio implica un número mucho mayor de registros de un juego de datos, en comparación con un juego de datos exclusivo de configuración. Aunque no existe ningún límite explícito para el tamaño del juego de datos, debe asumirse un límite razonable.
-
La inclusión de grandes juegos de entidades dependientes de un número relativamente reducido de entidades en el mismo juego de datos ralentiza de forma significativa el proceso de importación. Esta situación se produce al combinar datos de configuración, maestros y datos de transacciones de volumen elevado en una única migración. Por tanto, es recomendable diseñar migraciones independientes para estas clases de datos. Para obtener más información, consulte a continuación la sección Reducción de dependencia entre objetos de migración.
-
Todas las entidades de negocio tienen una clave generada por el sistema. Para obtener más información, consulte Datos con claves primarias generadas por el sistema.
En las secciones siguientes se amplían los temas y conceptos relacionados con la migración de datos de negocio.
Reducción de dependencia entre objetos de migración
CMA aprovecha la integridad referencial y las reglas de negocio de la aplicación para garantizar la conformidad y validez de las entidades cuando se importan en otro entorno. Estas reglas existen para evitar la importación de una entidad cuando una de las entidades a las que hace referencia no existe en el entorno de destino. Cuando tanto la entidad de referencia como aquella a la que hace referencia forman parte del mismo juego de datos, establecen una dependencia que dicta la secuencia en la que deben procesarse las entidades para su correcta importación. Debe tenerse en cuenta que la herramienta soporta las situaciones más complejas y extrañas en las que la dependencia entre entidades es cíclica, es decir la entidad A se refiere, de forma directa o indirecta, a la entidad B, mientras que esta última hace referencia de nuevo, de forma directa o indirecta, a la entidad A, por lo que el procesamiento secuencial no es suficiente para garantizar la correcta importación.
La herramienta utiliza relaciones de clave externa entre entidades del mismo juego de datos para identificar juegos de entidades dependientes y agruparlos en registros de transacción de migración independientes. Debe tener en cuenta que estas claves externas se definen en el repositorio del modelo de datos de la aplicación y no en el nivel de base de datos, para una mayor flexibilidad. Cuanto mayor sea la transacción de migración, más complejo será el proceso para la correcta importación de todos los objetos. Por ello, aunque la herramienta está diseñada para soportar todos los tipos de dependencias (secuenciales y cíclicas), la gestión de juegos de objetos dependientes de gran tamaño puede suponer un coste de rendimiento significativo.
Si bien las entidades de configuración tienden a mantener una elevada interdependencia, el número total de entidades que comprenden el juego completo de objetos de configuración es relativamente pequeño. Por tanto, el impacto en el rendimiento de estas dependencias al importar un juego de datos exclusivo de la configuración es inapreciable. Por otra parte, muchas entidades maestras y de transacción suelen hacer referencia a las entidades de configuración porque estas controlan muchos aspectos de las reglas de negocio de las primeras. Como tal, la combinación de datos de configuración y de negocio en el mismo juego de datos puede suponer la formación de grandes juegos de entidades de negocio que dependen de un número reducido de entidades de configuración. Por ello, es muy recomendable importar o definir datos de configuración en el entorno de destino antes de importar en él los datos de negocio.
De forma similar, hay algunos datos de transacción que suelen tener un volumen mucho más elevado, en comparación con las entidades de datos maestros a los que hacen referencia. También en este caso se recomienda encarecidamente la migración de entidades de datos maestros antes que el gran volumen de datos de transacciones relacionados. Por ejemplo, muchos registros de medidas de intervalo (datos de transacción) hacen referencia al mismo componente de medición (datos maestros). La migración de un gran volumen de datos de medida junto a sus componentes de medida podría dar lugar a una gran transacción de migración que llevaría mucho tiempo importar. La importación de los componentes de medida antes de migrar las medidas de intervalo, eliminará las dependencias innecesarias en el juego de datos exclusivo de medidas, mejorando de forma significativa el rendimiento del proceso global.
Volumen de datos razonable
El volumen total de las entidades de negocio que se van a migrar en un único juego de datos debe tener un tamaño razonable. Por ejemplo, la importación de varios centenares de cuentas y sus datos maestros y de transacción relacionados se considera un tamaño razonable. La migración de una cantidad de datos excesiva puede alcanzar las limitaciones físicas y de rendimiento de la herramienta.
Se puede utilizar cualquier método de solicitud de migración soportado para describir las entidades que se van a exportar. Si opta por una solicitud de migración de la lista de entidades, considere el uso de la zona de panel de control Recopilar entidad para crear la lista de entidades a medida que accede a ellas en sus respectivos portales.
Origen de datos único
CMA utiliza una clave primaria de entidad para determinar si es nueva para un entorno de destino y, por tanto, debe añadirse, o si hace referencia a un registro existente y debe sustituirse por la nueva versión. Todas las entidades de negocio tienen claves generadas por el sistema, específicas del entorno. Por lo tanto, es posible disponer de distintas entidades en entornos independientes con la misma clave primaria. Al migrar entidades con claves generadas por el sistema, es muy recomendable migrar los datos a un entorno de destino desde un entorno de origen único y evitar la creación de estas entidades en el entorno de destino mediante la aplicación. Esta práctica garantiza que las claves primarias de una entidad importada siempre están sincronizadas con el entorno de origen. Para obtener más información y otras consideraciones, consulte Datos con claves primarias generadas por el sistema.
Sin supresión
CMA no gestiona la supresión de entidades de ningún tipo, ya sean entidades de configuración o de negocio. En caso de que deba repetirse una prueba con una instantánea inicial de los datos, deberá restaurar el entorno de destino a una copia de seguridad obtenida antes de la importación de los datos de prueba, e importar la última versión de dichos datos. Si no es preciso suprimir las entidades importadas con anterioridad, podrá continuar recargando los datos de prueba desde un entorno de origen único, según sea necesario.
Modo de importación masiva
Por defecto, el proceso de importación crea un objeto de migración para cada entidad importada. Esto permite la generación granular de informes y la gestión de errores en el nivel de entidad. Cuando se importa un juego de datos de gran volumen de entidades de negocio, la gestión granular tiene un inconveniente respecto al rendimiento. Es posible que en esta situación desee utilizar la opción de importación masiva en la solicitud de importación del conjunto de datos de migración. En este modo, solo se crea un registro de objeto de migración para varias entidades del mismo objeto de mantenimiento. De la misma manera, solo se crea un registro de transacción de migración para varios grupos de transacciones lógicas. El uso de esta opción reduce el esfuerzo de gestión de objetos de migración durante todo el proceso, mejorando así el rendimiento.
Tenga en cuenta que cada entidad se sigue comparando y validando de forma individual, como en el procesamiento de importación normal, pero si una entidad no es válida, no se aplica el objeto de migración completo, lo cual afecta a todas las entidades agrupadas con él. El modo de importación masiva resulta útil cuando se importa un juego de datos grande desde un origen de datos validado, de manera que no se anticipe prácticamente ningún error.
Esta opción solo se soporta para objetos de mantenimiento maestros y de transacción, es decir, no se aplica a migraciones de configuración.
Modo Solo insertar
Por defecto, el paso de comparación del proceso de importación tiene que determinar si la entidad importada es nueva y, por tanto, debe añadirse, si representa un cambio en una entidad existente y se debe actualizar o si la entidad no se ha modificado. Cuando se importa un juego de datos de gran volumen de entidades de negocio que son todas nuevas para el entorno actual, esta comprobación lleva tiempo y se puede evitar. En esta situación, puede utilizar la opción Solo insertar en la solicitud de importación del juego de datos de migración para indicar que se supone que todas las entidades importadas son adiciones nuevas en el entorno actual. Al hacer esto, el proceso de importación evita los pasos innecesarios para determinar si la entidad debe añadirse o actualizarse y, de este modo, agiliza el proceso de importación.
Esta opción solo se soporta para objetos de mantenimiento maestros y de transacción, es decir, no se aplica a migraciones de configuración.
Distintos procesos por lotes para gestionar objetos de negocio de migración
Por defecto, los mismos procesos por lotes relacionados con importación gestionan las migraciones de datos de configuración y de negocio. Generalmente, las migraciones de datos de negocio implican un gran volumen de registros en comparación con juegos de datos de configuración menos voluminosos. El procesamiento conjunto mediante el mismo proceso por lotes, puede perjudicar al rendimiento de las migraciones de configuración, impidiendo que finalicen con mayor rapidez y frecuencia. La incidencia afecta principalmente a los entornos de prueba en los que las migraciones de clases de datos mixtas son más comunes: los datos de configuración se importan desde un entorno inferior y los datos de prueba de gran volumen se importan desde un entorno superior. Puede ajustar la configuración del producto base en esos entornos para beneficiarse de la separación de los procesos de importación para datos de negocio y de configuración.
Tenga en cuenta que la capacidad para separar procesos de importación se aplica a los objetos de migración debido solo a su volumen. Los juegos de datos de migración y los registros de transacción tienen un volumen bajo y, por eso, se gestionan mediante los mismos procesos por lotes.
Se incluyen procesos por lotes designados para importar objetos de migración que contienen datos de negocio, pero no se utilizan por defecto:
-
F1-MGOPB - Supervisor de objetos de migración (Negocio)
-
F1-MGOAB - Supervisor de objetos de migración (Negocio) - Aplicar
Siga estos pasos para utilizar los procesos por lotes designados independientes para los datos de negocio:
-
Actualice el objeto de negocio Datos de negocio de objeto de migración (F1-MigrObjectBus) para hacer referencia a los controles de lotes relacionados con los estados siguientes:
-
Pendiente, Error al aplicar, Necesita revisión - Supervisor de objetos de migración (Negocio) - F1-MGOPB
-
Aprobado - Supervisor de objeto de migración (Negocio) - Aplicar - F1-MGOAB
-
-
Si su organización utiliza ejecuciones de tareas controladas por eventos para procesos por lotes de CMA, consulte Ejecución de tareas por lotes para ver pasos de configuración adicionales.