OPTIMIZACION Y BUENAS PRACTICAS EN

DESARROLLO E INTEGRACION DE ETL

Versión 1.0

GERENCIA TI
SubGerencia Arquitectura de Software
2015

Autor: Claudio Villaroel I.

Revisor: Mario Moyano O. / Carlos Rubilar.
Versión: 1.0
Fecha: 22.01.2015
SubGerencia Arquitectura de Software

CONTENIDO

1. INTRODUCCION ......................................................................................... 3
2. INTEGRIDAD DE DATOS Y CONTINUIDAD OPERACIONAL .......................... 3
2.1. Reglas para las Conexiones ...................................................................................................... 3
2.2. Declaración de Packages ........................................................................................................... 4
3. PARÁMETROS V/S VARIABLES ................................................................... 5
3.1. Manejo de errores [Correo – Web Service] ........................................................................ 6
3.2. Componente Data Flow .............................................................................................................. 8
3.3. Tarea Tipo “For Each Loop” .................................................................................................... 10

Confidencial MAU - Buenas Practicas ETL - V1.0.doc Página 2 de 13

Versión: 1.0
Fecha: 22.01.2015
SubGerencia Arquitectura de Software

1. INTRODUCCION

Esta guía tiene como objetivo ayudar en el desarrollo y en la revisión de proyectos de Integration
Services, también conocidos en la empresa como “ETLs”.

2. INTEGRIDAD DE DATOS Y CONTINUIDAD OPERACIONAL

Se debe tener cuidado en que si en algún componente hubo un error, el flujo de datos quede
consistente y trazable de ser necesario (con algún indicador y/o fecha).

En el caso que hubiese un error, por cualquier motivo, y el ETL se ejecuta nuevamente en su
próxima iteración, no deben quedar datos duplicados, ni faltantes. La consistencia debe ser lo más
importante en estos proyectos.

2.1. Reglas para las Conexiones

 Conexiones de proyecto:

Las conexiones a las Bases de Datos Siempre deben ser de proyecto y no por cada Package,
aunque solamente haya un package, ya que si posteriormente se desea agregar otro, lo más
probable es que se utilicen las mismas conexiones.

Ilustración 1: Conexiones de Proyecto

Confidencial MAU - Buenas Practicas ETL - V1.0.doc Página 3 de 13

Versión: 1.0
Fecha: 22.01.2015
SubGerencia Arquitectura de Software

 Nombres conexiones

Las conexiones deben tener un nombre que identifique claramente el servidor, la base de datos y
el usuario con el cual se realice la conexión.

La mejor práctica es: [SERVIDOR].[BASE DE DATOS].[USUARIO].conmgr

 Conexiones repetidas

Las conexiones deben ser únicas.

Dos conexiones iguales (mismo servidor, misma base de datos y mismo usuario) solo causa
desorden y duplicidad.

 Conexiones innecesarias

Las conexiones que no se utilizan deben ser borradas.

2.2. Declaración de Packages

 Nombres packages

Los packages deben tener nombres que indiquen claramente las funciones que realizan.

Nombres como: Package1.dtsx No Corresponden.

Confidencial MAU - Buenas Practicas ETL - V1.0.doc Página 4 de 13

Versión: 1.0
Fecha: 22.01.2015
SubGerencia Arquitectura de Software

3. PARÁMETROS V/S VARIABLES

En un proyecto de integración o ETL se pueden utilizar Variables o Parámetros.

Dependiendo del valor que se desea manejar, se podría necesitar que el alcance de la variable sea
para todo el proyecto, para todo el package o incluso para un componente del package en
particular.

Ilustración 2: Parámetros de Package Ilustración 3: Parámetros de Proyecto

Ilustración 4: Variables de Package

Si se sospecha que el valor pudiese cambiar luego, es más sencillo guardar este valor en un
parámetro ya que posteriormente se puede modificar su valor desde el servidor y no es necesario
modificar en la ETL para luego “Re-Publicar”.

Confidencial MAU - Buenas Practicas ETL - V1.0.doc Página 5 de 13

Versión: 1.0
Fecha: 22.01.2015
SubGerencia Arquitectura de Software

3.1. Manejo de errores [Correo – Web Service]

Está disponible un proyecto plantilla (Ver archivo “Proyecto Plantilla ETL - SSIS.rar”) que tiene
incorporado el manejo de errores. Este considera:

 Envío correo de error

Se encapsula toda la lógica del package en un contenedor (Secuence Container), el cual en caso
de error envía un correo mediante un Web Service.

Ilustración 5: Envío correo de error

 Web Service

El Web Service que se llama para enviar correos se encuentra en:

http://pangue:60000/ws_Mail/WsEnviaMail.asmx?wsdl

El contrato de este servicio se guarda localmente en la máquina donde se está ejecutando el ETL
y la ruta que se debe crear para guardarlo es:

Ilustración 6: Ruta de servicio envío correo

Confidencial MAU - Buenas Practicas ETL - V1.0.doc Página 6 de 13

Versión: 1.0
Fecha: 22.01.2015
SubGerencia Arquitectura de Software

 Captura mensaje de error

En la sección Event Handlers, se indica que al haber error en algún paso del contenedor, capture
la descripción del error en una variable y el nombre del package en el asunto que se enviará en el
correo.

