Migración de un dossier

Etapas principales de la migración

Las etapas para migrar un dossier de una versión mayor a otra son:

• Los controles premigración en el dossier de origen. Estos controles se pueden llevar a cabo sin detener la explotación de Sage X3.
• La instalación de la Versión 11 en un entorno dedicado o la actualización de un entorno ya existente.
• La extracción de los datos a migrar del dossier de origen y, posteriormente, la reintegración de dichos datos (hay que detener la explotación hasta que acabe la migración). Los datos de los dossieres de menor tamaño se extraerán en un formato "plano" y los de mayor volumen con herramientas de extracción de bases de datos.
• La revalidación del dossier en el entorno de la Versión 11. Esta validación se puede segmentar en varias etapas con la parametrización de planes de migración. Si el dossier no es de gran tamaño, no es muy útil definir planes de migración. Lo es cuando hay que ejecutar los procesos de transferencia de forma paralela (para aprovechar la potencia de un servidor multiprocesador) y controlar su encadenamiento con puntos de recuperación.
• Los controles posmigración. Se trata principalmente de verificar y adaptar las parametrizaciones.

El resto de la documentación describe todas las etapas.

Etapas premigración

Las etapas de premigración se lanzan en el entorno de salida y se pueden extender en el tiempo antes de la migración propiamente dicha. No es necesario detener la explotación.

Las etapas de premigración son:

1. En primer lugar, compruebe que el dossier de origen se encuentra al nivel mínimo de parche que se requiere para llevar a cabo una migración.

• Si va a migrar de la Versión 6 a la Versión 11, el nivel mínimo de parche que se requiere del dossier de origen es el parche 29.
  En la Versión 6, puede visualizar este nivel de parche mediante el menú ? Acerca.
• Para migrar de la Versión 7 a la Versión 11, el nivel mínimo de parche que se requiere del dossier de origen es el parche 9.
• Para migrar de la Actualización 8 a la Versión 11, el nivel mínimo de parche que se requiere del dossier de origen es el parche 3.
  En la Versión 7 y la Actualización 8, puede visualizar este nivel de parche mediante el menú Administración > Información de la versión (a continuación, haga clic en un dossier de la tabla para acceder al detalle).
• Para migrar de la Actualización 9 a la Versión 11, no se requiere ningún nivel mínimo de parche.
• En Portugal, para migrar de la Versión 6 a la Versión 11, hay que seguir dos pasos: realizar una migración de la Versión 6 a la Actualización 8 y, después, otra migración de la Actualización 8 a la Versión 11.

2. A continuación, compruebe los requisitos previos funcionales para el proceso de migración. Estos requisitos se describen en la documentación dedicada.

3. Ahora puede desencadenar los procedimientos automatizados en el dossier de origen, mediante los procesos que comienzan por UU, lanzándolos con la función dedicada (EXETRT). Estos procesos se proporcionan, bajo solicitud, como un parche específico para la migración. Se entregan dos tipos de procedimientos:

• En primer lugar, procedimientos de control de los datos del dossier de origen. El resultado de este lanzamiento puede poner de manifiesto errores o incoherencias que hay que corregir antes de lanzar la migración. Esta fase de control se puede prever varias semanas antes de la migración para disponer de tiempo suficiente para corregir los datos. No obstante, habrá que lanzarla de nuevo para comprobar que todo está correcto antes de la transferencia. Estos procedimientos se enumeran en la documentación Lista de los procedimientos de migración por módulo.
• En segundo lugar, procedimientos opcionales de alimentación, que vuelven a validar algunas tablas añadiendo y alimentando campos adicionales. Como estos procedimientos son independientes, también se pueden prever varias semanas antes de la migración (se puede retomar la explotación en cuanto se añadan los campos). El objetivo de estos procedimientos es acelerar en gran medida las etapas de la migración propiamente dicha. Sin embargo, no son necesarios para conseguir un buen funcionamiento de los procedimientos de migración. Estos procedimientos se enumeran en la documentación Lista de los procedimientos de migración por módulo.

Copia de los datos y ajuste de los parámetros del dossier

Esta etapa corresponde al inicio de la transferencia. En este momento, hay que detener la explotación operativa de la solución. Se retomará cuando acabe la migración.

Se divide en cuatro fases:

• extracción de los datos del dossier a migrar:
• extracción en formato "plano" para los datos de los dossieres de menor volumen. Para ello, utilice la función de extracción, que crea los ficheros en el directorio SVG por defecto.
• extracción de bases de datos para los dossieres de mayor volumen (el formato depende de la base de datos y de la herramienta que se utilice),
• copia de los ficheros del dossier a migrar en la solución de la Versión 11,
• creación de un dossier de copia para la arborescencia del dossier en el nuevo entorno de la Versión 11 e importación de los datos exportados al nuevo entorno,
• creación de la ficha de dossier en el entorno de la Versión 11. Si la importación se ha realizado a través de la consola, la ficha del dossier se crea automáticamente. Si la importación se ha realizado con herramientas de bases de datos, habrá que crear la ficha del dossier manualmente después de la importación.

