En la entrada anterior comentamos algunos de los cambios en la nueva entrega de Integration Services en SQL Server 2012. El más profundo es el cambio de filosofía y estructura en la arquitectura del servidor y que ahora existe un único catálogo en el que realizar los despliegues y en él se van almacenar las carpetas, proyectos, paquetes, parámetros y entornos.[box type=”info”] Este artículo pertenece a la serie “Novedades de Integration Services en SQL 2012”. Puedes encontrar el índice de artículos al pie de este.[/box]

Arquitectura del servidor y catálogo SSISDB en Integration Services de SQL 2012

Hay que anotarse que sólo los proyectos con el nuevo modelo de despliegue (Project deployment model) se podrán beneficiar de los cambios que ofrece, los proyectos de modelo de despliegue legado (Legacy o Package deployment model) mantendrán la misma estructura que anteriormente.

Lo primero que debemos hacer para poder realizar despliegues de proyectos es crear el Catálogo, haciendo clic derecho sobre el nodo Integration Services del árbol de objetos de nuestra instancia de base de datos

 

Se marca por defecto la opción de habilitar la integración de CLR con la base de datos, necesario para el funcionamiento de Integration Services.

Arquitectura del servidor y catálogo SSISDB en Integration Services de SQL 2012

Esta acción iniciará un asistente que nos solicitará introducir una contraseña para cifrar la información sensible en la base de datos que soporta el catálogo y creará dicha base de datos SSISDB y un nodo SSISDB bajo la carpeta Integration Services.

Sí, tendremos dos nodos SSIDB en el árbol de objetos. Desde la base de datos podemos utilizar la API T-SQL mediante la que podemos hacer tarea administrativa sobre Integration Services: Especificar valores de parámetros, crear entornos y variables, ejecutar paquetes, monitorizar ejecuciones…Esto da como para otro capitulo, así que lo dejaremos para más adelante.

Arquitectura del servidor y catálogo SSISDB en Integration Services de SQL 2012

Desde el nodo de Integration ServicesSSISDB tenemos acceso a la administración del servicio a través del interfaz grafica y a los informes del Dashboard.

En el catálogo podremos configurar algunas propiedades muy interesantes:

  • Algoritmo de cifrado: (Encryption Algorithm Name) Podemos seleccionar el algoritmo con el que se cifrarán los datos sesibles en la base de datos SSISDB. Podemos establecer cualquier parámetro o variable de entorno como sensible para lograr que se cifre su valor. Los algoritmos soportados son DES, TRIPLE_DES, DES_3KEY, DESX, AES_128, AES_192 y AES_256 (valor por defecto).
  • Limpiar Logs periódicamente: (Clean Logs periodically) El catalogo registra toda la actividad producida por el servicio, como las ejecuciones. Esta propiedad establece si se debe o no limpiar ese registro en función de los días establecidos en la propiedad Periodo de retención (días).
  • Periodo de retención (días): (Retention period) Número de días que se mantendrá los datos en el Log, en caso de que la propiedad Limpiar Logs periodicamente se establezca en True.
  • Número máximo de versiones por proyecto: (Maxium Numer of Version per Project) El catálogo almacena el número de versiones que se establezca en esta propiedad. El valor por defecto es 10, por lo que al realizar despliegues del mismo proyecto tendremos un histórico de 10 versiones.
  • Eliminar periódicamente versiones antiguas: (Periodically Remove Old Versions) Cuando esta propiedad está establecida a True el Agente SQL eliminará las versiones anteriores al número establecido en la propiedad Número máximo de versiones por proyecto.

 

Carpetas

Las carpetas son una estructura lógica para organizar nuestros Proyectos y Entornos. Podemos, por ejemplo, crear una carpeta ‘Sistema Ventas’ y dentro de ella ubicar los distintos proyectos que tengan que ver con este sistema así como lo diferentes entornos.

Arquitectura del servidor y catálogo SSISDB en Integration Services de SQL 2012

 

Un punto interesante de las carpetas es que podemos conceder permisos para su gestión a usuarios sin que estos deban de ser administradores, delegando responsabilidades a los usuarios si fuera necesario:

Arquitectura del servidor y catálogo SSISDB en Integration Services de SQL 2012

Proyectos

La unidad de despliegue pasa de ser un único paquete a ser el proyecto por completo, con sus parámetros y paquetes. El nodo de cada proyecto contiene el nodo Packages, de dónde cuelgan los paquetes que le pertenecen.

Arquitectura del servidor y catálogo SSISDB en Integration Services de SQL 2012

Podremos realizar distintas acciones a través del menú contextual del nodo de proyecto

Configurar: En este formulario podemos referenciar a uno o varios entornos y asignar valores a los parámetros de ámbito de paquetes o de proyecto (podemos cambiar el ámbito en el desplegable Scope), escribiendo un valor o vinculando variables de los entornos referenciados.

Arquitectura del servidor y catálogo SSISDB en Integration Services de SQL 2012

