SSIS Cargando archivos Excel

 

Siempre hay quienes comienzan a hacer algo nuevo y este post está dedicado a estas personas, en concreto a Claudio. Un compañero de los foros de Integration Services en castellano que se preguntaba como podía conseguir resolver su proceso mediante paquetes ETL de SSIS.

 

Escenario

el asunto es que yo tengo una consulta, esta consulta me trae unos datos los cuales los tengo que poner en un excel con la fecha de la generacion y enviarlo a una persona, la idea es crear un paquete que permita mediante algun proceso crear el archivo excel con el nombre del dia(ejemplo ventas_19-06-2012.xls), mas que nada seria para automatizar un par de tareas que debo realizar diariamente

 

Una Solución

Por que siempre hay varios caminos para llegar al mismo sitio. Para este caso he sugerido utilizar una plantilla de libro Excel como destino de datos, que vamos a copiar con una tarea File System para generar un nuevo archivo con la fecha de la consulta que será el destino de los datos obtenidos mediante la misma (consulta)

Vamos con los detalles…

Es nuestro paquete ETL añadimos un DataFlow, con un origen OLEDB source con la consulta que vamos a realizar contra el origen de datos. Para esta entrada utilizaré la base de datos AdventureWorks para realizar esta consulta:

SELECT [ProductID],[Name],[ProductNumber],[MakeFlag],[FinishedGoodsFlag],[Color]
FROM [Production].[Product]

En el archivo Excel que vamos a utilizar como plantilla creamos las columnas necesarias para mapear con los datos de origen:

Hay que tener clara la versión de Excel a utilizar, dependiendo de esto podremos utilizar el componente Excel Destination (hasta Excel 2007) o nos veremos obligados a utilizar OLEDB Destination en caso de Excel 2010. En este caso la versión es 2007.

Añadimos un componente Excel Destination. Conectamos la salida de datos del OLEDB Source a la entrada del destino Excel y editamos este componente para establecer el archivo destino y el mapeo de datos.

Creamos una nueva conexión que apuntamos al archivo plantilla:

Una vez finalizada la conexión realizamos el mapeo de datos entre las columnas del origen de datos y el archivo Excel:

Y finalizamos la edición del componente de destino. Hasta ahora fácil, no hemos hecho nada especial para generar archivos dinámicamente en función de la fecha pero hemos conseguido establecer los metadatos que necesitan los componentes en el flujo de datos.

En las propiedades de este componente (en el panel de propiedades, F4 teniendo seleccionado el componente Excel Destination), hay que cambiar la propiedad ValidateExternalMetadata a false. Es importante este cambio para poder ejecutar el paquete sin que exista previamente el archivo sobre el que vamos a volcar los datos:

El siguiente paso es cambiar algunas propiedades en el administrador de conexión del archivo Excel, en concreto vamos a poner la atención en Delay Validation, que vamos a establecer a True. Observar la propiedad ExcelFilePath, que modificaremos más adelante mediante una variable que proporcionará el nombre de fichero para cada ejecución a través de Expressions:

Nos volvemos a la pestaña de ControlFlow y creamos una variable para generar el nombre del archivo en cada ejecución. Para esto hay que asegurarse de que tenemos seleccionado el lienzo y no el componente DataFlow que añadimos antes, para que el ámbito de esta variable sea del alcance de todo el paquete. Para acceder al panel de variables puede hacer clic derecho sobre el lienzo y seleccionar la opción variables. Crearemos la variable vNombreArchivo de tipo string y sin asignación de valor:

Seleccionamos la variable y pulsamos F4 para mostrar su panel de propiedades. En la propiedad EvaluateAsExpression seleccionamos el valor True y en Expressions vamos a añadir una expresión que conformará el valor de esta variable

En el editor de expresiones generamos una para construir un nombre de fichero en función de la fecha de proceso. Yo he utilizado la siguiente:

"C:\\Consultas2Excel\\Consulta_" + (DT_STR,20,1252) ( (DT_I8) (YEAR( @[System::StartTime] )) * 100000000 + MONTH(@[System::StartTime])*1000000 + DAY(@[System::StartTime]) * 10000 + datepart("hh",@[System::StartTime] ) * 100 + datepart("mi",@[System::StartTime] )   ) + ".xlsx"

