Mayo 2012

 Contexto General  Arquitectura  Procesos del Sistema  Integraciones  Operación del Sistema  Requerimientos del Sistema  Check List de Diagnostico  Control y Monitoreo  Tabla de Control Temario

Nombre del Proyecto Customer Data Delivery (CDD) Patrocinador Usuario LíderCynthia Rivera Jefe de Proyecto LANAna Virginia Miranda Jefe de Proyecto FocusGastón Navea Contexto General  Situación Actual Durante el 2012, LAN cambiará su actual proveedor de Host “Resiber – Amadeus” por “SABRE”, cambio que implica a nivel tecnológico, tocar gran parte de la plataforma IT de la compañía. Dado lo anterior, nace el proyecto “Customer Data Delivery (CDD)”, con el fin, de disponibilizar a la compañía, la información de gestión asociada a reservas y tickets, enviada por su nuevo proveedor “SABRE”

 Módulos del Sistema Las dependencias internas dentro del Sistema son dadas de la siguiente manera: CDD, CDDTD, CDDFDM, CDD_EPR, CDD_DEL_HIST Arquitectura

5  Componentes del Sistema A continuación se enumeran las siguientes componentes utilizadas por el sistema: DataStage: basada en Job Control, Sequences, Jobs, rutinas y parámetros globales. Unix: basada en Shells y archivos de configuración. Base de datos: basada en tablas y procedimientos almacenados Arquitectura

 CDD (Carga Modelo CDD Oracle) Proceso que permite cargar al modelo Oracle CDD, toda la información relacionada a las Reservas y Ticket del Pasajero desde los archivos Planos generados y enviados por GDS SABRES de Forma diaria, Este proceso validad tanto la consistencia y la estructura de la información entregada, como por ejemplo: ◦ No considerara (en el modelo final de carga) las reservas, que le falte información definida primordial para las Carga (Llaves) ◦ En algunos Casos, no considerara información que tenga inconsistencia con los tipos de Datos definido (si se espera un número no puede venir letras, etc. ) La idea de esta validaciones, es disponer a los otros proyecto como BPNR (Bajada PNR) de información consistente para sus procesos Info.: Este Proceso esta asociado a distintos modos de carga que permitirán en casos excepcionales, reprocesar, recargar la información para uno o mas periodos según se determine 6 Procesos del Sistema

 CDDTD (Carga Modelo WRK Teradata) Proceso que permite trasvasijar desde el modelo Oracle CDD, toda la información relacionada a las Reservas y Ticket del Pasajero a nuestro modelo Teradata (WRK), Como en el proceso anterior, se realizaron las validaciones necesarias sobre la información de Reserva y Ticket, solo se realiza la carga masiva desde un modelo a otro Info.: Este Proceso esta asociado a distintos modos de carga que permitirán en casos excepcionales, reprocesar, recargar la información para uno o mas periodos según se determine. 7 Procesos del Sistema

 CDDFDM (Carga Modelo FDM Teradata) Proceso que permite llevar desde el modelo Teradata (WRK), toda la información relacionada a las Reservas y Ticket del Pasajero a nuestro modelo Teradata (FDM), a diferencia del proceso anterior, en este nuevo modelo (FDM) se almacenara la historia de la reserva, manteniendo la ultima foto de esta o incorporando las nuevas reservas generada. Info.: Este Proceso esta asociado a distintos modos de carga que permitirán en casos excepcionales, reprocesar, recargar la información para uno o mas periodos según se determine. 8 Procesos del Sistema

 CDD_DEL_HIST (Borrado del Modelo Oracle) Proceso que Elimina la historia de las carga realizada, este proceso permite por medio de un parámetro ingresar los días que se desea mantener de Historia, es decir, si el parámetro indica 4 días, desde el día de proceso (10), se protegen los 4 días y se eliminara el resto de las cargas realizadas. 9 Procesos del Sistema

 CDD_EPR (Carga Oracle del Employee Profile Record) Proceso que permite cargar al modelo Oracle CDD, toda la información relacionada a los agentes de venta. 10 Procesos del Sistema

 Otras Funcionalidades La administración de Cada proceso tiene la capacidad de:  Reintentos: (Valor Paramétrico, default 3) de ejecuciones de Jobs una vez detectado la caída de alguno de ellos, si después de los reintentos definidos no logra auto recuperarse se da por abortado el Sistema.  Recuperación: Capacidad de Recuperar sólo los proceso abortados, para lo cual, se debe gatillar la misma Shell de Ejecución.  Adicionalmente la administración del sistema tiene la capacidad de: resetearse, generar mails automáticos dependiendo de cada Job control.  Cada Proceso se registrara las ejecuciones en las tablas de control internas como corporativa. 11 Procesos del Sistema

 Diagrama To BE de la Aplicación 12 Integración

 Ejecucion Norma y On-Demand Cada uno de los procesos mencionados Anteriormente, son ejecutados vía Shell (procesos Unix, que orquestan la ejecución de los Jobs). En CDD existen dos Shell, una que gatilla los procesos programados (Ejecuta_DSCDD.sh) y otra que gatilla los proceso On- Demand (Ejecuta_DSCDD_OnDemand.sh), entre ambas Shell la diferencia, esta que las procesos programados la Shell calculara automáticamente la fecha de proceso y para la ejecución On-Demand, se debe ingresar la fecha de proceso.  Ejemplo de Ejecucion Programada./Ejecuta_DSCDD.sh dscdd dscdd DSCDD CDD_00_Ejecuta_All NORMAL /dsdata/DSCDD/LOG PS_FECHA_DE_ARCHIVOS_CDD 0  Ejemplo de Ejecucion On-Demand./Ejecuta_DSCDD_OnDemand.sh dscdd dscdd DSCDD CDD_00_Ejecuta_All NORMAL /dsdata/DSCDD/LOG PS_FECHA_DE_ARCHIVOS_CDD 0 13 Operación del Sistema

 Hardware Como resultado de un proceso exhaustivo de QA sobre el sistema BPNR, se recomienda lo siguiente: 14 Requerimiento del Sistema

 Tips para correcto funcionamiento del sistema  A continuación se detalla los tips de buenas practicas: Se debe considerar que para una buena ejecución del proceso se debe encontrar 100% compilado y sin errores. Se recomienda que mensualmente se realice una compilación completa del sistema. Dado el gran volumen de archivos de procesamiento de datos a cargar diariamente, se recomienda contar con al menos un 20% ó 10% de espacio libre en Unix. Los Administradores de base de datos tanto de ORACLE, deben tener la preocupación de mantener los tablespaces asignados con espacio suficiente. Se recomienda realizar mantención semanal a las tablas de oracle con el objetivo de mantener los índices actualizados. 15 Check List de Diagnostico

 Tabla de Control ◦ Ejemplos de cómo se visualizan los registro procesados en la tablas de control CDD, esta tabla registra para ambos procesos sea este Proceso para el Modelo Oracle y Teradata ◦ Oracle ◦ Teradata 16 Control y Monitoreo

 PREGUNTAS ¿ ? 17 Fin Presentación