SAT-LIN009-IBM InfoSphere DataStage

Lineamientos IBM
InfoSphere DataStage
División de Tecnología
Subgerencia de Arquitectura
2021/01/26
TABLA DE CONTENIDO
1 Control del Documento .......................................................................................................................... 4
1.1 Historia de Cambios ...................................................................................................................... 4
1.2 Revisiones ..................................................................................................................................... 4
1.3 Referencias.................................................................................................................................... 4
2 Introducción ........................................................................................................................................... 5
2.1 Objetivo.......................................................................................................................................... 5
2.2 Alcance .......................................................................................................................................... 5
2.3 Público Objetivo ............................................................................................................................. 5
3 Conceptos Básicos ................................................................................................................................ 6
3.1 Glosario ......................................................................................................................................... 6
3.1.1 Jobs Paralelos ....................................................................................................................... 6
3.1.2 Jobs Secuenciales ................................................................................................................. 6
3.1.3 Links ...................................................................................................................................... 6
3.1.4 Proyecto ................................................................................................................................. 7
3.1.5 DataSet .................................................................................................................................. 7
3.1.6 Sequential File ....................................................................................................................... 7
4 Lineamientos ......................................................................................................................................... 8
4.1 Diseño ............................................................................................................................................ 8
4.1.1 Arquitectura de Infraestructura para los ambientes de Calidad y Producción ...................... 8
4.1.2 Patrones ETL permitidos en DataStage ................................................................................ 9
4.1.3 Proyecto ............................................................................................................................... 10
4.2 Desarrollo .................................................................................................................................... 11
4.2.1 Diseño del proceso .............................................................................................................. 11
4.2.2 Orden general de Construcción ........................................................................................... 11
4.2.3 Documentación de Jobs ...................................................................................................... 11
4.2.4 Parametrización de Job’s .................................................................................................... 12
4.2.5 Parametrización de valores de conexiones de BD desde los Job’s .................................... 13
4.2.6 Variables Globales Envió Correo ........................................................................................ 13
4.2.7 Variables Globales FTP ....................................................................................................... 13
4.2.8 Parametrización de rutas de archivos en los proyectos ...................................................... 14
4.2.9 Inclusión de parámetros a nivel de Stages ......................................................................... 14
4.2.10 Uso de Tablas Lookup ......................................................................................................... 15
4.2.11 Uso de Partitioning .............................................................................................................. 16
4.2.12 Uso de Columnas ................................................................................................................ 18
Lineamientos IBM InfoSphere DataStage 2 de 40

4.2.13 Uso de archivos DataSet ..................................................................................................... 18
4.2.14 Uso de archivos Sequential File .......................................................................................... 18
4.2.15 Importación Estructura de Tablas........................................................................................ 18
4.2.16 Importación Estructura de Tablas a Proyectos ................................................................... 18
4.2.17 Limpieza de Ejecución ......................................................................................................... 19
4.2.18 Tablas de Homologación ..................................................................................................... 19
4.2.19 Descripción de Objetos ....................................................................................................... 19
4.2.20 Manejo de Logs y Warnings ................................................................................................ 19
4.2.21 Fuentes de Datos No Formales ........................................................................................... 19
4.2.22 Conexiones a Bases de Datos ............................................................................................ 20
4.2.23 Manejo Parameter Set ......................................................................................................... 20
4.2.24 Uso de paquete Genérico .................................................................................................... 21
4.2.25 Volumetría y acción por realizar sobre la base de datos .................................................... 28
4.2.26 Inicialización de Jobs ........................................................................................................... 29
4.2.27 Aprovisionamiento de Recursos en Ambientes (Desarrollo, Calidad y Producción) .......... 29
4.2.28 Versionamiento DataStage .................................................................................................. 30
4.2.29 Rutinas aprobadas por Arquitectura .................................................................................... 31
4.2.30 Depuración ambiente de calidad ......................................................................................... 31
4.2.31 Exports y Despliegues desde ambiente de Desarrollo a otros ambientes .......................... 31
4.2.32 Lineamientos generales ...................................................................................................... 32
4.3 Nombramiento ............................................................................................................................. 34
4.3.1 Proyecto ............................................................................................................................... 34
4.3.2 Carpetas .............................................................................................................................. 34
4.3.3 Sequence Jobs .................................................................................................................... 35
4.3.4 Parallel Jobs ........................................................................................................................ 35
4.3.5 Links (enlaces)..................................................................................................................... 35
4.3.6 Procedimientos .................................................................................................................... 36
4.3.7 Variables de Proyecto ......................................................................................................... 36
4.3.8 Variables Globales .............................................................................................................. 36
4.3.9 Stages .................................................................................................................................. 36

1 CONTROL DEL DOCUMENTO
1.1 Historia de Cambios

Versión Fecha Modificación Elaborado por
1.0 04/04/2016 Creación Dirección de Arquitectura
1.1 05/12/2016 Actualización Dirección de Arquitectura
1.8 26/01/2021 Cambió de plantilla de lineamientos, adición de Hugo Andres Ramírez Sanclemente
definición de uso o no uso de los jobs genéricos,
adición de lineamientos para cargue
(insert/update) y adición de lineamiento para los
cargues a ODS.
1.2 Revisiones
Versión Revisado por Cargo/Área Fecha
1.0 Carlos David Bernal Pérez Arquitecto de Estrategia – Subgerencia de 2021/01/26
Arquitectura
1.3 Referencias
Título del Documento Ubicación en SharePoint Subgerencia de Arquitectura
Lineamientos IBM InfoSphere ../01.Gobierno/06.Lineamientos/ SAT-LIN009- IBM InfoSphere DataStage
DataStage

2 INTRODUCCIÓN
2.1 Objetivo
Como parte de la política del buen uso de los recursos y la estandarización de los desarrollos que se
realizan en cada una de las herramientas sobre las cuales se soportan los procesos de negocio llevados a
cabo al interior del Banco, este documento brinda las bases y lineamientos a considerar en cada una de
las implementaciones a realizarse sobre la herramienta ETL, llamada IBM InfoSphere DataStage.
2.2 Alcance
Definición de componentes, lineamientos de diseño y lineamientos de desarrollo de la herramienta.
2.3 Público Objetivo

Este documento está dirigido a los líderes técnicos y equipos técnicos que trabajen en implementar
soluciones basadas en procesos Batch.

3 CONCEPTOS BÁSICOS
3.1 Glosario
3.1.1 Jobs Paralelos
Este tipo de Jobs son los permiten realizar procesos de (ETL), pueden contener diferentes stage que
realizan las operaciones requeridas en el proceso de integración de datos. Se debe tener en cuenta que
los Jobs tienen stages de Origen de datos (entrada), stages para realizar las transformaciones necesarias
y stages para cargar el destino de datos (Salida). Los Jobs pueden tener varias entradas de datos y varias
salidas.
Origen de datos Transformación Destino de Datos
Ilustración 1 Ejemplo Job Simple
3.1.2 Jobs Secuenciales

Este tipo de Job permite la implementación de procesos más complejos, que pueden integrar los controles
de programación como condicionales y ciclos.
Los jobs secuenciales, se usan para especificar una secuencia de jobs paralelos o de servidor a ejecutar.
No contienen los stage que encontramos en los Jobs paralelos, que tienen funciones específicas ETL.
Ilustración 2 Job Secuencial
3.1.3 Links
Los enlaces (Links) unen los diversos stages de un job y se utilizan para especificar cómo fluyen los datos
cuando se ejecuta el job.
El tipo de link que utilice depende de si el link es de entrada o de salida, y de los stages que está enlazando.
Los job paralelos admiten tres tipos de links:

- Stream (flujo): estos links representan el flujo de datos de una etapa a otra. Los enlaces de flujo
son utilizados por todos los tipos de etapa.
- Referencia: estos links representan una tabla de búsqueda en los stages Lookup. Los enlaces de
referencia solo se pueden ingresar a los stages lookup y enviar la salida a otros stages.
- Links de rechazo: representan registros de salida que se rechazan porque no cumplen con un
criterio específico.
3.1.4 Proyecto
Los proyectos son una forma de organización para los diferentes procesos de integración de datos,
permiten agrupar definiciones de tablas, tipos de datos, archivos, Jobs y rutinas. Los proyectos pueden
contener uno o varios Jobs, todos los elementos se pueden agrupar de forma lógica y organizar en
carpetas.
Se puede definir seguridad a nivel de proyecto, teniendo en cuenta que solo los usuarios que estén
autorizados para el proyecto puedan acceder a los diferentes Jobs.
3.1.5 DataSet
Archivo físico que mantiene particionamiento y lectura múltiple.
3.1.6 Sequential File

Archivo Plano sin particionamiento. Puede ser visualizado por sistema operativo.

