G3/migracion/3.10.0/migracionG2G3Instructivo

<< Volver



MIGRACION GUARANI 2 - GUARANI 3



Consideraciones Iniciales


El proceso de migración de SIU-Guaraní 2 a SIU-Guaraní 3 se produce a medida que se desarrollan los módulos en SIU-Guaraní 3. Hasta el momento se han desarrollado los scripts de migración de los módulos: datos generales, personas, datos censales, propuestas, planes, calendario académico, docentes, matricula, cursadas, promociones, exámenes, actas y equivalencias.
Estos procesos se encuentran en etapa de testeo, por lo que su publicación tiene como objetivo que las instituciones puedan realizar pruebas con sus bases de datos e informarnos si detectan problemas o casos no contemplados.


Requisitos necesarios para la migración:
* Base de datos de Guaraní 2 a migrar; la misma debe ser versión 2.8.
* Base de datos de Guaraní 3 versión 3.9 instalada (instructivo de instalación).
* Herramienta de migración Pentaho Data Integration (Kettle) instalada y configurada (instructivo de instalación).
* La URL de descarga es:

https://colab.siu.edu.ar/svn/guarani3/nodos/<nodo_institución>/migracion/trunk/3.9.0

Se debe reemplazar <nodo_institución> por la Institución que se encuentra realizando la instalación.



El proceso de migración se separa en dos partes:
1) Pasaje de una base Guaraní 2 de Informix a un motor Postgresql.
2) Una vez que la base de Guaraní 2 se encuentra en postgresql, se procede a pasar los datos del modelo de datos de Guaraní 2 al modelo de datos de Guaraní 3.

1) Pasaje de una base Guaraní 2 de Informix a un motor Postgresql.


El proceso que se describe a continuación pasa una base de datos de Guaraní del Motor Informix a un esquema de una Base de Postgres. Se hace una copia de la base de Guaraní.
La base de Guaraní 2 se creará en el motor Postgresql en un esquema llamado mig.

1.1) Abrir el trabajo 01_IFX2PG\ifx2pg.kjb

source:/trunk/img/mig5.png

1.2) Crear la conexión a la base de informix


source:/trunk/img/kettle.nueva_conexionifx.png

source:/trunk/img/mig6.png

1.3) Crear la conexión a la base de postgres

source:/trunk/img/kettle.nueva_conexionpg.png

source:/trunk/img/mig7.png

1.4) Compartir ambas conexiones para que se repliquen en los diferentes scripts.

source:/trunk/img/kettle.compartir.png

No se pasan todas las tablas de la base de datos.

Las tablas que comienzan con el prefijo descrito a continuación no se pasarán a la base de datos a crearse en Postgres:

source:/trunk/img/mig4.png

De ser necesario, el script que se debe personalizar es script_1.sql. Ahí se definirá qué tablas pasar al motor postgresql.

1.5) Ejecutar el trabajo

source:/trunk/img/mig3.png

El pasaje de una base puede demorar aproximadamente 40 minutos.

Si se desea ejecutar el trabajo (del paso de la base Guaraní 2 de informix a posgresql) desde la línea de comando (consume menos recursos, se recomienda para bases medianas o grandes):
path\pentaho\pdi-ce-4.0.1-stable\data-integration>Kitchen.bat /file:"pah\ifx2pg.kjb" > ifx2pg.log

2) Migración de datos de la base de Guaraní 2 a Guaraní 3

Una vez que la base de Guaraní 2 se encuentra en postgresql, se pasan los datos del modelo de datos de Guaraní 2 al modelo de datos de Guaraní 3. Los scripts se ejecutarán con la siguiente secuencia:

2.1) Pre Controles

Ejecutar el archivo 02_Modulos\00_Precontroles\Precontroles.jkb.
Este script ejecutará los precontroles de todos los módulos.
Generará una planilla de cálculo por cada módulo en la carpeta 02_Modulos\Precontroles_excel.
El archivo generado mostrará los resultados de los precontroles, aquellos registros que no cumplieron con los controles deben ser corregidos antes de migrar dicho módulo.

