Paso Aplicar

El paso Aplicar es en el que se añaden o actualizan los registros en el entorno de destino. Al igual que en el paso de comparación, el paso de aplicación consta realmente de varios pasos para gestionar de manera óptima un gran volumen y las dependencias entre los registros del modo más fluido posible.

Nota: para obtener más información sobre cómo simplificar los distintos pasos del proceso, consulte Ejecución de tareas por lotes.

Antes de explicar en detalle el paso Aplicar, en los puntos siguientes se describe el tipo de datos que puede incluirse en un juego de datos concreto.

  1. Registros que no tienen claves externas y no tienen por lo tanto dependencias en otros registros. Ejemplos: mensaje, perfil de visualización.

  2. Registros que tienen claves externas que pueden estar en el destino. Ejemplos: algoritmos para los tipos de algoritmos existentes, roles de tarea para los tipos de tareas existentes.

  3. Registros que tienen claves externas que son registros nuevos pero también parte de la migración. El CMA detectó la relación en el momento de exportación y agrupó los objetos en la misma transacción. Ejemplo: tipo de algoritmo basado en script en el que el script está también en la migración.

  4. Registros que tienen claves externas que son registros nuevos pero también parte de la migración. CMA no detectó la relación. Esto puede ocurrir si la clave externa de referencia se encuentra en un XML o columna de parámetro y el plan de migración no incluía una instrucción para definir explícitamente la relación. Ejemplo: una zona que hace referencia a un script de visibilidad.

  5. Registros que tienen referencias circulares en las que ambos registros son nuevos y forman parte de la migración. El CMA detectó la relación en el momento de exportación y agrupó los objetos en la misma transacción. Ejemplo: script de plug-in para un hueco de plug-in de objeto de negocio. El script hace referencia al objeto de negocio y el objeto de negocio hace referencia a un algoritmo para el tipo de algoritmo del script. Otro ejemplo es cuando varios objetos de mantenimiento contienen el mismo registro y, por tanto, existe en varios objetos de migración.

Para gestionar datos de gran volumen, el primer paso en el proceso de aplicación es ejecutar la lógica de aplicación en el nivel de objeto de migración, a través de un tarea por lotes de varios threads. Esto debería dar como resultado la aplicación correcta en todos los registros en las categorías 1 y 2 anteriores.

Para los registros en las categorías 3 y 4 anteriores, si se añade o actualiza una clave externa antes de su registro relacionado, la validación fallará. Sin embargo, si el registro relacionado se añade primero y después se añade el registro al que hace referencia, el proceso de validación será correcto. La herramienta gestiona estas dependencias de la siguiente manera:
  • Por lo general, la dependencia entre las entidades maestra y de transacción es jerárquica y, en la mayoría de los casos, directa. La herramienta aprovecha este hecho conocido para orquestar el procesamiento de objetos de forma óptima, siguiendo el orden de dependencia en la medida de lo posible. Debe tenerse en cuenta que la relación entre entidades podría ser compleja y que este enfoque no elimina todos los errores relacionados con el orden de procesamiento, aunque sí los reduce de forma significativa.

  • La dependencia entre entidades de configuración es más compleja e interrelacionada y, por tanto, los objetos de migración no están ordenados, es decir, un proceso por lotes con varios threads podría no procesar los registros en el orden deseado.

  • Para superar las posibles incidencias de errores relacionados con el orden de procesamiento, el paso Aplicar tiene una funcionalidad especial, que se describe en detalle a continuación.

Para los registros en la categoría 5 anterior, la referencia circular significará que el proceso de aplicación en el nivel del objeto no añadirá ni actualizará estos registros. El proceso de aplicación en el nivel de transacción cubrirá estos registros. Esto se describe en detalle a continuación.

Aplicar objetos

Una vez que el juego de datos tiene el estado Aplicar objetos, se ejecuta el proceso Supervisor de objeto de migración - Aplicar (F1–MGOAP) para intentar aplicar los objetos.

Nota:

