Una vez que hemos creado y depurado un paquete de Integration Services (SSIS), debemos proceder a desplegarlo sobre el servidor, o posiblemente sobre varios servidores. Es habitual encontrarse con entornos de desarrollo, pruebas, preproducción y producción. En cada uno de ellos, los orígenes y destinos de nuestros datos pueden ser diferentes. La primera alternativa que tenemos es editar con BIDS (Business Intelligence Developement Studio) cada uno de estos paquetes en el servidor correspondiente y actualizar los valores de las propiedades de cada uno de los componentes que accedan a datos para que lo haga sobre el servidor que corresponda y con el usuario y password que tiene en dicho servidor. Esto puede ser una tarea pesada y repetitiva, y sobre todo poco flexible. Lo ideal es que este tipo de información sea independiente del paquete y se pueda cambiar sin necesidad de abrir dicho paquete y sin el uso de herramientas como Visual Studio.
Para ello, tenemos la configuración de paquetes SSIS, que nos permite actualizar las propiedades que indiquemos previamente, durante su ejecución. Con esto obtendremos una serie de ventajas que harán que el mover los paquetes entre diferentes servidores, o incluso el que cambie un origen o un destino de los datos, lo podamos gestionar sin tener que editar el paquete con Visual Studio. Además hay que tener en cuenta que en muchas ocasiones quien gestiona dichos paquetes es un DBA o un operador que no tiene porqué estar familiarizado con herramientas de desarrollo, ni tiene porqué conocer en contenido del paquete.
Con dicha configuración de paquetes, conseguimos que para cualquier cambio de los citados anteriormente, como por ejemplo, el paso de un entorno de desarrollo a otro de producción, sea mucho más simple, ya que sólo tenemos que acceder a la configuración y cambiar las cadenas de conexión. Por otro lado, podemos obtener una mayor flexibilidad, por ejemplo, podríamos cargar estos valores en variables y utilizarlos en un script task.
A la hora de almacenar esta configuración, tenemos diversas alternativa
s: archivos XML, variables de entorno, en el registro de Windows, en la configuración del paquete padre, o en una tabla de SQL Server. En este artículo, nos vamos a centrar en el almacenamiento en archivos XML y en tablas de SQL Server, en cualquiera de ellos podemos almacenar en un solo archivo o tabla la información de múltiples paquetes.
Los archivos XML son muy flexibles, pero en contraposición pueden ser fácilmente accesibles con cualquier editor, lo que puede suponer algún riesgo adicional para la información que contienen. Por supuesto que podemos tomar todas las medidas de seguridad que tenemos en el sistema de archivos. Otra alternativa es almacenar la información en una tabla de SQL Server, lo que supone un trabajo mínimo, aunque es algo menos flexible que los archivos XML, por ejemplo, si lo que necesitamos es cambiar la ubicación de dicha tabla de configuración (pasarla a otra base de datos, o pasar la base de datos donde se encuentra a otro servidor) el paquete dejará de funcionar correctamente.
Una buena alternativa, que une las ventajas de ambas formas de almacenamiento, es crear un archivo XML en el cual no se almacenará información sobre los orígenes y destinos de datos que necesita el paquete, ni cualquier otra información de configuración que necesitemos almacenar. Simplemente se almacenará la cadena de conexión a la base de datos de configuración. Y ya en la tabla de SQL Server, se almacenará el resto de información de configuración del paquete, con todas las ventajas de seguridad que tenemos que tenemos en el servidor, control de acceso a la base de datos, a la tabla y a las filas de ésta, así como la posibilidad de usar certificados, encriptación, etc.
Figura 1. Acceso a datos de configuración
En los siguientes posts expondremos un ejemplo concreto y cómo implementar su despliegue, incluyendo todo lo que hay que hacer paso a paso.