4 LINEAMIENTOS
4.1 Diseño
4.1.1 Arquitectura de Infraestructura para los ambientes de Calidad y Producción
• Se realizará balanceo a los nodos WAS desde el F5, este componente cuenta con la configuración
necesaria y además el proveedor del componente certifica que puede realizar estas funciones.
• Los servidores WAS se comunican con los servidores Engine.
• Para la administración de los nodos WAS, se realiza la instalación de “dmgr” activo pasivo en los
nodos de WAS, el “dmgr” tendrá un disco compartido con tecnología “GPFS”, en este disco solo
se instala lo referente al “dmgr” no se debe instalar producto.
• Teniendo en cuenta las características del producto, la comunicación a los diferentes repositorios
de metadatos, se realiza desde los servidores WAS teniendo en cuenta la configuración del
producto InfoSphere.
• El “clúster de datos” va a conectar a la basa de datos Stage, con el esquema “ADMSTAGE”, el cual
se tomará como un área temporal de trabajo.
• La capa de Engine, debe tener IP flotante y Host Virtual.
• Los nodos de Engine van a tener un Orquestador instalado en activo y otro en pasivo, en caso de
que el activo falle se moverán e iniciaran los servicios en el que está en pasivo.
• Se debe tener un disco compartido para la instalación entre los nodos de Engine.
• Por requerimientos del producto, los nodos de Engine deben tener instalados los clientes de las
diferentes tecnologías de bases de datos en caso de requerir acceso a las mismas.
• Por requerimiento del producto los nodos de Engine deben tener acceso a los servidores donde se
alojan las bases de datos de las diferentes fuentes y destino que se requiera en los procesos ETL.

4.1.2 Patrones ETL permitidos en DataStage
• E-T-L
Usado para realizar la extracción, transformación y cargue de información desde una fuente a un
destino final. La siguiente grafica presenta las etapas de este modelo.
Fuentes Transformación Destino
Cuándo utilizar este patrón.

• Solo se debe realizar la extracción de los campos requeridos en el proceso.
• Se deben aplicar la mayor cantidad de filtros para extraer solo información requerida.
• Siempre que un Job utilice stage adicionales al de carga y destino debe seguir este
patrón. Esto aplica cuando la información del origen y destino sufre procesos de
transformación o validación.
• El área para realizar transformaciones debe ser un archivo DataSet o la base de datos de
Staging
Ejemplo.
• E-L
Usado para realizar la extracción y cargue de información desde una fuente a un destino final. Este
modelo realiza la carga de la información al destino sin realizar ningún tipo de modificación o
validación.
La siguiente grafica presenta las etapas del modelo.
Fuentes Destino

• Cuando se realiza la extracción de la información y cargue sin utilizar stage diferentes al
de origen y destino. Esto aplica cuando la información del origen y destino no sufre
ningún proceso de transformación o validación.
Ejemplo.

• E-L-T
Usado para realizar la extracción, cargue de información y transformación en el destino final. La
siguiente grafica presenta las etapas de este modelo.
Fuentes Destino Transformación

• Este patrón de trabajo solo puede ser utilizado con autorización de arquitectura y se
evaluará si es necesario el uso.
4.1.3 Proyecto
1. Se creará un proyecto por sistema, contenido en el inventario de aplicaciones del Banco, que sea objeto
destino de procesos ETL.
2. Un proyecto contiene los Jobs que integran datos hacia la aplicación determinada por el nombre del
proyecto. Así, el proyecto PRY_ODS contendrá los desarrollos cuyo destino es el ODS.
3. Los desarrollos se agruparán en la carpeta Jobs del proyecto. Dentro de esta carpeta, se creará una
subcarpeta por sistema fuente de datos de los procesos ETL, o una subcarpeta por requerimiento,
dado por su CQ, en caso de que el proceso tenga varias fuentes.
4. Los proyectos Datastage deberán incorporar una estructura jerárquica para el almacenamiento del
proyecto en disco, los cuales estarán diferenciados por área temática que describa los distintos tipos
de usos:
dsdata
/workspace/ds/data/#NOMBREDEPROYECTO#/Entrada
/workspace/ds/data/#NOMBREDEPROYECTO#/Salida
/workspace/ds/data/#NOMBREDEPROYECTO#/LOG
/workspace/ds/data/#NOMBREDEPROYECTO#/DAT
/workspace/ds/data/#NOMBREDEPROYECTO#/Rutina
/workspace/ds/data/#NOMBREDEPROYECTO#/TMP
dsproject
/workspace/ds/project/#NOMBREDEPROYECTO#/
dsapp
/workspace/ds/app/#NOMBREDEPROYECTO#/SHL
/workspace/ds/app/#NOMBREDEPROYECTO#/SQL
/workspace/ds/app/#NOMBREDEPROYECTO#/CNF
/workspace/ds/app/#NOMBREPROYECTO#/PRG
Dónde:
/ds/data: Contendrá los datos temporales que requieren las ETLs para su funcionamiento.
/ds/project: Contiene los DSX del proyecto que corresponde a los códigos generados en DataStage.
/ds/app: las aplicaciones extras que usará el proyecto para funcionar correctamente, como son
llamadas a shell script, invocaciones de SQL, archivos de configuraciones y programas externos.
5. NOMBREDEPROYECTO: será una variable local del proyecto.
6. En la máquina se creará un directorio con el nombre del proyecto y dentro de esta se deben crear las
carpetas que se configuraron en la aplicación. (Data, Controls, Temp, etc.)
7. En la instalación de rutinas se deberá crear una carpeta con el nombre del módulo general y en ellas
se instalarán las rutinas que correspondan a este tipo de proyectos. Ver la siguiente figura:

4.2 Desarrollo
Para satisfacer los diferentes requerimientos del Banco en cuanto a procesos ETL y/o validación de calidad
de datos, se deben considerar los lineamientos de los siguientes numerales.
4.2.1 Diseño del proceso

Una vez identificados los requerimientos de integración de datos, y especificados en un documento, se
realiza el diseño, teniendo en cuenta los siguientes aspectos:
• Especificación de los sistemas y objetos de datos fuente y destino de los procesos.
• Configuración de las conexiones a los sistemas que contienen los objetos de datos de entradas y
salidas.
• Configurar los Stage de transformación.
• Utilizar enlaces para conectar los diferentes Stage.
• Cargar definiciones de tablas, según sea necesario.
• Cuando se requiera configurar las propiedades de los archivos de origen de datos.
• Cuando se requiera configurar las propiedades de archivo de destino de datos.
• Editar los stages de transformación según sea necesario, en función de sus tipos.
• Guardar y compilar el trabajo.
• Ejecutar y supervisar el trabajo.
• Revisar el registro.
4.2.2 Orden general de Construcción

Con el objeto de facilitar la lectura e interpretación de las construcciones. Todo Job y secuencia deberá ser
construido(a) con la siguiente orientación:
• Partiendo en el encabezado del extremo izquiedo y hacia la derecha.
• Siempre de arriba hacia abajo.
4.2.3 Documentación de Jobs

Todos los Jobs deben tener una anotación que contenga la siguiente información:
• Nombre del JOB
• Descripción
• Nombre del Desarrollador o del ultimo modificador
• Fecha de Modificación

La siguiente imagen presenta un ejemplo.
Nota.
Si en los stage tienen condiciones o características especiales estas se deben documentar en la
descripción general del mismo.
4.2.4 Parametrización de Job’s

Los Job Datastage deben ser construidos con una visión amplia de adaptación a los posibles escenarios
de ejecución. En la práctica esta forma de construir implica que los desarrolladores deben prestar especial
atención en aquellos aspectos que pueden hacer adaptable un Job, lo que implica es que estos deben ser
paramétricos.
Para facilitar la portabilidad de los Jobs, se exige que la construcción de Jobs sea paramétrico y adaptable
a nuevos escenarios, lo que implica en la practica el uso de parámetros de configuración para su ejecución.

Los parámetros usuales incluyen los valores (URI, usuario y password) para permitir la conexión a las
bases de datos de las diferentes aplicaciones origen y destino de los procesos ETL, valores para filtrar data
de las BDs, rutas y nombres de archivos, etc.
En los siguientes numerales expondremos la parametrización con variables globales para las acciones más
comunes en los Jobs.
Cualquier variable adicional a las definidas por arquitectura debe ser validada, documentada y justificada
por el proyecto, estas deben ser aprobadas por arquitectura y creadas por el administrador de la
herramienta.
A nivel de desarrollo, los Jobs pueden ser instanciados como bien sabemos, sin embargo, es muy complejo
identificar en el equipo de desarrollo los N Jobs con comportamientos iguales, para ser reutilizados, más
aún cuando en la mayoría de las ocasiones se cuenta con Metadata diferente entre los flujos entrantes.
Las funcionalidades propias del negocio que pueden definirse como reutilizables, por ejemplo,
administración de inconsistencias y/o rechazos, procesos de Reinyección o manejo de duplicados, pueden
ser construídas en Parallel Shared Containers y compartidos entre los diversos ambientes, la
implementación de cualquier funcionalidad reutilizable en un Parallel Shared Containers siempre deberá
ser aprobada antes por arquitectura.
4.2.5 Parametrización de valores de conexiones de BD desde los Job’s

Los Stages de conexión a las Bases de datos, normalmente requieren valores para la cadena de conexión,
usuario y password. Se requiere un set de estos valores por cada BD (sistema y ambiente) a la que se
requiere conectar desde la herramienta, por lo que esta información se almacena como variables de
ambiente en cada uno de los proyectos, en los diferentes ambientes, definidos en DataStage.
El formato de los nombres de las variables globales para los proyectos es:
Para la variable global de cadena de conexión
• VAG_Tecnología_URI_PrefijoSistema:
• ejemplos: VAG_ORA_URI_ADMSARC, VAG_ORA_URI_ADMODS, VAG_DB2_URI_ADMSIIF
Para variable global del usuario:
• VAG_Tecnología_USU_PrefijoSistema
• Ejemplos: VAG_ORA_USU_ADMSARC, VAG_ORA_USU_ADMODS, VAG_DB2_USU_ADMSIIF
Para variable global del Password del usuario:
• VAG_Tecnología_PASS_PrefijoSistema:
• ejemplos: VAG_ORA_PASS_ADMSARC, VAG_ORA_PASS_ADMODS,
VAG_DB2_PASS_ADMSIIF
Al momento de la instalación, se verificará la existencia de los parámetros que son requeridos por el
proyecto, teniendo en consideración el contenido de las variables, las cuales deben corresponder a las
configuraciones de los ambientes donde se va a ejecutar el proyecto.
4.2.6 Variables Globales Envió Correo