Ya tenemos un nombre dinámico para nuestro fichero destino. Ahora solo falta que ese fichero exista y lo vamos a conseguir con una tarea File System Task que añadimos al ControlFlow y establecemos restricciones de precedencia, conectando la salida de ejecución correcta de File System Task con el DataFlow que ya teníamos:

Editamos la tarea File System para modificar sus propiedades. Lo primero es asegurar que la operación es Copy File. Establecemos los siguientes valores por propiedad

Propiedad	Valor
Operation	Copy File
IsDestinationPathVariable	True
OverwriteDestination	(evaluar la necesidad de sobreescribir el archivo de destino si existe en la operación de copia)
IsSourcePathVariable	False
SourceConnection	(Nueva conexión a nuestro archivo plantilla) c:\PlantillaDestino

En el panel de conexiones, buscamos la conexión a Excel que utiliza nuestro destino en el DataFlow y accedemos a las propiedades, en concreto Expressions y añadimos una expresión para la propiedad ExcelFilePath. Escribimos @[User::vNombreArchivo]

Y listo!

Ya tenemos un paquete que lee datos de una consulta y lo vuelca en un fichero Excel nuevo que genera en cada ejecución:

 

Conclusión

Como también vimos en la entrada SSIS Dinamizando propiedades de componentes, el uso de variables facilita en gran medida operaciones de asignación dinámica de propiedades de componentes, tareas, DataFlow, ControlFlow… Además, podríamos utilizar configuraciones de paquetes (en package deployment model) o parámetros y entornos (project deployment model) para exponer estas variables y asignarles valor previa ejecución del paquete.

Si tienes cualquier duda o quieres obtener el paquete ETL  desarrollado durante esta entrada, deja un comentario.

SSIS Capturar duplicados en el flujo de datos

 

 

Introducción

Es muy común encontrarnos con escenarios en los que tenemos que consumir orígenes de datos que contienen duplicados, tanto por columnas clave como por filas completas. Integration Services ofrece componentes que permite eliminar los duplicados (componente Sort), pero en esta entrada vamos a centrarnos en un diseño que nos permita capturar las filas duplicadas por columnas clave para su posterior tratamiento, utilizando la menor cantidad de código posible (componente Script).

---

Este artículo ha sido publicado en el blog BICorner de SolidQ. Pulsa aquí para continuar leyendo.

SSIS: Obtener metadatos de ficheros

 

Introducción

Muchas veces es necesario comprobar algún metadato de un fichero antes de procesarlo. Supongamos que tenemos un paquete ETL que recoge un fichero con un volumen de datos importante, pongamos 100 millones de filas ( si, a veces pasa :) ). El contenido del fichero se genera cada cierto tiempo, pero su nombre nunca cambia. Cabe la posibilidad de obtener todo el contenido para compararlo contra el destino de datos, pero es una tarea que podemos (y debemos) evitar.

En este caso vamos a obtener la fecha de modificación de un fichero para determinar si es necesario procesarlo.

Obteniendo el metadato

Tenemos en un directorio un fichero llamado ventas.csv y disponemos de una tabla en la que vamos registrando la última fecha de modificación de forma que vamos a comparar este dato con el que tiene actualmente el fichero.

La estructura de la tabla es la siguiente:

CREATE TABLE [dbo].[FilesToProcess](
	[Id] [int] NOT NULL,
	[FileFullName] [varchar](255) NOT NULL,
	[LastModifiedDate] [datetime] NOT NULL,
	[ProcessDate]  AS (getdate())
	)

Para empezar, nos creamos tres variables de SSIS: vFilesFullName, vFileModifiedDate y vLastModifiedDate

Para obtener última fecha de modificación, añadimos un Execute TSQL Task al Control Flow y realizamos una consulta que nos devuelva el nombre del fichero a procesar y la última fecha de modificación que registramos:

SELECT [FileFullName], [LastModifiedDate]
  FROM [dbo].[FilesToProcess]

En la sección General establecemos la opción ResultSet a Single Row

En la sección Result Set, mapeamos el resultado a las variables:

Añadimos un Script Task y lo conectamos a la salida de la tarea anterior. Editamos su configuración y establecemos las variables que va a utilizar. Como variables de lectura añadimos vFileFullName y vLastModifiedName y como variable escribible seleccionamos vFileModifiedName:

Lo siguiente es añadir el código al componente (personalmente prefiero C#)

public void Main()
        {
            // TODO: Add your code here
            try
            {
                System.IO.FileInfo mFileInfo = new System.IO.FileInfo(Dts.Variables["vFileFullName"].Value.ToString());
                
                if (mFileInfo != null)
                {
                    Dts.Variables["vFileModifiedDate"].Value = mFileInfo.LastWriteTime;
                    Dts.TaskResult = (int)ScriptResults.Success;
                }
                else
                {
                    Dts.TaskResult = (int)ScriptResults.Failure;
                }
            }
            catch(Exception ex)
            {
                Dts.Events.FireError(-1, ex.Source, ex.Message,string.Empty , 0);
            }
            
        }

Como veis, utilizamos la clase System.IO.FileInfo para obtener la fecha de modificación que actualmente tiene el fichero.

Lo siguiente, es añadir un DataFlow para procesar el fichero. Conectamos el Script Task con el Data Flow  y modificamos la restricción de precedencia (precedence constraint) para añadir la expresión:

@vFileModifiedDate!=@vLastModifiedDate

El aspecto final de este diseño debería ser el de la siguiente imagen:

Resumen

A través de la inclusión de código en Script tasks y Script Component podemos proveer a nuestros paquetes ETL de Integration Services. A través de este ejemplo hemos visto como solucionar un requisito que puede ser habitual encontrarse.

Si queréis descargaros el paquete de ejemplo dejadme un comentario, estaré encantado de compartirlo con vosotros

Migración de proyectos en Integration Services de SQL Server 2012

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.

Introducción

Tras una evaluación concienzuda, hemos revisado pros y contras y se ha tomado la decisión. Ha llegado la hora de migrar aquellos proyectos que teníamos en versiones anteriores a SQL Server 2012 para poder disfrutar de las ventajas de la nueva arquitectura de servidor en Integration Services.

Debemos tener en cuenta las pocas restricciones que tiene este proceso de migración:

• No hay soporte para la tarea Ejecutar paquetes DTS 2000.
• Dejan de existir las tareas ActiveX Script

Tiene sentido que el producto se desprenda de tareas que únicamente mantenían la compatibilidad tecnologías ya obsoletas. Si en sus procesos utiliza estas tareas y quiere actualizar las capacidades de su servidor de integración, quizás es el momento de rediseñarlos.

Para este artículo vamos a utilizar un proyecto de Integration Services creado con SQL Server 2008 R2, compuesto por dos paquetes:

• Master: En un Data Flow, lee desde un fichero CSV y lo vuelca a un archivo RAW. Si la conclusión del Data Flow es correcta, ejecuta el paquete Child a través de la tarea Ejecutar Paquete con el que conecta a través del administrador de conexión ‘Reference to child.dtsx’. Este paquete Master contiene configuración para el origen de datos CSV.
• Child: En un Data Flow, lee desde el fichero RAW generado en el paquete Master  y almacena el nº de filas en una variable.

Son dos paquetes muy sencillos, diseñados específicamente para mostrar todos los pasos posibles de la conversión de proyectos. Además de esto, el proyecto contiene un origen de datos compartido llamado ‘Pruebas’.

 

Actualización del archivo de proyecto

Para comenzar la migración de un proyecto de SQL Server 2005, 2008 o SQL 2008 R2 a SQL Server 2012, únicamente es necesario abrir el proyecto o solución desde Visual Studio.

El proceso de migración tiene dos fases, en la primera de ellas se actualiza la versión del proyecto a Visual Studio 2010 y comenzará una vez se cargue el entorno de desarrollo. Pasamos la página de bienvenida del asistente y podemos definir todas la opciones de esta actualización: si queremos que haga o no copia de seguridad de los archivos antes de convertirlo:

 

Una vez finalizado el asistente Visual Studio cargará el proyecto, pero si nos fijamos en el nombre de la solución en el panel Explorador de Soluciones, entre paréntesis aparece package deployment model

 

Esto significa que podemos editar y guardar el proyecto para realizar despliegues manteniendo la misma estructura con la que veníamos trabajando anteriormente: MSDB o FileSystem, Configuraciones de paquetes (XML, SQL, etc..), pero no aprovecharemos la nueva arquitectura de servidor

 

 

Actualización del modelo de proyecto

Para realizar despliegues de proyectos de Integration Services sobre la nueva arquitectura de servidor es necesario convertir el modelo del proyecto a project deployment model (modelo despliegue de proyecto). Cómo se mencionó en el artículo anterior de la serie, la unidad de despliegue pasa de ser un único paquete a ser el proyecto por completo, con sus parámetros y paquetes.

Es en este proceso en el que los parámetros de paquete y proyecto toman el relevo a las configuraciones, y el hay que restablecer las referencias en tareas Ejecutar paquete. Vamos a iniciar el asistente para la conversión del modelo de proyecto para realizarlo paso a paso.

Haciendo clic derecho sobre el nodo de proyecto y seleccionamos la opción Convert to project deployment model

 

Lo primero que hace al iniciar el asistente es lanzar un aviso comentando el cambio que se producirá en los orígenes de datos compartidos. La conversión del modelo de proyecto  va a desvincular la referencia que exista desde cada paquete a la conexión compartida, transformándola en un administrador de conexión a nivel de paquete. Cuando finalice la migración del proyecto tenemos la posibilidad de convertir cada conexión en un administrador compartido a nivel de proyecto.

 

La primera página de este asistente enumera los pasos que se han de realizar para lograr la conversión y que vamos a seguir:

 

El primer paso es seleccionar los paquetes que vamos a convertir. Es recomendable seleccionar todos los paquetes del proyecto para realizar una conversión homogénea.

¿Que pasaría si optamos por no convertir algún paquete? ¿lo omitirá del proyecto? Si dejamos de convertir un paquete va a seguir formando parte del proyecto, pero no va a ser participe de los elementos que creemos durante la conversión, como los parámetros.

 

 

 

En la siguiente página podemos cambiar el nombre del proyecto y el nivel de protección para encriptación de datos sensibles en los paquetes.

 

Llegamos a la página de Actualizar tareas Ejecutar Paquete, uno de los cambios a realizar debido a la conversión del modelo son las referencias a paquetes en las tareas Ejecutar Paquetes. Hasta ahora, para configurar una tarea de este tipo podíamos seleccionar un origen SQL o FileSystem, pero con el cambio del modelo estas opciones se consideran Referencias Externas y se añaden las Referencias de proyectos, con el fin de simplificar los diseños y despliegues cuando los paquetes se encuentren dentro del mismo proyecto. En la siguiente imagen se puede observar el cambio en la configuración de la tarea.

 

Como dijimos en la introducción, el paquete Master.dtsx, contiene una tarea de este tipo que apunta (mediante referencia de fichero) al paquete Child.dtsx. La columna Original Reference que aparece ‘oculta’ es una ruta local. En esta página del asistente podemos sustituir la referencia anterior por una de proyecto en caso del que paquete a ejecutar se encuentre en el mismo. Como es nuestro caso, seleccionamos Child.dtsx.

 

Si continuamos a la siguiente página podremos seleccionar las configuraciones que vamos a convertir a parámetros. Automáticamente valida que puede cargar los datos de la configuración asociada a cada paquete y muestra el resultado en la columna Status. Podemos cambiar la configuración asociada al paquete por defecto pulsando sobre Añadir configuraciones.

 

El siguiente paso es remplazar las configuraciones de propiedades por parámetros y valores. Se mostrarán todas las propiedades de cualquier paquete del proyecto que estuviera configurado en la selección del paso anterior así que, en nuestro caso tenemos la propiedad Connection String del origen de datos CSV. Ha creado un parámetro al que podemos modificar el nombre que ha generado y el ámbito (paquete o proyecto).

 

Ya tenemos creado el parámetro que sustituye a la configuración pero aún nos queda asignarle un valor por defecto. El asistente rescatará el valor que tuviéramos en la configuración, en nuestro caso una ruta para el origen de datos CSV. En cualquier caso, podemos modificar este valor y pulsando sobre el botón […]

 

No sólo podemos cambiar el valor del parámetro, también establecerlo como requerido para ejecutar el paquete y añadir una descripción.

Una vez desplegado el proyecto podremos modificar los valores de cualquier parámetro manualmente o mediante entornos y variables.

La última página del asistente antes de la conversión nos muestra un resumen de los pasos realizados, en el que podemos revisar opciones que hemos seleccionado. Si pulsamos el botón Convertir comenzará el proceso, que tendrá una duración proporcional al tamaño del proyecto y complejidad de los paquetes. Como nuestro ejemplo es muy sencillo termina en menos de dos segundos.

 

El aviso que muestra indica que se ha convertido el proyecto correctamente, pero hemos de guardar los cambios antes de salir de Visual Studio si queremos preservarlos

 

Revisar el proceso

Cuando finaliza la conversión debemos revisar cada paquete comprobando que los cambios se han realizado como esperamos. En nuestro proyecto migrado, abrimos el paquete Master.dtsx y comprobamos que efectivamente se ha reemplazado la configuración sobre el origen de datos CSV por la asignación del parámetro que hemos creado durante el proceso:

 

Para ultimar los detalles algunos cambios que debemos realizar por nuestra cuenta. Mencionamos que los administradores de conexión compartidos, los que figuran bajo el nodo Data Sources en un proyecto de modelo de despliegue paquete, pasan a ser administradores de conexión a nivel de paquete. Esto podemos cambiarlo ‘promocionando’ la que nos interese como un administrador de conexión a nivel de proyecto y es tan sencillo como abrir el menú contextual y seleccionar la opción Convert to Project Connection (Convertir a Conexión de Proyecto)

Tras esta operación, la conexión convertida aparecerá referenciada en todos los paquetes del proyecto, mostrándose (project) en el nombre de la conexión para diferenciarla de las conexiones propias del paquete:

 

Y para acabar una pregunta… ¿es necesaria conexión “Reference to child.dtsx” tras la conversión del proyecto?

 

Conclusión

Hemos visto como convertir proyectos de Integration Services a modelo de despliegue de proyecto para aprovechar las nuevas características de la arquitectura del servidor. Esta migración se presenta bastante sencilla y aunque los paquetes de nuestro ejemplo no guardan complejidad alguna, en las que he podido realizar no han surgido incidencias.

Por supuesto tras la migración hay que revisar los cambios realizados, comprobando que los parámetros estén asignados a las propiedades correspondientes, compartiendo administradores de conexión y reasignando a los orígenes de datos, etc... darle el toque ‘personal’

En el próximo artículo veremos los puntos a tener en cuenta y el procedimiento para realizar el despliegue del nuevo modelo de proyecto en el servidor.

 

Serie: Novedades en SQL Server 2012 Integration Services

1. Novedades en Integration Services de SQL 2012 / Introducción

2. Nuevas funciones para el lenguaje de expresiones

3. Expression Task

4. Arquitectura del servidor y catálogo SSISDB

5. Migración de proyectos

6. Despliegue de proyectos

7. Informes Dashboard

8. API T-SQL

 

Referencias

Deployment of Projects and Packages
Convert and Deploy Projects

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

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.

 

 

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.

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.

Catálogo

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.

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.

Desde el nodo de Integration Services\SSISDB 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.

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:

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.

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.

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:

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. Para más información échale un vistazo a este artículo de la Wiki de TechNet http://social.technet.microsoft.com/wiki/contents/articles/project-and-package-validation-in-sql-server-denali-ctp1-ssis.aspx

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.

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

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:

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

 

Serie: Novedades en SQL Server 2012 Integration Services

1. Novedades en Integration Services de SQL 2012 / Introducción
2. Nuevas funciones para el lenguaje de expresiones
3. Expression Task
4. Arquitectura del servidor y catálogo SSISDB
5. Migración de proyectos
6. Despliegue de proyectos
7. Informes Dashboard
8. API T-SQL

 

Referencias

Integration Services (SSIS) Project Deployment Overview
Integration Services (SSIS) Catalog Overview
Integration Services (SSIS) Catalog Architecture and API
Integration Services (SSIS) Projects
Integration Services (SSIS) Parameters
Integration Services (SSIS) Environment Variables
Integration Services (SSIS) Package Execution
Integration Services (SSIS) Project and Package Validation
Integration Services (SSIS) Security in SQL Server
Monitoring Operations in the Integration Services (SSIS) Catalog
Integration Services (SSIS) Catalog Identifiers