Cuando se utilizan procesos por lotes distintos para datos de negocio, el proceso Supervisor de objeto de migración (Negocio) - Aplicar (F1-MGOAB) funciona de la misma manera para aplicar objetos de negocio de migración.

El proceso en segundo plano en conjunto con el algoritmo Aplicar tienen una funcionalidad especial para asegurar que los registros en las categorías 3 y 4 (anteriores) se aplican correctamente durante este paso:

  • Supervisor de objeto de migración - Aplicar es un proceso especial que vuelve a seleccionar de manera continua los registros en estado Aprobado hasta que no haya más registros elegibles que procesar.

  • Cuando se recibe un error en el algoritmo Aplicar objeto, el algoritmo incrementa un "recuento de iteraciones" en el registro de objeto de migración. Si el recuento de iteraciones no supera un recuento máximo (indicado en el algoritmo), el objeto permanece en el estado Aprobado y puede seleccionarse para volverse a procesar. Si el recuento de iteraciones supera el máximo definido en el algoritmo, el registro pasa al estado Error al aplicar.

Nota: al ejecutar esta tarea por lotes Aplicar, asegúrese de establecer el número de threads en un número que no supere el número de threads soportado por el trabajador del grupo de threads. Si lo hace, los threads en ‘exceso’ esperarán a que finalice el número soportado de threads.

El siguiente diagrama es la porción del ciclo de vida útil del objeto de migración que pertenece al paso Aplicar.

Ciclo de vida útil de objeto de migración -- Aplicar

Una vez finalizado el proceso de supervisión Aplicar, normalmente los objetos estarán en estado Aplicado o en el estado Error al aplicar. Los registros en el estado Error al aplicar están en ese estado por uno de dos motivos.

  • Están en la categoría 5 descrita anteriormente en la que los registros tienen una referencia circular con otro registro. Para este escenario, el paso Aplicar transacciones descrito a continuación debería aplicar los registros correctamente.

  • Hay otro error que no está relacionado con los registros en la migración actual. En este caso, podría necesitarse una intervención manual. Para obtener más información, consulte Resolución de errores más adelante.

Como se muestra en el diagrama, el algoritmo Aplicar objetos puede también detectar un motivo por el que objeto no puede aplicarse. Esto puede ocurrir si el objeto en el entorno de destino se ha actualizado desde el paso de comparación, por lo que el SQL capturado en ese punto deja de ser aplicable. Si ocurre esto, después de que se aplique por completo la migración actual, el fichero original puede volver a importarse y las nuevas comparaciones se pueden generar y aplicar.

Aplicar transacciones

En condiciones ideales, después del paso Aplicar objetos, todos los objetos están en estado Aplicado o en estado Error al aplicar debido a la situación de "referencia circular". El siguiente paso normal es cambiar la responsabilidad a las transacciones. Las transacciones de migración podrán intentar aplicar sus objetos en bloque.

Para asegurar que varios procesos en segundo plano no estén intentando seleccionar los objetos de migración con el fin de ejecutar el paso Aplicar, las transacciones solo son elegibles para tratar de "aplicar mis objetos" si el juego de datos está en estado Aplicar transacciones.

Ciclo de vida útil de juego de datos migración -- Aplicar

Un algoritmo de supervisión, ejecutado por el proceso por lotes de supervisión de juego de datos, en el estado Aplicar objetos, comprueba si ningún objeto de migración tiene el estado Aprobado o si el recuento de registros en estado Error al aplicar no supera un límite configurado. De ser así, de modo automático se cambia el registro al estado Aplicar transacciones.

Si el número de objetos de Error al aplicar supera un límite configurado, el algoritmo de supervisión no realizará la transición automática del registro. En este caso, un usuario deberá determinar si se puede resolver el elevado número de errores o si debe realizarse la transición manual a Aplicar transacciones, a pesar de la cantidad de errores. La sección Resolución de errores que aparece a continuación describe los pasos alternativos que puede realizar el usuario en caso de que haya errores.