2.2) Tablas de conversión de PKs

Ejecutar el trabajo 02_Modulos\01_TablasConversionPK\cnv_pk_tablas.kjb.
Se crearán todas las tablas de conversión de PK que se utilizarán durante el proceso de migración.

source:/trunk/img/mig2.png
Detalle de las tablas q se migran x conversion de pk


2.3) Migración de Módulos

El resto de los módulos tienen la misma estructura de carpetas:

  • 01_Pre_Controles
  • 02_Migracion
  • 03_Pos_Controles.

source:/trunk/img/mig_estructura_modulos2.png

Por cada uno de los módulos debe ejecutarse:

2.3.1) De la carpeta 02_Migración el trabajo que la misma contiene: mig_Generales.kjb, mig_Personas.kjb, etc

2.3.2) Una vez finalizada correctamente la migración del módulo, de la carpeta 03_Pos_Controles debe ejecutarse el trabajo que contiene: posctrl_Generales.kjb, posctrl_Personas.kjb, etc. La ejecución de esta tarea generará una planilla de cálculo por cada módulo en la carpeta Postcontroles_excel. El archivo generado mostrará los resultados de los postcontroles, los registros que aparecen con la palabra ERROR deben ser analizados caso por caso.


Los precontroles no deben ejecutarse ya que fueron ejecutados en el primer paso.

Es importante respetar el orden de los módulos.

CONTRASEÑAS: Se migran las claves tal cual están en g2 y luego hay que correr un php que hace una nueva encriptación:

guarani/lib/toba/bin$ ./toba proyecto migrar_claves -i desarrollo -p guarani


Como se modifican todos los valores de las claves, a toba se le deja la contraseña "toba" pero si era otra la contraseña utilizada se debe volver a cambiar la misma.

3) Migración de N Bases G2 a G3

Para posibilitar la inserción de datos de varias bases de datos de G2 en una unica base de G3 se agregaron al proceso de migracion dos modulos:
05_Tablas_Comunes: En el mismo se hace un control previo al comienzo del proceso, con el fin de verificar la existencia de datos en algunas tablas de G3 y evitar duplicados. Después de correr los scripts de este modulo, se genera un Excel en la carpeta ‘precontroles_excel’ con los errores encontrados; hay que verificar los valores de los campos existe y migrar de algunas tablas para decidir que hacer.
El campo existe se utiliza para indicar si el registro ya se encuentra en la tabla de G3.
El campo migrar se utiliza como marca para definir si el mismo debe insertarse en G3.

80_Controles_finales: poscontrol con datos a verificar y actualizar.

Tablas que se verifican:

Tabla Chequeo Accion Existe/Migrar
mdp_personasse verifica si existe la misma persona por tipo_documento + nro_documentoSi existe NO SE MIGRA, se setea el nro de persona de G3existe=1/migrar = 0
sga_docentesse verifica si existe la misma persona y legajoSi existe NO SE MIGRA, se setea el nro de persona de G3Existe=2 /Migrar=0
se verifica si existe el legajo en otro docenteSe genera el legajo con el formato ‘D’+ legajo_G2existe=1
se verifica si existe la persona con otro legajoexiste=3
sga_elementosse verifica si existe la misma materia y nombreSi existe NO SE MIGRA, se setea el cod de materia de G3existe = 2 / migrar = 0
se verifica si existe el codigo en otra materiaexiste = 1
se verifica si existe la materia con otro codigoexiste = 3
sga_periodos_genericosse verifica si existe existe = 1
sga_tipos_ingresose verifica si existeexiste = 1
sga_requisitosse verifica si existeexiste = 1
sga_propuestasse verifica si existeSi ya existe en G3 se puede poner el id que corresponde. planes y versiones se migranexiste = 1
sga_certificadosse verifica si existeexiste = 1