• VAG_SENDER_EMAIL_CAWA: cuenta cawa para envió de correo.
• VAG_SERVER_SMTP_EMAIL: Servidor SMTP para envió de correo.
4.2.7 Variables Globales FTP

Los valores de las variables cambian según el archivo de configuración del ambiente.
• VAG_WSFTP_USER: variable global usuario WSFTP esta configuración cambia según el
ambiente de ejecución (apl_datastage para desarrollo).
• VAG_WSFTP_PORT: variable global puerto WSFTP esta configuración cambia según el ambiente
de ejecución (22 para desarrollo).
• VAG_WSFTP_SERVER: variable global nombre del servidor remoto WSFTP esta configuración
cambia según el ambiente de ejecución (Xstabog15-400 para desarrollo).

• VAG_WSFTP_PASS: variable global clave usuario WSFTP esta configuración cambia según el
ambiente de ejecución.
4.2.8 Parametrización de rutas de archivos en los proyectos

• /workspace/ds/data/#NOMBREDEPROYECTO#/Entrada
• /workspace/ds/data/#NOMBREDEPROYECTO#/Salida
Aunque cada aplicación tiene una carpeta propia en el WS-FTP y en GoAnyWhere, ODI y DS compartirán
la carpeta dentro de WS_FTP y GoAnyWhere (/aplicaciones/apl_etl/), teniendo en cuenta la estructura de
almacenamiento que esta tiene, por ejemplo, en la subcarpeta de salida DS almacenará el archivo resultado
que sea requerido por cualquier otra aplicación.
• VAG_PATH_INPUT: Variable global con el repositorio de archivos que sirven de fuente o insumo
para los Jobs.
• VAG_PATH_OUTPUT: Variable global con el repositorio de archivos salientes o resultantes de
operaciones finales de los Jobs.
• VAG_PATH_TEMP: Variable global con el repositorio de archivos que sirven de áreas de trabajo
y descarga de temporales para los Jobs. Este directorio debe ser borrado con mayor frecuencia.
4.2.9 Inclusión de parámetros a nivel de Stages

En consideración a generar Jobs que sean dinámicos y fácilmente configurables, para garantizar así su
mantenimiento, se propone el empleo de un mecanismo de parametrización que permita manejar los Jobs
de manera dinámica.
La tarea de recuperación y entrega de los parámetros para la ejecución, deberá ser realizada por la función
RunJob la que deberá ser invocada desde un Batch Job.
Cada grupo de Job que se ejecute en forma conjunta deberán estar referenciados por un Job de secuencia
que contendrá la lógica de la secuencia de todos los Jobs en ejecución. Así toda secuencia Job, se debe
utilizar el Jobs Secuencial general para la administración de los parámetros requeridos por el Job a ejecutar.
El Batch Job realizará las siguientes tareas:
• Reconocerá los parámetros que estén definidos en el Job a ejecutar.
• Leerá desde el mánager los valores de parámetros de inicialización que han sido especificados.
• Invocará la ejecución del Job que se desea y controlará que se asignen los parámetros de
ejecución correspondiente.
• En caso de que el Batch Job invoque a un Job sequencer, este encadenará la ejecución de todos
los Jobs asociados a su definición, pasándole la información de los parámetros de conexión, que
cada Job requiera. Dentro del Job sequencer se deberán definir todos los parámetros necesarios
para la totalidad de Jobs involucrados

Cualquier parámetro específico a nivel de stage debe ser documentado y se deben generar el manejo del
error en caso de que este parámetro falte.
4.2.10 Uso de Tablas Lookup

El proceso de acceso a tablas Lookup, puede llegar a ser demasiado costoso en tiempo de ejecución,
dependiendo de qué tan robusta sea la fuente de datos. Esta problemática puede ser visible en procesos
de transformación que posee en múltiples fuentes Lookup remotas como puede ser un Oracle.
En estos casos se recomienda tener en cuenta lo siguiente:
• Liberar el motor de datos utilizando archivos HASH ordenados por los índices correspondientes.
• Para evitar múltiples accesos a un mismo repositorio se recomienda no usar un mecanismo de
lookup sino realizar estos “Cruces” usando la extracción inicial del proceso. En ciertos casos
puede ser recomendable utilizar esta táctica para pasar el esfuerzo de la validación al motor de
datos de instancia origen y no al motor del middleware.
• Cuando las consultas en el proceso de transformación son muy complejas, se recomienda
realizar un filtro previo donde se evalúen los datos rechazados, para excluirlos previamente de
las transformaciones.
• Cuando se emplee el Lookup a menos que sea del tipo Sparse, tener presente que la prioridad
en cantidad de registros para un óptimo rendimiento la tendrá el(los) Link de referencia, por ende,
si nuestra(s) referencia(s) posee cuantías de registros superiores a 400.000 no se deberá
emplear el LookUp como stage. No es relevante la cantidad de registros que transiten por el link
Stream, el uso o no, del stage Lookup dependerá siempre del volumen de nuestros links de
referencia. Como premisa se recomienda tener únicamente archivos tipo LookUp File Set o en su
defecto DataSets en las referencias, con cuantías de registros inferiores a los 400.000, que
permita a DataStage realizar búsquedas altamente eficientes sobre el link stream. Cabe recordar
que el LookUp mientras no sea del tipo Sparse, automáticamente realiza un Entire si la partición
no ha sido definida y se tiene dicha propiedad en Auto.

• Uso del Stage LookUp: este componente de gran utilidad nos permite realizar una o varias
búsquedas referenciales, en métodos que serían en terminología de Base de datos, tipo INNER,
LEFT y adicionalmente tipo Reject y por Rangos, con administración de rechazos y también
metodología Sparse. Debe ser empleado en el momento oportuno y teniendo en cuenta la
volumetría del o de los Links de referencia, es decir, se debe evitar usar este componente
cuando alguna de nuestras referencias supere los 500.000 registros, sin importar la cantidad de
registro en el link stream (principal). Así se podrán ejecutar búsquedas referenciales de una
fuente (principal) con cientos de millones de registros, sin problema alguno, siempre y cuando la
fuente de referencia (punteada) posea menos de 500.000 registros, ver imagen a continuación:
*Nótese en la imagen arriba que se cruzan 300 millones de registros (link principal/stream) con una
referencia de 300 mil registros (link reference), a una velocidad promedio de 900 mil registros por
segundo, se recomienda emplear siempre Entire en el link de referencia.
* El LookUp deberá emplearse en nuestros cruces con entidades MINOR, representando dicha
MINOR el link de referencia.
4.2.11 Uso de Partitioning

Nomenclatura básica:
1. AUTO
2. SAME
3. Reparticionamiento

A continuación, se listarán las características y los componentes más frecuentes empleados al interior de
Banco de Occidente y que requieren tener claro el concepto de particionamiento:
1. Tenga siempre como premisa: “si duda del método de particionamiento a emplear, deberá definir
(Auto) por defecto”, de esta forma DataStage será quien resuelva de forma acertada la
metodología de particionamiento, y evitar pérdida de registros al momento de hacer un cruce
entre fuentes, remover duplicados, calcular deltas y generar malos cálculos al momento de hacer
un agrupamiento u ordenando alguna fuente. Ver ejemplos a seguir:
Si duda del particionamiento emplee (Auto), como se muestra, note bien el recuadro en los links
de entrada al Stage, simbolizan el método de particionamiento Auto:
Si posee claridad sobre el particionamiento y la llave a emplear, particione los links de entrada a
los stages como Hash o Modulus por la misma llave que se hará el Join, ordenamiento o remoción
de duplicados; de esta manera DataStage no tendrá que hacer la gestión de selección automática.
Tenga en cuenta que se hace un Reparticionamiento cuando los links entrantes estén como se
muestra en la siguiente imagen:
*Nota: El punto 1. anteriormente descrito también aplica para otros stage, como por ejemplo el
Merge.
2. Siempre y cuando no se empleen Stages que requieran particionamiento específico, configure

sus Jobs conservando el particionamiento SAME a lo largo de los stages de su desarrollo, ver
imagen de ejemplo:
*Nota: Siempre y cuando el stage transformer se use de manera paralela, no será necesario
particionarlo, en caso se requiera ejecutarlo de manera secuencial, se recomienda particionar.

4.2.12 Uso de Columnas
En los procesos de transformación se deberán incorporar solo aquellas columnas de campos que serán
usadas efectivamente en estos procesos con el objetivo de proporcionar mayor claridad a los diseños. Los
proyectos deberán quitar la referencia a columnas sin uso, así como también la referencia a otros objetos,
como tablas, funciones, etc., que no estén siendo usados efectivamente en el flujo Datastage en
construcción.
Para brindar consistencia a la premisa y buena práctica que permite preservar el rendimiento óptimo de los
desarrollos, garantice siempre que las columnas que transfiere entre sus stages, sean las requeridas por
sus flujos de desarrollo, por ningún motivo conserve la metadata que no sea operativa.
4.2.13 Uso de archivos DataSet

