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.9.
* Base de datos de Guaraní 3 versión 3.10 instalada (instructivo de instalación).
* Herramienta de migración Pentaho Data Integration (Kettle) instalada y configurada (Instructivo de instalación).
* La URL de descarga de los scripts de migración de Guarani 2 a Guarani 3 es:
https://colab.siu.edu.ar/svn/guarani3/nodos/<nodo_institución>/migracion/trunk/3.10.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
1.2) Crear la conexión a la base de informix
1.3) Crear la conexión a la base de postgres
1.4) Compartir ambas conexiones para que se repliquen en los diferentes scripts.
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:
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
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.
Si el error es de tipo 'advertencia', no es necesario corregirlo, pero sí verificarlo. Si es de tipo 'error', debe corregirse obligatoriamente.
La corrección se podrá hacer sobre la base original de Guaraní 2 y luego volver a comenzar el proceso de migración, o bien sobre las tablas del esquema ‘mig’ de la base de Guaraní 3. Este esquema contiene una copia de la base de Guaraní 2.
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.
Detalle de las tablas que se migran por conversión 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.
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_personas | se verifica si existe la misma persona por tipo_documento + nro_documento | Si existe NO SE MIGRA, se setea el nro de persona de G3 | existe=1/migrar = 0 |
| sga_docentes | se verifica si existe la misma persona y legajo | Si existe NO SE MIGRA, se setea el nro de persona de G3 | Existe=2 /Migrar=0 |
| se verifica si existe el legajo en otro docente | Se genera el legajo con el formato ‘D’+ legajo_G2 | existe=1 | |
| se verifica si existe la persona con otro legajo | existe=3 | ||
| sga_elementos | se verifica si existe la misma materia y nombre | Si existe NO SE MIGRA, se setea el cod de materia de G3 | existe = 2 / migrar = 0 |
| se verifica si existe el codigo en otra materia | existe = 1 | ||
| se verifica si existe la materia con otro codigo | existe = 3 | ||
| sga_periodos_genericos | se verifica si existe | existe = 1 | |
| sga_tipos_ingreso | se verifica si existe | existe = 1 | |
| sga_requisitos | se verifica si existe | existe = 1 | |
| sga_propuestas | se verifica si existe | Si ya existe en G3 se puede poner el id que corresponde. planes y versiones se migran | existe = 1 |
| sga_ubicaciones | se verifica si existe | existe = 1 | |
| sga_certificados | se verifica si existe | existe = 1 |
Campos ‘existe’ y ‘migrar’ - Valores posibles
| Tabla | Campos | Valores |
| mdp_personas | Existe | Valores: 1 = Existe la persona por su "pais nacimiento + tipo documento + nro documento". |
| 0 = No existe (default) | ||
| Migrar | 1 = 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_censales | Solo 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_docentes | existe | 0 = 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_docente | 1 = 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_elementos | existe | 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_genericos | existe | 0 = No existe el requisito, se migra |
| 1 = Existe el periodo_generico. Analizar si se migra o no.* | ||
| migrar | 1 = Se migra. | |
| migrar | 0 = No se migra, debe reemplazarse el campo "periodo_generico" por el que existe en G3 | |
| sga_tipos_ingreso | existe | 0 = No existe el tipo de ingreso, se migra |
| 1 = existe el tipo_ingreso. Analizar si se migra o no.* | ||
| migrar | 1 = Se migra. | |
| No se migra, debe reemplazarse el campo "tipo_ingreso" por el que existe en G3 | ||
| sga_requisitos | existe | 0 = No existe el requisito, se migra |
| 1 = Existe el requisito. Analizar si se migra o no.* | ||
| migrar | 1 = Se migra. | |
| 0 = No se migra, debe reemplazarse el campo "requisito" por el que existe en G3 (sga_requisitos.requisito) | ||
| sga_propuestas | existe | 0 = 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.* | ||
| migrar | 1 = Se migra. | |
| 0 = No se migra, debe reemplazarse el campo "propuesta" por el que existe en G3 | ||
| codigo_nuevo | Por si se quiere registrar la carrera con un nuevo codigo | |
| sga_ubicaciones | existe | 0 = NO EXISTE la ubicacion(sede) en G3 |
| 1 = EXISTE la ubicacion en G3 (sga_ubicaciones.nombre) | ||
| migrar | 1 = Se migra. | |
| 0 = No se migra, debe reemplazarse el campo "ubicacion" por el que existe en G3 (sga_ubicaciones.ubicacion) | ||
| sga_certificados | existe | 0 = NO EXISTE el certificado (titulo) en G3 |
| 1 = EXISTE el certificado en G3 (sga_certificados.certificado) | ||
| migrar | 1 = 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.
