Paso de Aplicación

El paso de aplicación es el paso en el que agregan o se actualizan registros en el entorno de destino. Como el paso de comparación, el paso de aplicación consiste generalmente de múltiples pasos para manejar de manera óptima volúmenes grandes y dependencias entre registros de la mejor manera posible.

Nota: Consulte Ejecución de Trabajos de Lote para obtener más información sobre cómo perfeccionar los diversos pasos del proceso.

Antes de explicar los pasos de aplicación en detalle, en los siguientes puntos se realza el tipo de datos que se pueden incluir en un juego de datos determinado.

  1. Registros que no tienen claves foráneas y, por lo tanto, no tienen dependencias en otros registros. Ejemplos: Mensaje, Perfil de Despliegue.

  2. Registros que tienen claves foráneas que es posible que ya estén en el destino. Ejemplos: Algoritmos para tipos de algoritmo existentes, Roles de Tarea para Tipos de Tareas existentes.

  3. Registros que tienen claves foráneas que son registros nuevos pero también son parte de la migración. El CMA detectó la relación durante la exportación y agrupó los objetos en la misma transacción. Ejemplo: Tipo de Algoritmo basado en Script, donde el script también está en la migración.

  4. Registros que tienen claves foráneas que son registros nuevos pero también son parte de la migración. El CMA no detectó la relación. Esto puede ocurrir si la clave foránea de referencia está en un XML o una columna de parámetros, y el plan de migración no incluyó una instrucción para definir de forma explícita la relación. Por ejemplo, una Zona que hace referencia a un script de visibilidad.

  5. Registros que tienen referencias circulares, donde ambos registros son nuevos y son parte de la migración. El CMA detectó la relación durante la exportación y agrupó los objetos en la misma transacción. Ejemplo: Script de conector para un lugar de conector 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 se da cuando el mismo registro es mantenido por múltiples objetos de mantenimiento y, por lo tanto, existe en múltiples objetos de migración.

Para manejar grandes volúmenes de datos, el primer paso del proceso de aplicación es realizar la lógica de aplicación en el nivel del objeto de migración mediante un trabajo en lote de múltiples subprocesos. Esto debe generar la aplicación correcta de todos los registros en las categorías 1 y 2 de arriba.

Para los registros de las categorías 3 y 4 de arriba, si se agrega o se actualiza un registro con una clave foránea antes del registro relacionado, la validación fallará. Sin embargo, si se agrega primero el registro relacionado y, a continuación, el registro que hace referencia a éste, se aprobará la validación. La herramienta maneja estas dependencias de la siguiente manera:
  • La dependencia entre las entidades principales y las de transacción suele ser jerárquica y, en la mayoría de los casos, sencilla. La herramienta aprovecha ese conocimiento para organizar el procesamiento de objetos de una manera óptima que siga su orden de dependencia lo mejor posible. Tenga en cuenta que la relación entre entidades puede ser compleja y este enfoque no elimina todos los errores relacionados con el orden de procesamiento, sino que los reduce significativamente.

  • La dependencia entre entidades de configuración es más compleja y está interrelacionada; por lo tanto, los objetos de migración no están ordenados, es decir, es posible que el proceso de lote con múltiples subprocesos no procese los registros en el orden deseado.

  • Para solucionar posibles 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 de la categoría 5 de arriba, la referencia circular significará que el proceso de aplicación en el nivel de objeto no agregará ni actualizará correctamente estos registros. Este proceso de aplicación en el nivel de transacción cubrirá estos registros. Esto se describe en detalle abajo.

Aplicar Objetos

Una vez que el Juego de Datos tiene el estado Aplicar Objetos, se ejecuta el proceso Monitoreo de Objetos de Migración: Aplicar (F1-MGOAP) para intentar aplicar los objetos.

Nota:

Al utilizar procesos de lote separados para datos de negocios, el proceso Monitor de Objeto de Migración (Negocio): Aplicar (F1-MGOAB) funciona de la misma manera para aplicar objetos de migración de negocio.