Campos ‘existe’ y ‘migrar’ - Valores posibles

Tabla Campos Valores
mdp_personasExisteValores: 1 = Existe la persona por su "pais nacimiento + tipo documento + nro documento".
0 = No existe (default)
Migrar1 = La persona se migra a G3. (default)
0 = La persona no se migra a G3. Se debe reemplazar el campo "persona" por el id correspondiente en G3 (mdp_personas.persona)
migrar_datos_censalesSolo tiene sentido evaluar este campo migrar = 1. El técnico deberá decidir que hacer con datos censales.
1 = Se pasan los datos censales. Si existe = 1, entonces los datos censales se borran y se registran los datos censales de esta persona en esta base que se esta migrando.(default)
0 = No se pasan los datos censales de la persona de esta 2da/3er... Base de G2.
sga_docentesexiste0 = No existe ni la persona ni el legajo en G3 (default)
1 = Existe mismo legajo en otra persona (¿Se permite el mismo legajo docente en diferentes personas?)
2 = Existe mismo legajo en la misma persona (por tipo y nro de DNI) Aca no deberia migrarse. Se registra el "docente" con el existente en G3
3 = Existe la persona con otro legajo en G3 (¿Se permite un docente con mas de un legajo?)
migrar_docente1 = Se migra el docente / 0 = No se migra el docente y hay que reemplazar el valor de "docente" por el id de G3. (default 0)
sga_elementosexiste 0 = No existe la actividad, se migra. (default)
1 = Existe la actividad. Analizar si se migra o no.*
migrar 1 = Se migra. (default)
0 = No se migra, debe reemplazarse el campo "elemento" por el que existe en G3
codigo_nuevo Por si se quiere reemplazar el codigo actual de G2 por un nuevo codigo al migrar a G3 (solo cuando existe = 0)
sga_periodos_genericosexiste 0 = No existe el requisito, se migra
1 = Existe el periodo_generico. Analizar si se migra o no.*
migrar1 = Se migra.
migrar0 = No se migra, debe reemplazarse el campo "periodo_generico" por el que existe en G3
sga_tipos_ingresoexiste0 = No existe el tipo de ingreso, se migra
1 = existe el tipo_ingreso. Analizar si se migra o no.*
migrar1 = Se migra.
No se migra, debe reemplazarse el campo "tipo_ingreso" por el que existe en G3
sga_requisitosexiste0 = No existe el requisito, se migra
1 = Existe el requisito. Analizar si se migra o no.*
migrar1 = Se migra.
0 = No se migra, debe reemplazarse el campo "requisito" por el que existe en G3 (sga_requisitos.requisito)
sga_propuestasexiste0 = NO EXISTE la carrera en G3. Se migra
1 = EXISTE la carrera en G3. NO SE MIGRA.(Se la busca por el campo "codigo").Se debe setear el dato de sga_propuestas.propuesta que existe en G3 en el campo "propuesta" de esta tabla.*
migrar1 = Se migra.
0 = No se migra, debe reemplazarse el campo "propuesta" por el que existe en G3
codigo_nuevoPor si se quiere registrar la carrera con un nuevo codigo
sga_certificadosexiste0 = NO EXISTE el certificado (titulo) en G3
1 = EXISTE el certificado en G3 (sga_certificados.certificado)
migrar1 = Se migra.
0 = No se migra, debe reemplazarse el campo "certificado" por el que existe en G3 (sga_certificados.certificado)



* IMPORTANTE: Estos casos deben chequearse inmediatamente despues de correr el modulo 'Tablas comunes'. Si el proceso encuentra datos que ya existen en G3, seteara el campo existe en '1' y el campo migrar en '0'. Queda a criterio de la Universidad habilitar o no la migracion de estos datos, asignando un '1' al campo 'migrar' y los codigos nuevos a insertar en G3 en las tablas que asi lo permiten.


<< Volver