Ilustración 7: Captura mensaje de error

 Parámetros

En la sección Project.params, se pueden modificar los parámetros para indicar a quién enviarle el
correo de error y con copia. En este caso se están manejando a nivel de proyecto ya que
seguramente se les enviará a las mismas personas los errores de los distintos packages del
proyecto.

Tener cuidado en que los correos van entre los signos “<” y “>” y separados por “;”.

Ilustración 8: Parámetros para Manejo de Error

Confidencial MAU - Buenas Practicas ETL - V1.0.doc Página 7 de 13

Versión: 1.0
Fecha: 22.01.2015
SubGerencia Arquitectura de Software

 Procedimientos almacenados

Al utilizar procedimientos almacenados en un ETL, los errores pueden ser manejados en éste con
una sentencia Try..Catch, o dentro del ETL. Esto dependerá de la lógica que se desee utilizar y del
proyecto.

En el caso de utilizar un procedimiento almacenado para obtener datos en un Data Flow, este
procedimiento no debe tener lógicas adicionales como update o delete ya que Integration
Services no sabe qué hacer con los mensajes que envía el motor de base de datos, solo se debe
realizar el Select en el procedimiento y manejar lo demás en procedimientos distintos.

3.2. Componente Data Flow

El componente Data Flow se utiliza para traspasar datos de un origen a un destino, siendo estos
últimos bastante variados, tablas en bases de datos, procedimientos almacenados en los
orígenes, archivos de texto plano o archivos Excel.

 Nombres componentes Origen y Destino

Los orígenes y destinos deben indicarnos fácilmente desde dónde hasta dónde van los datos.
Esto lo indicaremos de la siguiente forma:
[SERVIDOR] - [BASE DE DATOS] - [TABLA PRINCIPAL O PROCEDIMIENTO ALMACENADO]

Ilustración 9: Nombres Origen - Destino en Data Flow

Confidencial MAU - Buenas Practicas ETL - V1.0.doc Página 8 de 13

Versión: 1.0
Fecha: 22.01.2015
SubGerencia Arquitectura de Software

 Lookup

El componente Lookup se utiliza para ir a buscar datos según una llave a otra fuente o también
puede servir para ver si esa otra fuente no tiene ciertos datos, sin la necesidad de traerse toda
una tabla de una fuente a otra.

Ilustración 10: Ubicación Lookup en Toolbox

Para ir a buscar datos a otra fuente se debe ser bien explícito en qué parte de los datos vamos a
buscar, aplicar los filtros correspondientes y seleccionar solamente los campos necesarios, ya
que todos estos datos se levantarán en memoria para su búsqueda.

Confidencial MAU - Buenas Practicas ETL - V1.0.doc Página 9 de 13

Versión: 1.0
Fecha: 22.01.2015
SubGerencia Arquitectura de Software

3.3. Tarea Tipo “For Each Loop”

Una tarea muy usual en la integración de datos, es ir a consultar una lista de registros y por cada
uno de ellos realizar otras tareas. En este ejemplo se consulta una lista de correos y por cada uno
de ellos se envía el correo y luego se actualiza su estado.

Ilustración 11: Ejemplo For Each Loop

Para esto se debe crear una variable de tipo Object, en la cual se debe almacenar el set de datos
que se utilizará para ir recorriendo.

Ilustración 12: Variable objeto For Each Loop

Confidencial MAU - Buenas Practicas ETL - V1.0.doc Página 10 de 13

Versión: 1.0
Fecha: 22.01.2015
SubGerencia Arquitectura de Software

Se debe utilizar un componente Execute SQL Task en donde se ejecutará una sentencia SQL o
procedimiento almacenado que entregue como resultado una lista de registros. Esta se debe
configurar en la sección Result Set como Full Result Set.

Ilustración 13: Execute SQL Task Editor

Y en el menú Result Set a la izquierda del panel, se debe asignar la variable tipo Object creada
previamente.

Ilustración 14: Asignar variable Object

Confidencial MAU - Buenas Practicas ETL - V1.0.doc Página 11 de 13

Versión: 1.0
Fecha: 22.01.2015
SubGerencia Arquitectura de Software

Posteriormente, se debe agregar el componente Foreach Loop Container, se selecciona el menú

Collection a la izquierda del panel, y se configura la opción Enumerator con Foreach ADO
Enumerator, y en la opción ADO object source variable seleccionar la variable Object previamente
creada. Dejar la opción Enumeration Mode con su valor por defecto Rows in the first table.

Ilustración 15: Configuración Collection Foreach Loop Editor

Confidencial MAU - Buenas Practicas ETL - V1.0.doc Página 12 de 13

Versión: 1.0
Fecha: 22.01.2015
SubGerencia Arquitectura de Software

Por último, se debe mapear los campos de la lista de registros que se utilizarán posteriormente
partiendo desde el index 0 (cero).

Ilustración 16: Configuración Variable Mappings Foreach Loop Editor

Luego solo se tendrá que conformar la lógica que se aplicará para cada uno de los registros dentro
del contenedor.

Confidencial MAU - Buenas Practicas ETL - V1.0.doc Página 13 de 13