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.
Referencias
Deployment of Projects and Packages
Convert and Deploy Projects