El proceso en segundo plano, junto con el algoritmo Aplicar, tiene una funcionalidad especial, para garantizar que los registros de las categorías 3 y 4 (arriba) se apliquen correctamente durante este paso:

  • El proceso Monitoreo de Objetos de Migración: Aplicar es un proceso especial que vuelve a seleccionar continuamente los registros con el estado Aprobado hasta que no hay más registros elegibles para procesar.

  • Cuando se recibe un error en el algoritmo Aplicar Objeto, el algoritmo incrementa un "recuento de iteración" en el registro del objeto de migración. Si el recuento de iteración no excede un recuento máximo (que se observa en el algoritmo), el objeto permanece en el estado Aprobado y es elegible para ser seleccionado nuevamente para procesamiento. Si el recuento de iteración excede el máximo definido en el algoritmo, el registro pasa al estado Error durante Aplicación.

Nota: Al ejecutar este trabajo de lote Aplicar, asegúrese de definir el número de subprocesos en un número que no supere el número de subprocesos soportados por el trabajador de grupo de subprocesos. Al hacerlo, los subprocesos "excedentes" esperarán a que finalice el número de subprocesos soportados.

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

Ciclo de Vida de Aplicación de Objetos de Migración

Cuando se finaliza el proceso de monitoreo de Aplicar, generalmente los objetos tienen el estado Aplicado o el estado Error durante Aplicación. Los registros con el estado Error durante Aplicación están en ese estado por uno de dos motivos.

  • Están en la categoría 5 que se describe arriba, donde los registros tienen una referencia circular con otro registro. Para este escenario, el paso Aplicar Transacciones que se describe abajo debe aplicar correctamente los registros.

  • Hay algún otro error que no está relacionado con los registros de la migración actual. En este caso, es posible que se requiera la intervención manual. Consulte la sección Resolución de Errores para obtener más información.

Como se muestra en el diagrama, el algoritmo Aplicar Objetos también puede detectar un motivo por el que el objeto no se puede aplicar. Esto puede ocurrir si el objeto del entorno de destino se ha actualizado desde el paso de comparación, lo que hace que el SQL capturado en ese punto ya no sea aplicable. Si esto ocurre, una vez que se ha aplicado por completo la migración actual, es posible que se importe nuevamente el archivo original, y se podrán generar y aplicar nuevas comparaciones.

Aplicar Transacciones

Idealmente, después del paso Aplicar Objetos, todos los objetos tienen el estado Aplicadoo Error de Aplicación debido a una situación de "referencia circular”. El paso siguiente generalmente consiste en traspasar la responsabilidad a las transacciones. A continuación, las transacciones de migración pueden intentar aplicar sus objetos en bloque.

Con el fin de garantizar que múltiples procesos en segundo plano no estén intentando seleccionar los objetos de migración para ejecutar el paso Aplicar, las Transacciones solamente son elegibles para intentar "aplicar mis objetos" si el Juego de Datos está en el estado Aplicar Transacciones.

Ciclo de Vida de Aplicación de Juego de Datos de Migración

Un algoritmo de monitoreo (ejecutado por el proceso de lote de monitoreo de juego de datos) con el estado Aplicar Objetos controla si todos los objetos de migración ya no tienen el estado Aprobado o el recuento de registros con el estado Error de Aplicación no excede un límite configurado. Si es así, pasa automáticamente el registro al estado Aplicar Transacciones.

Si el número de objetos en el estado Error de Aplicación excede un límite configurado, el algoritmo de monitoreo no realiza automáticamente la transición del registro. En ese caso, un usuario deberá determinar si la gran cantidad de errores se puede resolver o si se puede realizar la transición manualmente a Aplicar Transacciones (a pesar de la gran cantidad de errores). La sección Resolución de Errores que aparece a continuación describe los pasos alternativos que deberá seguir el usuario si hay errores.

