Desplegar y agendar paquetes SSIS en el Catalogo

Es una tarea bastante sencilla pero siempre genera dudas, así que vamos a intentar aclarar como se hace el despliegue de un paquete y como se agenda, y algunos de los problemas que nos podemos encontrar.

Una vez creado un paquete creado en Visual Studio con SSIS necesitamos un catalogo al que subirlo. Como nota al pie os diré que antes los paquetes se podían subir a MSDB o al sistema de archivos, igual se puede hacer aún hoy, pero es un atraso y una complicación innecesaria. El catalog (-SSIS catalog-) es con mucha diferencia mucha mejor solución que sus predecesoras.

Entre otras ventajas se pueden configurar ambientes, cada ambiente puede asignar valores a cadenas de conexion y variables, además esos valores pueden ir cifrados si es necesario. Además genera versiones de los paquetes, de forma que ante un error en un despliegue siempre puedes volver atrás, y algunas otras más que no podemos desarrollar simplemente en el ámbito de un articulo como este.

Veamos primero donde se configura. Por si aún no lo habías notado, SQL Server Management Studio es el anillo único cuando se trata de administrar SQL-Server. así que configurar implica univocamente SQL Server Management Studio. Ahí vamos al Integration Services Catalogs y con botón derecho sobre el menú nos aparece crear catálogo. Yo ya lo tengo creado por lo que me resulta complejo mostraros la información, pero básicamente se configura un password para encriptar la información sensible y se habilita el uso del CLR para la ejecución de paquetes de SSIS a través de procedimientos almacenados.

Una vez configurado el catálogo ya podemos subir paquetes de varias formas distintas.

  • Generar un .ispac desde visual studio y desplegarlo con el SSIS Deployement Wizard
  • Desde el propio Visual Studio
  • Desplegando solo un paquete y no toda la solución

Generar un fichero .ispac

Para hacer esto en nuestra solución de SSIS vamos podemos pulsar el botón build (compilar), Build Solution. Podemos hacerlo a nivel de solución o a nivel de proyecto, dependiendo de si tenemos más de un proyecto o no. En cualquier caso en el directorio bin\xx donde xx es el entorno donde estemos trabajando (normalmente development ) encontraremos un fichero de extension .ispac. Ese fichero, para los mas curiosos, no es mas que un fichero comprimido en formato zip que contiene todos los paquetes de SSIS y algunos metadatos para su despliegue.

Normalmente la extensión .ispac ya se encuentra asociada al SSIS Deployment Wizard, pero siempre puedes buscarlo en las aplicaciones y abrir el fichero.  En resumen, podemos enviar ese fichero .ispac por nuestro mecanismo favorito a quien tenga que hacer el despliegue (incluso si somos nosotros mismos) y quien lo recibe simplemenete haciendo doble click recibirá un wizard en el que pide todos los valores de despliegue.

En otro artículo intentaré contar la parte de ambientes y su configuración, de momento aquí vamos a hacer el proceso más simple, subir los paquetes, y ejecutarlos.

Desplegar paquete

En esta primera pantalla vamos a ver que se puede seleccionar el fichero y si el origen es un catalogo (para mover paquetes de un catálogo a otro) o un proyecto (como en nuestro caso) que no es otra cosa que el fichero .ispac del que venimos hablando.

También podemos ver como nos permite seleccionar entre Project Deployment y Package Deployment. Bien , la diferencia es la que esperas, que se despliegue todo el proyecto o solamente un paquete de los que incluye, en cuyo caso hay que decir que paquetes. Yo no suelo usar esta opción, pero no es por nada en especial, solamente por la forma en la que suelo trabajar con esta herramienta.

Cuando se pulsa siguiente, se valida los paquetes, que todo esté correcto y pide el destino.

En el path podemos usar el botón browse para crear nuevas carpetas y de esa forma organizar nuestros proyectos y despliegues en carpetas del catalogo.  Despues de esto, poca cosa hay que hacer puesto que simplemente muestra un resumen de la operación que se va a hacer y posteriormente hace el desplieuge mostrando el avance como puede verse en la siguiente figura

Al acabar simplemente podemos acercarnos a nuestro menú catalog en SQL Server Management studio y comprobar que nuestro proyecto está desplegado

y ahí simplemente botón derecho sobre cualquier paquete y ejecutar.

Agendar un job

También podemos agendar en un job el paquete para que se ejecute. Para ello simplemente en el step del job decimos que es de tipo SQL Server Integration Services Package, indicamos en que servidor está el catálogo y que paquete es el que hay que ejecutar y generamos el agendado como cualquier otro paquete.

El menú que aparecerá será el que puede verse en la siguiente figura.

Si nos fijamos en la figura el job se ejecutará bajo las credenciales del SQL Server Agent Service Account. Esto es el primer reto que se puede encontrar toda persona «nueva» en el mundo del agendado. El paquete puede funcionar en Visual Studio, y cuando vas a agendarlo no funciona ¿porqué? pues porque cuando lo ejecutas en Visual Studio, corre con tus credenciales, mientras que cuando lo ejecuta el agente corre con las credenciales que tenga el propio SQL Server Agent (las de la cuenta que levanta el servicio) y puede que no sean suficientes.

¿y cual es la solución? Pues hay 2 soluciones

  • Asignar permisos suficientes al agente.
  • Crear un proxy con un usuario que si tenga esos permisos y asignar la ejecución a ese proxy.

Para la primera parte no creo que se necesite mucha ayuda, básicamente, averigua cual es la cuenta con la que se ejecuta el agente (puedes mirarlo en los servicios) y después asigna los permisos a esa cuenta, ya sea en directorios de Windows, rutas compartidas o bases de datos.

Para crear el proxy sin embargo hay un poquito mas de trabajo

  1. Crea unas credenciales  que tenga los permisos suficientes (puede ser un usuario de windows) como puedes ver en la figura siguiente – se hace desde el módulo de seguridad, menú Credentials, crear nueva credencial. Puedes encontrar el menú en SQL Server Management Studio.
  2. Crea el proxy. para eso, dentro del SQL Server Agent, Proxies, SSIS package Execution, new proxy y asigna las credenciales creadas como puedes ver en la siguiente figura
  3. En el paso del job, selecciona la cuentra proxy adecuada para la ejecución del paquete como puedes ver en la siguiente figura.

Conclusiones., Aunque hemos visto solamente los pasos más básicos sin entrar en detalles de configuración podemos empezar a desplegar nuestros paquetes de SSIS y conseguir que se ejecuten sin problemas de permisos. En breve publicaremos un artículo, también introductorio sobre como se crean estos paquetes.

Saludos

 

 

 

Deja un comentario

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