Se deben generar con la extensión .ds, lo cual permite identificarlos plenamente como archivos de
almacenamiento que conservan distribución por Nodo. Para almacenamiento intermedio entre procesos.
No Usar si se desea revisar su contenido desde Sistema Operativo.
4.2.14 Uso de archivos Sequential File

Generación de Archivos de Rechazo, Archivos requeridos por los frentes como entrada o salida.
No Usar como Almacenamiento Intermedio.
4.2.15 Importación Estructura de Tablas

Toda creación de estructuras se debe realizar utilizando el Metadata Asset Manager para garantizar la
integridad. Se debe solicitar al administrador de componente la creación de la conexión a la base de datos
para realizar la ingeniería inversa de las tablas. El nombre de la conexión debe ser el mismo de la
Aplicación.
Ejemplo: FC_Activas, ODS
Todas las estructuras de tablas deben ser compartidas manejando las versiones respectivas.
4.2.16 Importación Estructura de Tablas a Proyectos

Todos los proyectos deben tener la estructura de tablas organizadas de la siguiente forma:
Carpeta principal: Definición de Tablas
Sub Carpeta Nivel 1: Base de Datos
Sub Carpeta Nivel 2: Tecnología
Sub Carpeta Nivel 3: Aplicación
Ejemplo:
Consideraciones:
• La tecnología debe estar acompañada de la versión.

• Si una aplicación maneja diferentes esquemas estos deben estar agrupados en la carpeta de
aplicación.
4.2.17 Limpieza de Ejecución

Los procesos Datastage que manejan información, deben en ocasiones almacenar datos localmente por
razones de procesamiento, y con el objetivo de acelerar los procesos de transformación. Se debe tener
siempre presente que esta información que pasa por el Job es temporal y que será refrescada en una
nueva ejecución siempre. Por esta razón el Job debe considerar, como parte de su procesamiento, la
limpieza de las áreas temporales de trabajo de manera que se logren liberar los espacios en disco que han
sido usados por parte del proceso de carga.
Se debe tener especial cuidado que la limpieza se produzca aun en condiciones de término inesperado del
Job y no solo en los casos de finalización con éxito.
4.2.18 Tablas de Homologación

En los procesos de homologación se deben tener en cuenta los lineamientos actuales para el manejo de
la tabla de homologación, si por algún motivo no se puede utilizar estas tablas se debe validar la excepción
con arquitectura y dejar toda la documentación pertinente del proceso especifico.
4.2.19 Descripción de Objetos

Los proyectos Datastage deberán estar documentados, incorporando descripciones en los campos de
comentarios proporcionados para el proyecto, así como para los objetos que forman parte de él. No podrá
haber campos, Job, funciones, parámetros, etc., sin su descripción.
4.2.20 Manejo de Logs y Warnings

No se aceptan desarrollos con warnings durante su ejecución, excepto aquellos que sean justificados y
manejados vía Message Handler, cualquier otro warning propio a la creación de los Jobs, deberá ser
corregido por el desarrollador.
Los Jobs deberán abortar tras un máximo de 50 warnings detectados en el periodo de ejecución.
Un máximo de 3 días estará disponible en ambiente de desarrollo y calidad para todos los Jobs.
Un máximo de una semana en logs estará disponible en ambiente de Producción para todos los Jobs.
Los warnings que no se puedan solucionar debido a la naturaleza de la tipificación del error en DataStage,
se almacenarán o agruparán en el message handler general, para lo cual será deber del equipo
responsable del desarrollo y paso a producción, notificar la adición de la excepción de el o los warnings al
message handler productivo.
4.2.21 Fuentes de Datos No Formales

Cuando hablamos de fuentes de no estructuras o no formales estamos mencionando todos aquellos casos
en que la carga es hecha desde un archivo plano o una planilla Excel como fuente de origen o fuentes no
establecidas como formales a nivel corporativo.
Pueden existir casos en los cuales la carga de datos debe hacerse usando este mecanismo, estos deberán
estar justificados por la naturaleza del negocio, para lo que existen condiciones que deben ser tenidas en
cuenta. Así, el uso de fuentes de datos no estructuradas podrá ser autorizado solo cuando se den TODAS
las siguientes condiciones:
• Este justificado por las condiciones del negocio del cual se está tratando.
• El formato de los archivos de carga este acordado con el responsable de negocio, lo que deberá
ser estático para permitir las cargas de datos en el tiempo.
• Existe un área responsable para la fuente de información de origen que se hará cargo de la
entrega de los datos y de las fallas de que estos puedan provocar al flujo.

• La inconsistencia de información pueda ser controlada a nivel de JOB, sea irrelevante o de bajo
impacto para el uso que se dará a los datos que están siendo procesados.
• No se requiere rigurosidad en los datos.
• Existe tolerancia a los errores que sean detectados con un bajo impacto en el proceso posterior.
4.2.22 Conexiones a Bases de Datos

Para la creación de conexiones a base de datos se debe solicitar la autorización a Arquitectura, con esta
autorización se debe realizar los siguientes pasos:
• Enviar correo Arquitectura solicitando autorización creación de la conexión a la base de datos.
• Con la autorización de Arquitectura solicitar la creación de la conexión al administrador de
componente.
• El administrador de componente realiza la gestión y validación de la conexión con el
administrador de plataforma, luego de realizar el proceso informa sobre la creación de la
conexión.
4.2.23 Manejo Parameter Set

Teniendo en cuenta las diferentes necesidades de manejar valores en parameter_set para cada uno de los
ambientes se define que el parameter set debe contar con 3 contextos los cuales deben ser ejecutados
con los valores correspondientes a cada uno de los ambientes.
Será responsabilidad del desarrollado el garantizar que los contextos del parameter_set sean los indicados
para cada uno de los Ambientes. Al momento de ejecutar el Job se debe definir cuál es el contexto que se
manejara.
El parameter set no debería tener valores default solo los datos que se manejen en los ambientes.
Las siguientes imágenes presentan la configuración básica de un Parameter Set.

Con los 3 contextos generados se puede ejecutar con WA o de forma manual indicando cuales son las
variables que se deben usar en cada uno de los ambientes y no se restringe a los desarrolladores o genera
carga operativa adicional para el banco.
Nota. Un parameter set puede tener valores default solo cuando haga referencia a una variable global y se
defina el valor con $PRODEF
4.2.24 Uso de paquete Genérico

Cada proyecto al interior de BOCC, posee en su repositorio la carpeta Jobs -> General, allí se encuentra
el Sequence de invocación genérica “SEQ_GEN_INVOCAR_PAQ_GENERICO”.
Este SEQ, se permite la ejecución de los paquetes generales ubicados en el proyecto

PRY_CTL_GENERAL: SEQ_CTL_CARGAR_TABLA Y SEQ_CTL_CARGAR_PLANO; de forma paralela.
TENGA PRESENTE QUE ESTÁ ROTÚNDAMENTE PROHIBIDO modificar el paquete genérico por parte
de los desarrolladores.
El uso del paquete genérico no es obligatorio para todos los casos y dependerá de si su uso agrega
complejidad y si aporta valor a la solución. En la tabla a continuación se define de manera general cuándo

debe usarse este paquete. Es importante aclara que la complejidad que se menciona a continuación es la
que agrega el uso de control cargue en estos procesos:
Origen Destino Requiere genérico Complejidad

Tabla Tabla No Baja
Tabla Plano Debe* Baja
Plano Tabla Debe* Baja
Plano Plano Debe* Baja
Excel Tabla Debe* Media/Baja
Tabla Excel Debe* Media/Baja
Tabla XML Debe* Media
XML Tabla Debe* Media
Tabla Planos(masivos) No se recomienda Media/Alta
***
Tablas - Origen Tablas - ODS No Media/Alta
Procesos personalizados No Alta
*Se debe usar para simplificar las funcionalidades del FTP, pero se podría sustituir por el stage propio de
la herramienta, siempre y cuando no se requiera cifrar/descifrar o comprimir/descomprimir.
***Se puede usar, pero no se recomienda si se requiere que la generación, cifrado, compresión y
transmisión de los planos masivos sea concurrente.
4.2.24.1 Uso de control cargue modelos tipo ODS

Debido a problemas presentados por el uso masivo del paquete genérico, se define no utilizar el genérico
para los cargues a ODS, en su lugar se propone el siguiente manejo para los cargues donde se reutilizan
múltiples objetos a lo largo del proceso:
Los procesos de cargue del ODS se deberán desarrollar de tal manera que las precedencias del proceso
se carguen en bloque, posteriormente se realizaran las transformaciones correspondientes y finalmente los
cargues. Para tener control de cuál proceso ya se ejecutó y poder reestablecer la ejecución desde el punto

en donde falló se define que se hará uso de las funcionalidades propias de datastage, en este caso se hará
uso de la propiedad checkpoint la cual permite reestablecer ejecuciones de proceso desde el punto donde
este falló. Para tal fin se debe mantener el ID de ejecución durante el proceso.
4.2.24.2 Explicación del uso de los paquetes genérico
SEQ_CTL_CARGAR_TABLA: Su funcionalidad está condicionada a la invocación de SEQUENCES , que