Una vez que el juego de datos está en el estado Aplicar transacciones se ejecuta el proceso Supervisor de transacciones de migración - Aplicar (F1–MGTAP). Intenta aplicar los objetos de la transacción. Si ningún objeto de migración es erróneo, la transacción simplemente cambia a Aplicado. Si alguno de los objetos de migración están en estado Error al aplicar, los procesos en segundo plano y el algoritmo Aplicar tienen una funcionalidad especial para superar las dependencias en los objetos migrados.

  • El algoritmo Aplicar selecciona todos los objetos de migración en error y ejecuta todo su SQL y, a continuación, valida todos los registros. Si hay objetos en la transacción con referencias circulares, estos deberían superar la validación en este punto.

  • Puesto que puede seguir habiendo algunas dependencias en las transacciones, ocurre el mismo error de gestión descrito en el paso Aplicar objetos. Cuando se recibe un error en el algoritmo de objeto Aplicar transacción para cualquier objeto en la transacción, el algoritmo incrementa el "recuento de iteraciones" en el registro de transacción de la migración. Si el recuento de reiteraciones no supera un recuento máximo (indicado en el algoritmo), la transacción sigue en el estado Preparado para aplicar y puede elegirse para volver a procesarla. Si el recuento de iteraciones supera el máximo, el registro pasa al estado Error al aplicar. Tenga en cuenta que si algún objeto en la transacción tiene error, no se aplicará ninguno de los objetos. Seguirán teniendo error.

  • Supervisor de transacciones de migración - Aplicar es un proceso especial que vuelve a seleccionar de modo continuo los registros en estado Preparado para aplicar hasta que no haya más registros elegibles para procesar.

Nota: al ejecutar esta tarea por lotes Aplicar, asegúrese de establecer el número de threads en un número que no supere el número de threads soportado por el trabajador del grupo de threads. Si lo hace, los threads 'en exceso' esperarán a que finalice el número de threads soportados, eliminando la ventaja del procesamiento de iteración.

El diagrama siguiente es la porción del ciclo de vida útil de la transacción de migración que pertenece al paso Aplicar, que ilustra los puntos anteriores.

Ciclo de vida útil de transacción de migración -- Aplicar

Si al final del proceso Aplicar, en el nivel de transacción, hay transacciones con estado de error y, por lo tanto, sigue habiendo objetos con error, un usuario debe revisar los errores y determinar cómo resolverlos. Para obtener más información, consulte Resolución de errores más adelante.

Resolución de errores

Según se ha mencionado en las secciones anteriores, los errores se pueden recibir tras la ejecución del proceso Aplicar objetos. Si el número de registros con errores es inferior a un determinado límite y se ejecuta la tarea por lotes de supervisión del juego de datos para ejecutar los algoritmos de supervisión, el sistema realizará la transición automática del juego de datos a Aplicar transacciones. Si no se ejecuta la tarea por lotes de supervisión o el número de objetos con errores supera un determinado límite, un usuario podría tomar la decisión tras ver los errores de la zona de objetos con errores en el portal Importación de juego de datos de migración.

  • Si los errores parecen ser una dependencia relacionada, el usuario puede decidir dejar que las "transacciones apliquen sus objetos" y cambiar el juego de datos a Aplicar transacciones, como se ha descrito anteriormente.

  • Si los errores parecen estar relacionados a una incidencia exterior que puede resolverse de forma manual, el usuario puede decidir resolver la incidencia y repetir el paso Aplicar objetos.

  • El usuario también puede decidir rechazar uno o más objetos para eliminarlos de la migración.

Después de aplicar el paso Aplicar transacciones, si sigue habiendo errores, un usuario debe revisar los registros y determinar cómo proceder. Los errores son visibles en la zona de transacciones con errores en el portal Importación de juego de datos de migración.

  • El usuario puede decidir si rechazar uno o varios objetos para eliminarlos de la migración.

  • El usuario puede resolver de forma manual una incidencia externa a la migración y, a continuación, decidir si hacer lo siguiente:

    • Repetir el paso Aplicar objetos. Esto se recomienda si todavía hay un gran número de objetos con error y no se espera un gran número de dependencias. Las ventajas de ejecutar el paso Aplicar objetos de varios threads asegurarán que el proceso se ejecute de modo eficiente.

    • Repetir el paso Aplicar transacciones.