Si se fijan en la imagen pueden observar varias cosas: Tenemos una pestaña Parameters y otra Connection Managers. A los parámetros podemos asignarles un valor manualmente o mapear una variable de un Entorno referenciado (y cuando lo hacemos aparece el nombre de la variable del entorno subrayado). En la pestaña de administradores de conexión también podemos modificar valores de propiedades como la cadena de conexión, credenciales o nombre de servidor y hacer uso de variables de Entornos referenciados. Los administradores de conexión a nivel de proyecto proyecto no aceptan expresiones en tiempo de diseño, pero todas sus propiedades son expuestas para dinamizar la ejecución del paquete:

Arquitectura del servidor y catálogo SSISDB en Integration Services de SQL 2012

  • Validar: Una de las tareas mas pesada que tiene que realizar el motor de Integration Services a la hora de ejecutar paquetes es la validación (conectividad de orígenes de datos, metadatos, etc..). Se puede realizar esta tarea de forma independiente a la ejecución de los paquetes y de esta forma asegurar que puede realizarse la ejecución. Existe validación a nivel de proyecto y de paquete.
  • Mover: Para cambiar el proyecto de carpeta debemos utilizar esta opción.
  • Versiones: Como adelantamos en la configuración del catálogo, se guardan una versión por cada despliegue que es realice de un proyecto. A través de esta opción podemos ver un registro de las últimas versiones del proyecto y restaurarlo a alguna si lo consideramos necesario.

Paquetes

Los paquetes forman el último nodo del árbol de proyectos y poseen propiedades que podemos configurar igualmente, a través del menú contextual y la opción Configure. El formulario para la configuración del paquete es idéntico al de configuración de proyectos: podemos referenciar Entornos, cambiar el ámbito de los parámetros (paquete, proyecto) y asignarles valor, etc..

También como los proyectos podemos validar el paquete. Sin embargo a nivel de paquete tenemos la opción de ejecutar

  • Ejecutar: Accediendo a esta opción abriremos un formulario que nos muestra distintas pestañas, para la asignación de valores a variables, que por defecto tomará las configuradas a nivel de paquete / proyecto, la pestaña para configurar propiedades de administradores de conexión, y una pestaña que hasta ahora no hemos visto: Advanced. Desde aquí vamos a poder sobrescribir propiedades del paquete a través de su ruta (como se hacia en las configuraciones), seleccionar si queremos utilizar el runtime de 32 bits, y el nivel de loging que deseamos extraer de la ejecución.

Arquitectura del servidor y catálogo SSISDB en Integration Services de SQL 2012

Al pulsar Ok se iniciará la ejecución del paquete con la configuración proporcionada.

 

Entornos

Este nuevo elemento nos permite definir variables y asignarles valores. Posteriormente podremos vincular los entornos con los proyectos y asignar las variables creadas en los entornos a los parámetros tanto de nivel de proyecto como de paquete, como vimos en el punto anterior. Un ejemplo clásico es crear entornos con las variables correspondientes para las apuntar a servidores de desarrollo o producción. De esta forma lograríamos ejecutar los paquetes contra distintos servidores simplemente modificando el entorno del que vamos a tomar las variables en el momento de ejecutar los paquetes.

Para crear un entorno hacemos clic derecho sobre el nodo Environments y encontraremos la opción Create Environment

Arquitectura del servidor y catálogo SSISDB en Integration Services de SQL 2012

Tras asignarle un nombre y descripción en el formulario que aparece, se creará el nodo correspondiente bajo el nodo Environments. Si accedemos a las propiedades mediante el menú contextual o haciendo doble clic tendremos la posibilidad de crear las variables y definir su tipo de datos, asignarles un valor y configurar si son datos sensibles para que se cifren en la base de datos:

Arquitectura del servidor y catálogo SSISDB en Integration Services de SQL 2012

Al marcar la variable como sensible sustituirá el valor por unos bonitos asteriscos.

 

Conclusión

En mi opinión el cambio en la arquitectura del servidor centraliza y facilita la administración de Integration Services, todo se hace más intuitivo. Quizás al principio se echen de menos los archivos XML distribuidos o las tablas SQL para las configuraciones, pero a través de la API T-SQL se puede lograr la misma funcionalidad utilizando los Entornos de una forma más segura. Es preciso realizar un pequeño cambio en la forma de trabajar que veníamos desarrollando hasta ahora, pero les anticipo que ese cambio nos revertirá muchas ventajas y nuevas funcionalidades como el Dashboard … del que hablaremos mas adelante.

Si han tenido oportunidad de trabajar con la entrega actual y quieren realizar alguna aportación serán bienvenidos en los comentarios

 

0 Shares:
2 comments
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like
Leer más

Expresiones, parámetros y funciones en Azure Data Factory

Hay ocasiones, cuando estamos construyendo pipelines con Azure Data Factory, que queremos repetir patrones para extraer y procesar la información cambiando de manera dinámica, en tiempo de ejecución, valores, orígenes/destinos de los datasets, incluso los mismos linked services. Esto es posible mediante el uso de parámetros, expresiones y funciones. Vamos a ver cómo implementarlo con un ejemplo práctico en el que se nos plantea el siguiente supuesto. Se nos ha pedido que extraigamos todos los días los datos del día anterior de distintas tablas del DW a ficheros en un blob storage que además se nombre como la tabla de origen. Si no pudiéramos utilizar contenido dinámico tendríamos que crear dos datasets (uno de origen y otro de destino) y añadir una actividad de copia por cada tabla a exportar.