realizan obtención o procesamiento de datos desde cualquier fuente; puede ser un archivo de entrada o
tablas de base de datos; procedimientos de base de datos, etc.; que por lo general extraen, transforman
y/o cargan a un destino (Tabla o archivo de salida).
El archivo de entrada debe estar ubicado en un servidor FTP Banco, puede ser cifrado o no; comprimido o
no. La funcionalidad de cargar tabla va a permitir copiar el archivo desde el FTP al Engine de Datastage
para hacer el proceso de extracción y aplicar la funcionalidad del desarrollo particular que se requiere
invocar.
SEQ_CTL_CARGAR_PLANO:_Esta funcionalidad se utiliza cuando el desarrollo particular, genera salidas
de información diferente a tablas que requieran transferencia de archivos hacia FTP. La transferencia se
realiza desde el Engine DataStage (lugar donde se aloja temporalmente la salida de información del
desarrollo particular - Origen ) hacia el servidor FTP (destino).
Las rutas de archivo tanto origen como destino, usuarios y nombres de archivos, son parametrizados en la
tabla de control STG_TBL_CONTROLFTP, que posteriormente serán usadas por el sequence
SEQ_CTL_CARGAR_PLANO.
El SEQ_CTL_CARGAR_TABLA y SEQ_CTL_CARGAR_PLANO; reciben como parámetro los relacionados
en la siguiente tabla, que a su vez deben ser enviados por SEQ_GEN_INVOCAR_PAQ_GENERICO
PARAMETRO DESCRIPCION
Nombre del Sequence que genera el archivo, incluido el prefijo
VAG_CTL_NOMBRE_DESTINO
‘SEQ’

VAG_NOMBRE_RECURSO Nombre del archivo de salida, si este es dinámico o de entrada.
Parámetros de ejecución la ETL interna que genera el archivo,
separados cada parámetro con “|”. Ejemplo: Se diligencia el nombre
VAG_CTL_PARAMETROS de la variables seguida de “;” y su correspondiente valor. Para incluir
variables adicionales se incluye el separador de lista “|”.
VAR_ESTADO;1|VAR_CUSTOMER_ID;266
4.2.24.3 Invocación SEQ_GEN_INVOCAR_PAQ_GENERICO

Para invocar el paquete genérico, una vez creado el Sequence de su propio proceso(Desarrollo particular),
incluya como Job Activity el sequence SEQ_GEN_INVOCAR_PAQ_GENERICO y modifique las
características de invocación, y el parámetro VAP_COMANDO según requiera el tipo de proceso que
pasará por CARGAR TABLA o CARGAR PLANO, líneas abajo se brindará más información.
Invocation Id: permite identificar plenamente la instanciación del proceso que invocará al genérico y
adicionalmente según la naturaleza del desarrollo le brindará un consecutivo por fecha y hora de ejecución
para ello se usa en un USER VARIABLE ACTIVITY el parámetro #UVA_HORA.Hora# que básicamente
contiene el nombre del sequence desarrollado junto a la fecha y hora del sistema en tiempo de ejecución
(aclaración, esto va condicionado al requerimiento). Se pretende además que CARGAR TABLA o CARGAR
PLANO conserven dicho Invocation Id en el posterior paso asociado a VAP_COMANDO.
VAP_COMANDO: parámetro que guiará la ejecución del genérico
SEQ_GEN_INVOCAR_PAQ_GENERICO, allí se debe consignar la cadena de invocación:
"(cd $DSHOME/bin &&./dsjob -run -jobstatus -param VAG_CTL_PARAMETROS=":'"':"":'"':" -param
VAG_NOMBRE_RECURSO=":'"':"":'"':" -param
VAG_CTL_NOMBRE_DESTINO=":'"':"SEQ_STG_DS_FCT_PLAN_PAGOS_ACTIVOS":'"':"
PRY_CTL_GENERAL
SEQ_CTL_CARGAR_TABLA.SEQ_STG_DS_FCT_PLAN_PAGOS_ACTIVOS":UVA_HORA.Hora:")"
SEQ_STG_DS_FCT_PLAN_PAGOS_ACTIVOS -> Reemplace por el nombre de su proceso y/o sequence
correspondiente
SEQ_CTL_CARGAR_TABLA -> Puede cambiarlo si requiere CARGAR PLANO, basta con reemplazar por
SEQ_CTL_CARGAR_PLANO y de esa manera empleará el genérico que llama al proceso BOCC que
realiza el proceso mediante CARGAR PLANO y así realizar transferencia FTP del archivo plano resultante
de su proceso.

Se aclara que el SEQ_CTL_CARGAR_TABLA también posee funcionalidad FTP, pero está orientada a
realizar la importación de archivos vía FTP desde el servidor FTP (origen) hacia el Engine de DataStage
(destino), mientras que el SEQ_CTL_CARGAR_PLANO realiza la transferencia desde el Engine de
DataStage (origen) hacia el servidor FTP (destino).
A continuación, se presenta un ejemplo usando el SEQ_CTL_CARGAR_PLANO, tenga presente además
que el mecanismo definido por BOCC para la invocación de los genéricos, le permite pasar los parámetros
que requiera su proceso sin ningún inconveniente.
VAP_COMANDO ejemplo, para invocar SEQ_CTL_CARGAR_PLANO:

"(cd $DSHOME/bin &&./dsjob -run -jobstatus -param VAG_CTL_PARAMETROS=":'"':"":'"':" -param
VAG_NOMBRE_RECURSO=":'"ConsolidadoConsumosF1023Anio': Right(TimeDate(),4) :'.xls': '"':" -param
VAG_CTL_NOMBRE_DESTINO=":'"':"SEQ_GENERAR_EXCEL":'"':" PRY_CTL_GENERAL
SEQ_CTL_CARGAR_PLANO.SEQ_GENERAR_EXCEL":UVA_HORA_FECHA.HORA :")"
4.2.24.4 Configuración de parámetros Modelos de carga Banco
Cada uno de los desarrollos de DataStage (SEQUENCES), debe contener su correspondiente

parametrización en STG_TBL_CONTROLCARGUE; para ser invocado desde el
SEQ_CTL_CARGAR_TABLA. Si Se trata de una salida de información con transferencia de archivos,
requiere diligenciar también su correspondiente registro en la tabla STG_TBL_CONTROLFTP.
ADMSTAGE.STG_TBL_CONTROLCARGUE
Nombre Columna Tipo de dato Obligatorio Default Descripción

Nombre de la tabla
que se carga, debe
ser igual al nombre del
VARCHAR2(80 paquete que la carga,
STR_NOMBRE_TABLA BYTE) No sin prefijo PAQ

Fecha inicial del
periodo en que se
DTM_FCHA_INICIAL DATE Yes debe hacer el cargue
Fecha final del
periodo en que se
DTM_FCHA_FINAL DATE Yes debe hacer el cargue
Frecuencia de la
carga: Y Anual, M
Mensual, Q
Trimestral, B
Quincenal, W
Semanal, D Diario, H
VARCHAR2(80 hora, 12H 12 horas, N
STR_PERIODICIDAD BYTE) Yes Sin periodicidad
Indica si la carga es
VARCHAR2(256 total, o parcial y su
STR_CONDICION_CARGAINI BYTE) Yes condición
VARCHAR2(256 Condición de Hasta,
STR_CONDICION_CARGAFIN BYTE) Yes para la carga
Indica el estado de la
última ejecucion:
EXITO, ERROR o
EJECUTANDO. Si
estó en
EJECUTANDO no
VARCHAR2(80 permite volver a
STR_ESTADO_ULT_CARGUE BYTE) Yes lanzar otra carga.
Indica si la carga está
VARCHAR2(80 activa = A o inactiva =
STR_ESTADO_ACTIVO BYTE) Yes I.
Fecha de la última
DTM_FCHA_ULT_EJEC DATE Yes ejecución de la carga
VARCHAR2(4000 Indica el tipo de error
STR_PASO_ERROR BYTE) Yes al cargar, si lo hay
Indica si la última vez
VARCHAR2(80 se hizo un cargue total
STR_TIPO_ULT_CARGUE BYTE) Yes o parcial
Fecha del último
cargue exitoso.
Teniendo en cuenta
esta fecha y la
periodicidad del
cargue, se lanza o no
DTM_FCHA_ULT_CARGUE DATE Yes un nuevo cargue
Sistema de donde
VARCHAR2(80 viene la información
STR_FUENTE BYTE) Yes que se está cargando
Fecha de ultimo
DTM_FCHA_CARGUE DATE Yes recargue desde SAM
Identificador de la
aplicación destino de
PK_CARGUES_APLICACION NUMBER No la información
VARCHAR2(2 Identificador de
STR_CONCURRENTE BYTE) Yes 'NO' Interfaz Concurrente