Puede agrupar estas etapas en una sola. Para ello, utiliceel asistente de importación a distancia que hay disponible en la consola de configuración SAFE X3.

Si hay que volver a lanzar el procedimiento a partir de la importación de los datos del dossier de migración, debe lanzar el proceso TRTMIGDEL para limpiar las tablas que almacenan el informe de migración.

Antes de revalidar los dossieres, hay que ajustar el valor de los códigos de actividad en la ficha del dossier. De esta manera, las parametrizaciones se ajustarán a la licencia 11 para, por ejemplo, establecer nuevas funcionalidades controladas por nuevos códigos de actividad.La ficha del dossier se creará o modificará conectándose al dossier Supervisor.
La nueva validación de los dossieres no se puede desencadenar sin esta actualización. En cuanto se lanza la validación, aparece un mensaje de error como recordatorio.

Revalidación del dossier

Mediante la transferencia de datos, la revalidación del dossier va a transformar la estructura del diccionario X3, luego de las tablas de parametrización y luego de las tablas de datos de la versión anterior para subirla al nivel de la Versión 11. Se desencadena con el botón Validacióndesde la gestión de dossieres.

Lleva a cabo la migración supervisor y operativa del dossier comparando los diccionarios de la versión anterior y la versión de destino.

Si se realiza una primera prueba de migración en un dossier que incluye desarrollos específicos y la migración puede detenerse por un error, el dimensionamiento por defecto de la variable global GTRALIG a 200 (por razones de optimización) no permite obtener la totalidad de las últimas operaciones realizadas antes de que se detuviera el sistema.
Hay que modificar temporalmente la fórmula de dimensión de la variable global GTRALIG con el valor 1. Después de la migración, hay que volver a introducir el valor 200.
¡Cuidado! Hay que desconectarse y volverse a conectar para que se tenga en cuenta este valor.

Etapas principales de la revalidación

La revalidación del dossier desencadena las siguientes etapas en el dossier a migrar:

• Depuración de ciertas tablas temporales o de acumulados, que se volverán a crear en fases posteriores. Las tablas supervisor que se ven afectadas por esta depuración son:
      ALSTRD
      ALISTER
      AWRKLOG
      AWRKLOGIND
      AWRKLOGMES
      ATMPTRA
  También se depuran otras tablas temporales funcionales (en Sage X3, estas tablas son : LABELPRN, PRTSCRWRK, BALANCE, BALANA, GLCONSO, BALCONSO, GAJOUSTA, FUP, FUPTOT, BATCH, TMPEXPENSE).
• Migración del diccionario de datos y de las tablas supervisor que se necesitan para el funcionamiento de la base de datos (conexión, gestión de usuarios, entorno de desarrollo y parametrización mínima). Una vez realizada la migración, aunque las tablas que incluyen los datos de aplicación del flujo aún estén vacías, en teoría puede conectarse.
• Migración funcional: en todas las tablas que experimenten un cambio de estructura, el procedimiento va a realizar los cambios pertinentes (si es necesario, asignando valores adecuados por defecto a través de procedimientos encadenados en etapas y fases). Esta es la parte más extensa de la migración, la que depende del volumen de los datos.
• Proceso de posmigración (principalmente resincronizaciones de las tablas de acumulados). Algunas de estas etapas se pueden aplazar, retomando la explotación, pero el software funcionará en modo degradado en la fase intermedia. Hay que pasar por todas las etapas para que la migración se considere completa.
• Supresión final de las tablas temporales. Esta fase es manual y, por razones de seguridad, se podrá aplazar hasta garantizar que todos los datos del flujo se han migrado correctamente.

Uso de los planes de migración

La migración funcional puede ser muy pesada cuando el dossier es de gran volumen. Además, algunas de las tablas actualizadas son potencialmente independientes y, por lo tanto, se pueden migrar en paralelo. Esto permitiría que las arquitecturas multiprocesador aceleraran esta fase.

Para planificar mejor esta migración, puede definir un plan de migración personalizado ANTES de lanzar la validación de los datos. Este plan de migración se describe en la función proceso de migración (llamada desde el dossier supervisor). Esta función permite definir las etapas, fases y procedimientos de la migración funcional y de supervisor. De manera más específica, los planes de migración corresponden a la definición de parámetros concretos de migración (dossier afectado, número de procedimientos que se pueden ejecutar en paralelo, política de encadenamiento de tareas, estado de ejecución). Los planes de migración se crean volviendo a copiar todos los elementos activos del procedimiento de migración. Este conjunto de procedimientos se proporciona en estándar, lo que permite encadenar por completo los procesos que ha realizado el software estándar en la fase de migración. Se da una breve descripción de estos procedimientos en un documento dedicado.