Puesto que los objetos y las transacciones tienen el estado Error al aplicar, para "reintentar" el paso Aplicar, después de solucionar de forma manual un error, el sistema debe devolver los registros al estado que permite seleccionarlos mediante el proceso adecuado de Aplicar. Para los objetos de migración, es necesario devolver los registros al estado Aprobado. Para las transacciones de migración, es necesario devolver los registros al estado Preparado para aplicar. En los puntos siguientes se describe la lógica de reintento para los objetos de migración.

  • Si un usuario decide Reintentar objetos con un botón de acción en la página Importación de juego de datos de migración, el juego de datos realizará la transición al estado Reintentar objetos. En este punto, deberá ejecutarse la supervisión de objeto de migración.

  • El supervisor del estado Error al aplicar de los objetos detecta que el juego de datos se encuentra en estado Reintentar objetos y dispara la transición de nuevo al estado Aprobado.

  • El siguiente paso será realizar la transición del juego de datos de Reintentar objetos a Aplicar objetos. Este proceso se puede realizar de forma manual o mediante la ejecución del proceso de supervisión Importación de juego de datos de migración.

  • Ahora los objetos son elegibles para su selección por el proceso Aplicar, de nivel de objeto.

Existe una lógica análoga para las transacciones de migración.

  • Si un usuario decide Reintentar transacciones con un botón de acción en la página Importación de juego de datos de migración, el juego de datos realizará la transición al estado Reintentar transacciones. En este punto, deberá ejecutarse la supervisión de objeto de transacción.

  • El supervisor del estado Error al aplicar de las transacciones detecta que el juego de datos se encuentra en estado Reintentar transacciones y dispara la transición de nuevo al estado Preparado para aplicar.

  • El siguiente paso será realizar la transición del juego de datos de Reintentar transacciones a Aplicar transacciones. Este proceso se puede realizar de forma manual o mediante la ejecución del proceso de supervisión Importación de juego de datos de migración.

  • Ahora las transacciones son elegibles para su selección por el proceso Aplicar, de nivel de transacción.

También se puede producir la lógica de reintento al realizar la transición entre Aplicar objetos y Aplicar transacciones, en función de si existen o no errores. En el siguiente escenario se resalta este punto.

  • Tras el paso Aplicar objetos, hay objetos en Error al aplicar. El juego de datos realiza la transición al estado Aplicar transacciones y se realiza el paso Aplicar en el nivel de transacción.

  • Tras el paso Aplicar transacciones, hay transacciones en Error al aplicar.

  • El usuario elige intentar aplicar de nuevo los objetos pulsando en Reintentar objetos. En este punto se siguen los pasos indicados antes para reintentar objetos.

  • Tras aplicar objetos, el usuario puede volver a reintentar los objetos, después de solucionar los errores, si procede.

  • En algún punto, el usuario realizará la transición de nuevo a Aplicar transacciones. En caso de que existan transacciones en Error al aplicar, el sistema realizará la transición automática del juego de datos a Reintentar transacciones y se seguirán los pasos indicados antes para el reintento de transacciones.

Finalización del paso Aplicar

Una vez que todos los objetos de migración están en un estado final (Aplicado, Rechazado o No se puede aplicar), la transacción de migración cambia al estado Aplicado. Una vez que todas las transacciones de migración estén en estado Aplicado, el registro de juego de datos de migración pasa a Finalizado y la importación estará completa.

Nota: para revisar el ciclo de vida útil completo de cada registro, consulte la pestaña Objeto de negocio - Resumen, en los metadatos de aplicación para los objetos de negocio base Importación de juego de datos de migración (F1-MigrObjectImport), Transacción de migración (F1-MigrTransactionImport) y Objeto de migración (F1-MigrObjectImport).