Indicador de
VARCHAR2(2 generación de
STR_INDICADOR_NOTIFICACION BYTE) No 'NO' notificación SI/NO
VARCHAR2(4000
STR_CORREO_NOTIFICACION BYTE) Yes Correo de notificación.
Nombre de Proyecto
VARCHAR2(50 donde se encuentra el
STR_NOMBRE_PROYECTO BYTE) Yes Sequence
ADMSTAGE.STG_TBL_CONTROLFTP
Obligatori Defaul
Nombre Columna Tipo de dato Descripción
o t
Nombre del archivo o de la
tabla destino, debe ser igual
VARCHAR2(80) Si al nombre del paquete que
genera el archivo, sin el
STR_NOMBRE_DESTINO prefijo ‘PAQ’
Tipo del cargue
VARCHAR2(80) No
STR_TIPO_CARGUE DELTA/FULL
Nombre del archivo
VARCHAR2(80) Si
STR_NOMBRE_ARCHIVO principal
Nombre del archivo en
VARCHAR2(80) No
STR_NOMBRE_ARCHIVO_FULL cargue FULL
STR_NOMBRE_ARCHIVO_DEL Nombre del archivo en
VARCHAR2(80) No
TA cargue DELTA
Dirección IP del WSFTP
VARCHAR2(80) Si
STR_DIRECCION_IP donde se realiza el cargue
Nombre de usuario en la
VARCHAR2(80) Si
STR_NOMBRE_USUARIO conexión FTP
Contraseña para conexión
VARCHAR2(80) Si
STR_PALABRA_CLAVE FTP, cifrada
VARCHAR2(11
Si Ruta de archivos FTP
STR_RUTA_FTP 0)
Ruta en el workspace de
VARCHAR2(80) Si
STR_RUTA_ETL Datastage
NUM_REGLA_FECHA NUMBER Si Número para regla de fecha
STR_DESCRIPCION VARCHAR2(80) No Descripción del archivo
Indica si el archivo viene o
VARCHAR2(80) No 'NO' se debe generar cifrado
STR_CIFRADO (SI/NO)
Indica si el archivo es de
VARCHAR2(80) No
STR_TIPO_PLANO ENTRADA o de SALIDA
Indicador para comprimir
VARCHAR2(80) No 'NO'
STR_COMPRIMIR SI/NO
Indicador para auditar
VARCHAR2(80) No 'NO'
STR_AUDITAR SI/NO
DTM_FCHA_CARGUE DATE No Fecha del último cargue
Valida si el nombre del
VARCHAR2(80) Si 'NO' archivo de salida es
STR_NOMBRE_DINAMICO dinámico, si es así se toma

Obligatori Defaul
Nombre Columna Tipo de dato Descripción
o t
de la variable
VAG_NOMBRE_RECURS
O.
STR_REQUIERE_EXTENSION VARCHAR2(2) Si 'NO'
STR_NOTIFICACION VARCHAR2(2) Si 'NO'
STR_ENDPOINT_IP VARCHAR2(60) No '-'
STR_ENDPOINT_PTO VARCHAR2(4) No '-'
STR_ESQUEMA VARCHAR2(30) No '-'
STR_NOMBRE_TABLA VARCHAR2(30) No '-'
STR_NOMBRE_COLUMNA VARCHAR2(30) No '-'
STR_BORRA_STAGE VARCHAR2(2) No 'NO'
Clave acceso FTP desde
VARCHAR2(60) No '-'
STR_FTP_SO SO.
Los valores de los distintos parámetros serán almacenados en un archivo plano de inicialización que deberá
estar protegido en el servidor donde residen los Jobs de DataStage, este archivo estará configurado
teniendo en cuenta los respectivos ambientes (Desarrollo, Calidad y Producción).
4.2.25 Volumetría y acción por realizar sobre la base de datos

De acuerdo con la cantidad de registros que se van a procesar y cargar en el destino, se definen ciertos
estándares y grados de complejidad en los procesos:
Complejidad Baja Complejidad Media Complejidad Alta

(Simple) (Medio) (Complejo)
Insert con baja Cargue de Cargues de
cantidad de información de tipo información de tipo
registros, o delta, donde se delta con
actualizaciones de tienen que insertar o volumetrías altas
pocos registros. actualizar registros (mas de 1M de
< 100 Mil de manera registros) las cuales
simultánea. requieres inserts
masivos o
actualizaciones.
Basado en la clasificación anterior, se hacen las siguientes recomendaciones para el cargue de datos:
Complejidad Baja Se recomienda el uso del stage directamente.

(Simple)
Complejidad Media Se recomienda el uso del stage directamente,
(Medio) para proceso de que manejen hasta 100mil
registros, en caso de que la volumetría del
proceso este entre 100mil registros y un millón
de registros se recomienda hacer por
separado la actividad de insert y las otras
acciones que se van a realizar.

Complejidad Alta Para volumetrías superiores a 1millon se
(Complejo) recomienda crear una tabla temporal en la
base de datos destino y mediante una
sentencia de tipo MERGE realizar el ajuste de
procesamiento de la información.
4.2.26 Inicialización de Jobs

Se deberá utilizar la función RunJobdentro del código del Batch Job, para poder tomar los valores de los
parámetros de inicialización desde el manager Datastage. Esta función recibe como parámetro el nombre
del Job.
Se presenta un ejemplo de las variables a recibir la configuración cambia según el archivo de configuración
del ambiente para las variables.
• VAG_ORA_URI_ODS: variable global URI conexión a ODS esta configuración cambia según el
ambiente de ejecución
• VAG_ORA_USER_ODS: variable global usuario interaplicaciones conexión a Oracle esta
configuración cambia según el ambiente de ejecución
• VAG_ORA_PW_ODS: variable global clave usuario interaplicaciones conexión a Oracle esta
configuración cambia según el ambiente de ejecución
• VAG_PATH_ENTRADA: Variable global con el repositorio de archivos que sirven de fuente o
insumo para los Jobs.
• VAG_PATH_SALIDA: Variable global con el repositorio de archivos salientes o resultantes de
operaciones finales de los Jobs.
• VAG_PATH_TMP: Variable global con el repositorio de archivos que sirven de áreas de trabajo y
descarga de temporales para los Jobs.
• VAG_PATH_DATASETS: Variable global con el repositorio de archivos que sirven de áreas de
trabajo y descarga de datasets temporales para los Jobs.
• VAG_PATH_LOGS: Variable global con el repositorio de archivos que sirven para la
administración de logs.
• VAG_PATH_RUTINAS: Variable global con el repositorio de archivos que sirven para rutinas y
similares.
4.2.27 Aprovisionamiento de Recursos en Ambientes (Desarrollo, Calidad y Producción)

Para la implementación de la plataforma de InfoSphere se toma un dimensionamiento inicial el cual fue
realizado por expertos en la plataforma de IBM, personal de operaciones en el Banco de Occidente, el
Administrador de Componente y el Administrador de plataforma deben realizar el análisis de cada uno de
los proyectos que se desarrollan en la plataforma de Infosphere con la finalidad de evaluar el impacto y
consumo de recursos en caso de requerir recursos adicionales se debe evaluar con infraestructura el
procedimiento para la asignación de los mismos en los 3 ambientes (Desarrollo, Calidad y Producción) .

4.2.28 Versionamiento DataStage
4.2.28.1 Descripción de roles y flujo de trabajo versionamiento

Roles DataStage
1. Desarrollador: persona encargada de desarrollar los DSX componentes o elementos de DataStage.
2. Administrador DataStage: persona encargada de la administración y gestión de la herramienta, debe
garantizar el control de versiones entre ambientes.
3. Infraestructura: persona encargada de los despliegues en ambientes de Calidad y Producción.
Flujo de trabajo
1. El Desarrollador trabaja el código en su equipo de manera local y genera los export.DSX con
ejecutables, diseños y todos los componentes propios de la ETL, no solamente los modificados.
2. El Desarrollador carga los DSX en la carpeta destinada para desarrollo del Servidor de
Versiones SVN.
3. El Administrador de DataStage tomará la última versión del SVN-desarrollo y cargará en SVN-
calidad, luego solicitará a Infraestructura el despliegue en ambiente de calidad.
4. Infraestructura descarga código del SVN-calidad y despliega en ambiente de Calidad.
5. Una vez certificado el desarrollo, el Administrador de DataStage tomará la última versión de
SVN-Calidad y cargará en SVN-Producción, luego solicitará a Infraestructura el despliegue en
ambiente de Producción.
6. Infraestructura realiza despliegue desde SVN-Producción a ambiente Productivo.

Ejemplo Control de Versiones entre
Ambientes
DESARROLLO CALIDAD PRODUCCIÓN
1.0 1.0 1.0
1.1 1.1 1.0
1.2 1.1 1.0
1.3 1.1 1.0
1.4 1.4 1.4
Por ningún motivo:

- En ambiente Productivo deben existir versiones superiores a la útlima versión de Calidad y
Desarrollo.
- En ambiente de Calidad deben existir versiones superiores a la última versión de Desarrollo.
4.2.29 Rutinas aprobadas por Arquitectura

- CargarVariablesProyecto, esta rutina resuelve de manera cíclica y múltiple, la lectura de valores
existentes en un archivo plano al interior del Engine de DataStage; tarea primordial para
complementar esta característica que no viene directamente incorporada en algún stage de la
herramienta.
4.2.30 Depuración ambiente de calidad

Evite en todo momento llevar al ambiente de calidad Jobs y/o Sequences dentro de sus export, que NO
sean utilizados por el proceso o que constituyan temporales de trabajo en ambiente de desarrollo,
adicionalmente, está rotundamente prohibido incluir en los export que van a calidad y/o producción, Jobs
que no cumplan con los estándares definidos o que represente copias de Jobs sin uso.
4.2.31 Exports y Despliegues desde ambiente de Desarrollo a otros ambientes

1. Se define el documento estándar a diligenciar paso a paso por parte del desarrollador, para afinar
y garantizar el despliegue exitoso y posterior ejecución de Jobs en cada ambiente:
ESTRATEGIA DE PASE PROD_TEST_#NOMBRE_PROCESO#.xls
2. En caso sean requerido por parte de los funcionales y/o administradores de la plataforma en
BOCC, será deber del desarrollador y/o persona que solicite el despliegue en ambiente de
calidad y/o producción entregar evidencia de la ejecución exitosa de los Jobs y secuencias
desplegados o a desplegar, para ello se exigirán los pantallazos del status y monitor de los Jobs
asociados a la secuencia, velando porque el despliegue efectivamente ejecutó de manera
satisfactoria previamente.
3. El archivo DSX que será entregado para el despliegue, NO puede contener ítem dependientes,
será deber de quien realice el despliegue compilar los Jobs y garantizar el buen estado del
ambiente de calidad y/o producción. Para ello se deben configurar los export.DSX con
ejecutables, diseños y todos los componentes propios de la ETL (no solamente los modificados)