En este momento, se pueden definir procedimientos específicos a través de procesos complementarios en conformidad con la metodología definida en el siguiente anexo. Estos procedimientos específicos se insertarán correctamente entre los procedimientos estándar.

Una vez que se define un plan de migración, puede lanzarlo, interrumpirlo de forma temporal, reanudar su ejecución y visualizar su progreso.

Cuando el dossier no es de gran volumen y la migración no requiere una planificación particular, no es necesario crear un plan de migración. De hecho, si no hay ningún plan de migración definido, la validación del dossier crea uno automáticamente. A este plan de migración se le asignará el código del dossier, excepto si dicho código ya corresponde a un plan de migración que no se encuentra en estado En espera. Si es el caso, el plan se creará con un código predefinido: MIGmmddM##. mmy dd corresponden a los números del mes y el día de lanzamiento y ## es un número secuencial.

Sin embargo, si desea personalizar las opciones de encadenamiento de migración, puede crear un plan de migración cuyo código debe corresponder al nombre del dossier. Este plan se creará en el dossier supervisor antes de lanzar la validación del dossier. Si hay un plan de migración en estado En espera, se utilizará en la migración funcional del dossier.

 Los automatismos de validación del dossier nunca utilizarán un plan creado con un nombre diferente al del dossier a migrar. Un plan de ese tipo se limita a lanzamientos manuales.

Proceso operativo en un plan de migración

Los planes de migración se caracterizan por un código de dossier y cuatro parámetros:

• Un título,
• El número de procedimientos que se pueden lanzar de forma simultánea. Este número representa un posible máximo. Solo se lanzarán de forma simultánea los procedimientos que se puedan ejecutar en paralelo. Preste atención, ya que este número viene limitado por el número de tareas batch que se pueden ejecutar de forma simultánea (definido en la función de parametrización del servidor batch), limitado a su vez por la licencia del usuario.
• Un indicador que especifica si hay que lanzar automáticamente los procedimientos de forma encadenada según la lógica que define el plan. Si no es el caso, habrá que encadenarlos de forma manual.
• Un indicador que señala si hay que encadenar los procedimientos posmigración a la misma migración. Estas operaciones se describen a continuación.

Si el plan de migración se crea por defecto tras revalidar el dossier, se creará con los valores:

• Número de tareas simultáneascon el valor del parámetro NBRTACSIM o, si no existe, con el 2,
• Encadenamiento automático en Sí,
• Operaciones posmigración en Sí.

Puede modificar estos valores desde la función de control del plan de migración.

En la pantalla asociada al plan de migración, encontrará la lista ordenada de los procedimientos del plan. Hay botones que permiten controlar la ejecución del plan de forma global:

• lanzando la ejecución,
• suspendiendo el lanzamiento de nuevos procedimientos,
• interrumpiendo todos los procedimientos en curso,
• lanzando de nuevo la ejecución.

Cada línea del plan representa una etapa de la ejecución y se caracteriza por:

• el código del procedimiento y su descripción,
• la etapa y la fase de la que forma parte el procedimiento,
• el módulo funcional al que se asocia el procedimiento,
• el rango de ejecución.

Las etapas de la migración permiten dividir la migración funcional. Si no se termina un procedimiento vinculado a una fase determinada, no se pueden lanzar las siguientes fases. Las fases se asocian a las siguientes etapas:

• La etapa de inicialización es preliminar y es la primera que se ejecuta. Actualmente no se utiliza y permite la ejecución de procedimientos específicos antes de la misma migración.
• La etapa de tronco común permite migrar los datos que se utilizan en las siguientes etapas.
• La etapa módulo permite realizar las migraciones vinculadas a cada módulo funcional. Una operación de esta etapa está asociada a un módulo funcional: la asociación solo es informativa, no impone la ejecución. De esta manera, la migración de datos vinculados a módulos diferentes se puede ejecutar en paralelo si los datos se encuentran en la misma fase. El lanzamiento se llevará a cabo por orden de módulo y, luego, por rango de ejecución.
• La etapa posmigración permite realizar operaciones secundarias de sincronización o actualización que no son obligatorias para retomar el funcionamiento en modo degradado. Se puede utilizar, por ejemplo, para aplazar la migración de datos antiguos. Sin embargo, hay que tener en cuenta que, aunque no sea obligatoria para retomar la explotación, habrá que completarla en algún momento para que un dossier se considere completamente migrado. Estas operaciones posmigración se lanzan por defecto, pero son opcionales. Se enumeran en un párrafo dedicadodel anexo que describe los procedimientos de migración.