Una vez que el Juego de Datos tiene el estado Aplicar Transacciones, se ejecuta el proceso Monitoreo de Transacción de Migración: Aplicar (F1-MGTAP). Intenta aplicar los objetos de la transacción. Si no hay objetos de migración con estado de error, la transacción de migración simplemente pasa al estado Aplicado. Si alguno de los objetos de migración tienen el estado Error durante Aplicación, el proceso en segundo plano y el algoritmo Aplicar tienen una funcionalidad especial para intentar solucionar las dependencias de los objetos migrados:

  • El algoritmo Aplicar selecciona todos los objetos de migración con estado de error, realiza todas las operaciones de SQL y, a continuación, valida todos los registros. Si hay objetos en la transacción con referencias circulares, deberán aprobar la validación en este punto.

  • Dado que es posible que aún haya dependencias en las transacciones, aquí se produce un manejo de errores similar al descrito en el paso Aplicar Objetos. Si se recibe un error en el algoritmo Aplicar Objeto de Transacción para cualquiera de los objetos de la transacción, el algoritmo aumenta el "recuento de iteración" en el registro de la transacción de migración. Si el recuento de iteración no excede un recuento máximo (que se observa en el algoritmo), la transacción permanece en el estado Listo para Aplicar y es elegible para ser seleccionado nuevamente para procesamiento. Si el recuento de iteración excede el máximo, el registro pasa al estado Error durante Aplicación. Tenga en cuenta que si alguno de los objetos de la transacción tiene el estado de error, no se aplicará ninguno de los objetos. Todos permanecen en el estado de error.

  • El proceso Monitoreo de Transacción de Migración: Aplicar es un proceso especial que vuelve a seleccionar continuamente los registros con el estado Listo para Aplicar hasta que no hay más registros elegibles para procesar.

Nota: Al ejecutar este trabajo de lote Aplicar, asegúrese de definir el número de subprocesos en un número que no supere el número de subprocesos soportados por el trabajador de grupo de subprocesos. Al hacerlo, los subprocesos "excedentes" esperarán a que finalice el número de subprocesos soportados, lo que eliminará el beneficio del procesamiento de iteración.

El siguiente diagrama es la parte del ciclo de vida de la transacción de migración que pertenece al paso Aplicar que ilustra los puntos de arriba.

Ciclo de Vida de Aplicación de Transacción de Migración

Si al final del proceso Aplicar del nivel de transacción, hay transacciones con error (y, por lo tanto, aún hay objetos con el estado de error), un usuario deberá revisar los errores y determinar cómo solucionarlos. Consulte la sección Resolución de Errores para obtener más información.

Resolución de Errores

Como se menciona en las secciones anteriores, se pueden recibir errores después de que se ejecuta el proceso Aplicar Objetos. Si el número de registros en estado de error está por debajo de cierto límite (y el trabajo de lote de monitoreo de juego de datos se envía para ejecutar los algoritmos de monitoreo) el sistema pasará automáticamente el juego de datos a Aplicar Transacciones. Si el trabajo de lote de monitoreo no se ejecuta o si el número de objetos en estado de error excede cierto límite, el usuario debe tomar la decisión después de visualizar los errores en la zona Objetos en Estado de Error en el portal de Importación de Juego de Datos de Migración.

  • Si los errores parecen estar relacionados con dependencias, el usuario podrá decidir si permitir que "las transacciones apliquen los objetos" y pasar el juego de datos al estado Aplicar Transacciones, como se describe arriba.

  • Si los errores parecen estar relacionados con un problema externo que se puede resolver manualmente, el usuario podrá elegir solucionar el problema y volver a llevar a cabo el paso Aplicar Objetos.

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

Después del paso Aplicar Transacciones, si aún hay errores, un usuario deberá revisar los registros y determinar cómo proceder.. Los errores se ven en la zona de Transacciones con Error, en el portal Importación de Juego de Datos de Migración.

  • El usuario podrá decidir si rechazará uno o más objetos para removerlos de la migración.

  • El usuario podrá resolver manualmente un problema externo a la migración y, a continuación, decidir llevar a cabo una de las siguientes acciones:

    • Volver a realizar el paso Aplicar Objetos. Esto se recomienda si hay una gran cantidad de Objetos que aún tienen el estado de error y no se espera una gran cantidad de dependencias. Los beneficios de ejecutar múltiples subprocesos de Aplicar Objetos, garantizará que el proceso se ejecute de manera eficaz.

    • Volver a realizar el paso Aplicar Transacciones.