para el paso a calidad y/o producción, teniendo en cuenta que el Administrador de DataStage
debe asegurar el control de las versiones en cada uno de los ambientes.
4.2.32 Lineamientos generales

• Todo usuario de la herramienta debe estar creado en LDAP.
• La auditoría de sucesos debe estar activa y permitir registrar todos los intentos de acceso por
aplicación y acceso a los datos.
• Las contraseñas deben cumplir con políticas de seguridad y deben ser cambiadas
periódicamente.
• Los proyectos deben tener un grupo de usuarios definido que permitan acceder a desarrollo,
monitoreo y demás funciones que se requieran.
• Los usuarios creados deben pertenecer a grupos de usuarios que permitan identificar las
funciones y proyectos que pueden acceder
• Todo proceso que requiera realizar procesos de cargue o migración debe apoyarse en el área
Stage o base de perfilamiento con el cual cuenta la herramienta.
• Los JOBs que manejen archivos cifrados, deberán usar el llavero inter-aplicaciones para realizar
el cifrado o descifrado.
• La programación de la ejecución de los JOBs se realizará mediante la herramienta de
automatización WA, en ningún caso se usará la herramienta “Planes de Carga” o “Information
Services Director”
• Todo desarrollo de Jobs debe tener el archivo de configuración de nodos, el cual tendrá en
cuenta si el proceso es en Online o Batch.
• Para llevar a cabo los procesos de homologación propios de la ejecución del proceso de ETL,
debe realizarse sobre el modelo definido para esto.
• El área de Stage o base de datos de perfilamiento es de uso exclusivo de DataStage y de los
procesos que esta lleva a cabo, no se permite el acceso a la información existente con una
herramienta externa, ni alojar en ella información de manera persistente, más allá de la ejecución
de la ETL que soporta.
• Todo proceso producto de un requerimiento debe ser empaquetado en un Sequence Jobs, para
consolidar los recursos usados dentro de una implementación en particular.
• Todo proceso de transformación solo tendrá en cuenta las columnas que impacten el proceso las
que no están siendo usadas no deben ser tenidas en cuenta al momento de mapear.
• Todas las fuentes oficiales hacen referencia a una base de datos transaccional de aplicaciones
utilizadas por el banco en los siguientes motores de bases de datos (Oracle, SQL Server) y
cualquier aplicación que tenga un repositorio de datos. Se debe tener en cuenta el soporte de
DataStage para el repositorio de datos que se quiera acceder.
• Toda variable global tendrá su parametrización en los ambientes de (Desarrollo, Calidad y
Producción).
• Las variables $APT_TSORT_STRESS_BLOCKSIZE, APT_SORT_INSERTION_CHECK_ONLY
se mantienen con valores default, teniendo en cuenta los monitoreos del Administrador de
Componentes y Administrador de Plataforma se deben ajustar estos valores.
• Toda aplicación creada en Information Server Director para despliegue de un Job online debe
utilizar alguno de los siguientes protocolos (SOAP Over HTTP, SOAP Over JMS, REST 2.0).
• Por definición un proceso es Online cuando sus stage de entrada y salida sean de tipo servicio
(ISD_Input, ISD_Oput, entre o por definición todo Job que sea de tipo servicio debe estar
relacionado con una aplicación que permita su publicación.

• Todo Job debe tener un documento de diseño aprobado por arquitectura y administrador de
DataStage.
• Todos los procesos (Secuencias y Jobs) que requieran despliegue entre ambientes, deberán
contemplar la plantilla de detalle de los Jobs a pasar al ambiente destino, relacionando nombre
de Jobs afectados, secuencias, variables generales empleadas en el SEQ principal, fechas y
otros detalles del desarrollador.
• Todo proceso de creación de un archivo debe garantizar el borrado del archivo al finalizar el
trabajo, solo tendrá excepción si otro Job lo requiere como entrada pero el ultimo Job debe
garantizar el borrado y se actualizarán los documentos de diseño explicando el proceso.
• Todo archivo almacenado en FileSystem de la capa Engine de tipo “.ds”, será eliminado cada 24
horas.
• Todo proyecto de DataStage debe solicitar al administrador la asignación de usuarios, creación
de proyecto, asignación de roles y usuarios del proyecto.
• Toda fuente de datos que se desee agregar a InfoSphere debe ser autorizada por Arquitectura.
• Todo Job debe considerar como parte de su procesamiento, la limpieza de las áreas temporales
de trabajo, de tal manera liberar los espacios en disco que han sido usados por parte del proceso
de carga.
• Todo proceso de Job debe considerar que la limpieza de temporales se produzca aun en
condiciones de termino inesperado del Job y no solo en los casos de finalización con éxito.
• Se debe validar el plan de ejecución en la fuente sobre todas las consultas construidas con el fin
de asegurar un rendimiento óptimo.
• Se deben revisar todos aquellos JOB con rendimiento menor a 1.200 rows/seg, siendo estos
candidatos a optimización.
• Todo proceso de Job debe eliminar los accesos a disco innecesarios como llamados a tablas
desde una transformación a otra transformación, o pasar a un archivo txt para transformar los
atributos de los campos. Se debe privilegiar el flujo de los datos a través de las transformaciones
como forma de trabajo.
• Se debe evitar ejecuciones de llamadas a shell para procesos cuya lógica puede ser construida
en Datastage. El uso de Shell debe ser evitado cuando Datastage proporciona funcionalidad
similar.
• La configuración inicial para lograr que el proceso sea óptimo, es la siguiente: Array Size en
1000, Transaction size en 5000 y Rows por transaction en 1000, para el stage de lectura se debe
configurar el prefetch rows en 5000.
• Todo Job debe tener un stage o proceso para el control de errores, en caso de generar errores al
ejecutar un proceso es definición de diseño y negocio si se detiene todo el proceso o se realiza
cargue parcial.
• Todo Jobs que afecte un proceso CORE del banco al generar un error, no debe realizar cargues
parciales sino detener la carga total.
• Cualquier variable de parametrización adicional a las definidas por arquitectura debe ser validada
y aprobada por arquitectura, el proyecto debe documentar y justificar la nueva variable.
• Todas las variables requeridas por un proyecto DEBEN ser gestionadas con el administrador de
la herramienta.
• Todos los Jobs deberán utilizar el Job Secuencial para la ejecución y administración de las
variables del ambiente respectivo.
• Los Jobs siempre deben ser ejecutados por (WA) en los ambientes de (Producción y Calidad)
utilizando línea de comandos, solo en desarrollo se puede utilizar el Services Director para su
ejecución.
• La conexión a las diferentes fuentes de datos se debe realizar con las variables globales
definidas para cada una de las aplicaciones y deben ser administradas por el administrador
principal de la herramienta.
• Toda variable global requerida por cualquier proyecto debe ser autorizada por arquitectura.

• La parametrización de un stage particular debe realizarse con el uso de variables de proyecto o
globales, si es una variable de proyecto debe ser documentada.
• Todas las rutinas utilizadas en DataStage, deben tener el visto bueno de arquitectura, con un
documento que explique la finalidad y justificando porque no se puede desarrollar en stage
propios de la herramienta.
• Todas las sentencias SQL deben ser optimizadas por el DBA de desarrollo y tener su visto
bueno.
• Los Jobs de extracción solo deberán tener en cuenta las columnas requeridas, las columnas que
no sean requeridas no deben ser tenidas en cuenta en el proceso ETL.
• Evitar el uso de rutinas en las trasformaciones, implementar la lógica en las funciones del Stage
de Transformación.
• Evitar el sobre uso de rutinas en los Jobs.
• Los directorios de instalación de la plataforma no deben contener información de ningún
desarrollo o proyecto, estos deben estar en la raíz “/DS/” que tiene esa finalidad.
• Todos los Jobs deben tener diligenciado los campos de descripción corta, anotaciones que
expliquen modificaciones entre versiones.
• Todo desarrollador tiene la responsabilidad de versionar correctamente sus desarrollos en el
repositorio de versiones de ambiente de desarrollo de DS.
• Toda información que no requiera agrupación debe utilizar el particionamiento de tipo Round
Robín y se debe mantener en el proceso completo.
• Los desarrollos no deben realizar propagación de columnas que no sean requeridas.
• Todo job que requiera ejecución en paralelo, debe tener activada la opción (Allow Multiple
Instance).
• Todo parámetro creado debe tener el mismo nombre en la opción “Parameter name ” y “Prompt”.
• Los DataSets temporales que se creen a lo largo de cada proceso deberán ser borrados una vez
terminada la ejecución del mismo, dejando única y exclusivamente aquellos que para efectos de
la naturaleza del proceso sean re-utilizables o bien hagan las veces de checkpoint para el
proceso en un eventual caso de reprocesamiento.
• Todo desarrollo en Datastage debe hacerse con los objetos stage que ofrece la herramienta, solo
debe utilizarse el área temporal ADMSTAGE cuando por motivos de complejidad o rendimiento
no sea eficiente el proceso.
4.3 Nombramiento
El nombramiento de objetos en DataStage debe cumplir el siguiente estándar:
4.3.1 Proyecto
PRY_XXXX
XXXX: describe la aplicación destino de los procesos ETL del proyecto. Ejemplo PRY_ODS. Un proyecto
agrupa los desarrollos cuyo destino es el sistema usado como descriptivo
4.3.2 Carpetas
Abreviatura del sistema fuente, o del requerimiento: Las carpetas son contenedores de objetos, así que se
deben usar nombres descriptivos.

4.3.3 Sequence Jobs
SEQ_XXXX
XXXX: es el nombre del flujo final que carga. Se pueden usar abreviaturas cuando se refiera al área staging
o al área destino.
Ejemplo:
• SEQ_SF_PLANO_MR: genera un archivo con la información de multiregistros.
• SEQ_FCT_SALDOS_CONTABLES: carga la tabla de ODS FCT_SALDOS_CONTABLES
SEQ_ + Archivo o Tabla (Principal) Destino.
4.3.4 Parallel Jobs

JOB_YYYXXXXNN
XXXX: es el nombre del objeto de datos destino, que se carga en el Job.

NN: Consecutivo para diferenciar grupos de interfaces que cargan la misma tabla.
YYY: Denota el tipo de actividad realizada por el Job.
• EXT: Extracción de información de la fuente de datos.
• DUP: Obtención de registros duplicados en la fuente de datos, con respecto a los datos que se
requiere almacenar en el destino.
• CDC: Es el proceso donde se hace la captura de los cambios de la data en proceso con respecto
a la data existente (ejecución inmediatamente anterior).
• CLE: Se realiza la limpieza (cleaning) y transformación de formato de la información a procesar.
• MIN: Contiene la extracción de las entidades tipo MINOR consideradas tablas de menor cuantía
en registros, hacia DataSets, que serán leídas vía conector nativo y/o ODBC según amerite y
posteriormente cruzados a través de LookUps, ejemplo (tabla de homologación con sus filtros,
países, canales, etc).
• TRF: Se realiza el proceso de transformación y validación de la data con respecto a los dominios
que esta tiene. Por ejemplo: se puede validar el dominio de una clasificación
• Género bajo los valores Masculino, Femenino, en este caso si el valor que traemos desde la fuente
no coincide con el dominio especificado, la validación no será exitosa.
• LOD: Se carga la información ya depurada hacia la tabla o archivo destino.
Cuando el job realiza una actividad de carga de información, no es obligatorio especificar la actividad.
En cada Job se debe identificar con el nombre del archivo o tabla destino, y si es más de un archivo o tabla
destino, se debe especificar el Host/Archivo o tabla principal.
Ejemplos:
• JOB_DIM_OPERACION_COMEX_01: es el segundo job paralelo que carga datos en la
DIM_OPERACION_COMEX
• JOB_DS_FCT_RELACION_PRESTAMOS_MR: job que crea un archivo DS con la información
extraída de la FCT_RELACION_PRESTAMOS, relacionada con multiregistros.
JOB_ Archivo / Tabla (Principal) Destino+ consecutivo.
4.3.5 Links (enlaces)

LNK_XXX_YYY_ZZZZ
XXX: Abreviatura del tipo de Stage Origen

YYY: Abreviatura del tipo de Stage destino

ZZZZ: descriptivo
Ejemplos:
• LNK_DS_JN_DIMPRESTAMO: para el enlace entre un archivo DS y un Join que procesa
información de la DIM_PRESTAMO
• LNK_TRN_AGG_VALTRANS: para el enlace entre un transformer y un aggregator que calcula el
valor de una transacción
4.3.6 Procedimientos
PRC_XXXX
XXXX: Descriptivo breve del objetivo del procedimiento. Ejemplo: PRC_TRUNCAR_STG
4.3.7 Variables de Proyecto

VAP_XXXX
XXXX: Nombre de la variable. Ejemplo: VAP_FECHA_ACTUAL
4.3.8 Variables Globales

VAG_XXXX
XXXX: Nombre de la variable. Ejemplo: VAG_FECHA_ACTUAL
4.3.9 Stages
Los Parallel o Sequence Jobs están compuestos por Stages, cuyos nombres deben tener los prefijos que
se listan a continuación:
Icono Tipo de Stage Prefijo de

Nombramiento
Aggregator AGG_[Nombre]
Change Capture CDC_[Nombre]
Change Apply CAC_[Nombre]

Copy COP_[Nombre]
Filter FIL_[Nombre]
FTP FTP_[Nombre]
Funnel FUN_[Nombre]
Join JN_[Nombre]
LookUp LKP_[Nombre]
Merge MER_[Nombre]
Modify MOD_[Nombre]
Pivot PIV_[Nombre]
Remove Duplicates RMD_[Nombre]
Slowly Changing Dimension SCD_[Nombre]

Sort SRT_[Nombre]
Surrogate Key Generator SKG_[Nombre]
Switch SWT_[Nombre]
Container CONT_[Nombre]
Db2 Enterprise DB2_[Nombre]
ODBC Connector ODBC_[Nombre]
Sybase SYB_[Nombre]
Store Procedure SP_[Nombre]
Teradata TER_[Nombre]
Column Generator COG_[Nombre]
Row Generator ROG_[Nombre]
Data Set DS_[Nombre]

Sequential File SF_[Nombre]
Lookup File Set LFS_[Nombre]
Start Loop Activity STL_[Nombre]
End Loop Activity ENL_Nombre
Exception Handler EXH_Nombre
Execute Command ECM_Nombre
Job Activity Corresponde al

nombre del Server
Job o Parallel Job
invocado.
Nested Condition NEC_Nombre
Notification Activity NOA_Nombre
Routine Activity RTN_Nombre
Sequencer SEQ_Nombre
Terminator Activity TEA_Nombre

User Variables Activity UVA_Nombre
Wait For File Activity WFFA_Nombre

SAT-LIN009-IBM InfoSphere DataStage

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

SAT-LIN009-IBM InfoSphere DataStage

Cargado por

Copyright:

Formatos disponibles

Lineamientos IBM

Lineamientos IBM InfoSphere DataStage 2 de 40

Lineamientos IBM InfoSphere DataStage 3 de 40

1.1 Historia de Cambios

Lineamientos IBM InfoSphere DataStage 4 de 40

2.3 Público Objetivo

Lineamientos IBM InfoSphere DataStage 5 de 40

Origen de datos Transformación Destino de Datos

Ilustración 1 Ejemplo Job Simple

3.1.2 Jobs Secuenciales

Ilustración 2 Job Secuencial

Lineamientos IBM InfoSphere DataStage 6 de 40

3.1.6 Sequential File

Lineamientos IBM InfoSphere DataStage 7 de 40

Lineamientos IBM InfoSphere DataStage 8 de 40

Fuentes Transformación Destino

Cuándo utilizar este patrón.

Cuándo utilizar este patrón.

Lineamientos IBM InfoSphere DataStage 9 de 40

Fuentes Destino Transformación

Cuándo utilizar este patrón.

Lineamientos IBM InfoSphere DataStage 10 de 40

4.2.1 Diseño del proceso

4.2.2 Orden general de Construcción

4.2.3 Documentación de Jobs

Lineamientos IBM InfoSphere DataStage 11 de 40

4.2.4 Parametrización de Job’s

Lineamientos IBM InfoSphere DataStage 12 de 40

4.2.5 Parametrización de valores de conexiones de BD desde los Job’s

4.2.6 Variables Globales Envió Correo

4.2.7 Variables Globales FTP

Lineamientos IBM InfoSphere DataStage 13 de 40

4.2.8 Parametrización de rutas de archivos en los proyectos

4.2.9 Inclusión de parámetros a nivel de Stages

Lineamientos IBM InfoSphere DataStage 14 de 40

4.2.10 Uso de Tablas Lookup

Lineamientos IBM InfoSphere DataStage 15 de 40

4.2.11 Uso de Partitioning

Lineamientos IBM InfoSphere DataStage 16 de 40

2. Siempre y cuando no se empleen Stages que requieran particionamiento específico, configure

Lineamientos IBM InfoSphere DataStage 17 de 40

4.2.13 Uso de archivos DataSet

4.2.14 Uso de archivos Sequential File

4.2.15 Importación Estructura de Tablas

4.2.16 Importación Estructura de Tablas a Proyectos

Lineamientos IBM InfoSphere DataStage 18 de 40

4.2.17 Limpieza de Ejecución

4.2.18 Tablas de Homologación

4.2.19 Descripción de Objetos

4.2.20 Manejo de Logs y Warnings

4.2.21 Fuentes de Datos No Formales

Lineamientos IBM InfoSphere DataStage 19 de 40

4.2.22 Conexiones a Bases de Datos

4.2.23 Manejo Parameter Set

Lineamientos IBM InfoSphere DataStage 20 de 40

4.2.24 Uso de paquete Genérico

Este SEQ, se permite la ejecución de los paquetes generales ubicados en el proyecto

Lineamientos IBM InfoSphere DataStage 21 de 40

Origen Destino Requiere genérico Complejidad

4.2.24.1 Uso de control cargue modelos tipo ODS

Lineamientos IBM InfoSphere DataStage 22 de 40

4.2.24.2 Explicación del uso de los paquetes genérico

SEQ_CTL_CARGAR_TABLA: Su funcionalidad está condicionada a la invocación de SEQUENCES , que