En una etapa, los procedimientos unitarios están organizados en fases y rangos.

• Dos procedimientos definidos en la misma fase se pueden ejecutar de forma simultánea y, por lo tanto, deben ser independientes. La asignación de un procedimiento estándar a una fase determinada no se puede cambiar. Hasta que no terminen todos los procedimientos de una fase, no se puede lanzar la fase siguiente.
• El orden de rango es un orden preferencial de lanzamiento, pero se puede cambiar al definir un plan, también para procedimientos estándar.

Depuración final de las tablas de movimiento

Esta fase es manual. Se desencadena ejecutando el proceso TRTMIGDEL desde la función de ejecución de proceso. Al ejecutarlo, se borran todas las tablas que contienen el código de actividad MIG.

Esta fase es irreversible, asegúrese con anterioridad de que los procesos de migración se han realizado correctamente.

Conservar las tablas temporales en el dossier no impide retomar la explotación, de modo que estas tablas se pueden almacenar en línea durante algunas semanas de explotación. De esta forma, en caso de que surja algún problema tras la migración, puede disponer de los datos originales con fines de comparación o análisis.

Ejemplo de secuenciación en la migración de flujos

Considerando las siguientes operaciones:

• en la etapa de inicialización, siete operaciones:
• IN1, IN2 en la fase 1 (rangos 3 y 7),
• IN3 y IN4, IN5 y IN6 en la fase 2 (y rangos sucesivos 1 3, 5 9),
• IN7 en la fase 3,
• en la etapa de tronco común, seis operaciones:
• TC1, TC2 y TC3 en la fase 1, con rangos 3, 6, 9,
• TC4 en la fase 2,
• TC5 y TC6 en la fase 3,
• en la etapa de módulo, cinco operaciones:
• la etapa MO1, en el módulo de Contabilidad,con la fase 2 y el rango 1,
• las etapas MO2 y MO3, en el módulo de Stocks, con las fases 1 y 2 y rangos 1 y 2, respectivamente,
• las etapas MO4 y MO5, en el módulo de Ventas, con las fases 1 y 2, respectivamente, y el rango 1,
• las etapas MO6 y MO7, en el módulo de Compras, con las fases 1 y 5, respectivamente, y el rango 1.

Imaginemos que el plan de migración se lanza con encadenamiento de tareas y un máximo de dos procedimientos simultáneos. El encadenamiento puede ser el siguiente:

• Los procedimientos IN1 y IN2 se lanzan en este orden.
• Imaginemos que el procedimiento IN2 termina primero. Hasta que no termine el IN1, no se puede lanzar otro procedimiento, ya que los siguientes se encuentran en una fase o etapa de rango superior.
• Cuando termine el IN1, se lanzarán los procedimientos IN3 y IN4 en este orden.
• Si el IN4 termina antes que el IN3, se lanzará el IN5. Si termina antes que el IN3, se lanzará el procedimiento IN6 y se ejecutará a la vez que el IN3.
• Cuando terminen los procedimientos IN3 y IN6 (y solo en este momento), la fase de inicialización estará completa.
• Ahora se pueden lanzar los procedimientos de la primera fase de la etapa Tronco común: primero los procedimientos TC1 y TC2, luego TC3, que se lanzará en cuanto termine uno de los dos procedimientos anteriores. Tendremos que esperar a que terminen los tres procedimientos TC1, TC2 y TC3 antes de lanzar TC4, que se ejecutará en solitario porque no hay más procedimientos en esta fase. A continuación, se lanzarán TC5 y TC6, que se ejecutarán en paralelo.
• Cuando terminen TC5 y TC6, podremos pasar a las tareas de la etapa de módulos.
• Primero se lanzarán los procedimientos MO2, luego MO6 (en orden, estos procedimientos se ejecutan en paralelo); después, cuando termine uno de los dos, el MO4, que es el siguiente en el orden fase/módulo/rango, se lanzará en paralelo con el procedimiento MO2 o MO6 que aún no haya terminado.
• Tendremos que esperar a que terminen los procedimientos anteriores para lanzar los procedimientos de la fase 2, MO1 y MO3. Cuando termine uno de los dos, se lanzará MO5. Después, esperaremos a que terminen todas las tareas anteriores.
• Por último, se lanzará MO7, el único procedimiento de la fase 5.

Verificación posmigración

En cuanto acabe la revalidación del dossier, este se puede utilizar sin restricciones (si se han aplazado algunas operaciones posmigración, sí puede haber algún tipo de restricción).

Solo queda verificar y adaptar algunas parametrizaciones funcionales, que se describen en los requisitos posteriores funcionales.