Dado que los objetos y las transacciones tienen el estado Error de Aplicación, para "reintentar" el paso Aplicar después de solucionar manualmente un error, el sistema deberá mover los registros nuevamente al estado que les permite ser seleccionados por el proceso Aplicar correspondiente. Para los objetos de migración, se deben mover los registros nuevamente al estado Aprobado. Para las transacciones de migración, los registros se deben mover nuevamente al estado Listo para Aplicar. En los siguientes puntos, se describe la lógica de Reintentar para los objetos de migración.

  • Si un usuario decide Reintentar Objetos (mediante el botón de acción que se encuentra en la página Importación de Juego de Datos de Migración), el juego de datos pasa al estado Reintentar Objetos. En este punto, se debe ejecutar el monitoreo del Objeto de Migración.

  • El monitoreo de objetos en el estado Error de Aplicación detecta que el juego de datos está en el estado Reintentar Objetos y, de esa manera, se activa la transición nuevamente al estado Aprobado.

  • El paso siguiente es la transición del juego de datos del estado Reintentar Objetos al estado Aplicar Objetos. Esto se puede realizar manualmente o mediante la ejecución del proceso de monitoreo de Importación de Juego de Datos de Migración.

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

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

  • Si un usuario decide Reintentar Transacciones (mediante el botón de acción que se encuentra en la página Importación de Juego de Datos de Migración), el juego de datos pasa al estado Reintentar Transacciones. En este punto, se debe ejecutar el monitoreo del Transacción de Migración.

  • El monitoreo de transacciones en el estado Error de Aplicación detecta que el juego de datos está en el estado Reintentar Transacciones y, de esa manera, se activa la transición nuevamente al estado Listo para Aplicar.

  • El paso siguiente es la transición del juego de datos del estado Reintentar Transacciones al estado Aplicar Transacciones. Esto se puede realizar manualmente o mediante la ejecución del proceso de monitoreo de Importación de Juego de Datos de Migración.

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

La lógica de reintento también se puede aplicar al realizar la transición entre Aplicar Objetos y Aplicar Transacciones en función de la presencia de errores. El siguiente escenario realza este punto.

  • Después del paso Aplicar Objetos, habrá objetos en Error de Aplicación. El juego de datos pasa a Aplicar Transacciones, y el paso Aplicar se realiza en el nivel de transacción.

  • Después del paso Aplicar Transacciones, habrá transacciones en Error de Aplicación.

  • El usuario elige si desea aplicar objetos nuevamente (haciendo click en Reintentar Objetos). En este punto, se describen los pasos descritos anteriormente para reintentar objetos.

  • Después de aplicar objetos, el usuario puede elegir si desea reintentar objetos nuevamente (tras corregir los errores si corresponde).

  • En algún punto, el usuario realizará la transición a Aplicar Transacciones nuevamente. Si hay transacciones en Error de Aplicación, el sistema pasará el juego de datos automáticamente a Reintentar Transacciones, y se seguirán los pasos descritos anteriormente para reintentar transacciones.

Finalización del Paso Aplicar

Una vez que todos los objetos de migración de una transacción de migración están en el estado final (Aplicado, Rechazado o No se Puede Aplicar), la transacción de migración pasa al estado Aplicado. Una vez que todas las transacciones de migración están en el estado Aplicado, el registro de Juego de Datos de Migración pasa al estado Finalizado y se finaliza la importación.

Nota: Para revisar el ciclo de vida completo de cada registro, consulte el separador Objeto de Negocio: Resumen de los metadatos de la aplicación para los objetos de negocio de 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).