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

Expression Task para Integration Services en 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.

 

 

Entre las novedades en la versión de SQL 2012 de Integration Services se ha añadido una nueva tarea que podemos utilizar en el Control Flow

Expression Task

Permite la evaluación de expresiones y asignación de valores a parámetros y variables.

Vamos a ver dos ejemplos:

---

Supongamos que tenemos un parámetro CSVOrigen en nuestro paquete que nos informa de la ruta donde se encuentra un fichero CSV.

[$Package::CSVOrigen] = C:\RespositorioFicheros\CSVOrigen.csv

Durante la ejecución del paquete si surge algún error al leer del fichero, las filas erróneas debemos redirigirlas a la misma carpeta que el origen (C:\repositorioFicheros\). A través de la Expression Task vamos a extraer el directorio de la ruta del archivo a la variable RutaFicheros.

La siguiente expresión obtiene la carpeta de la ruta de origen almacenada en el parámetro CSVOrigen:

(LEFT( @[$Package::CSVOrigen] , LEN( @[$Package::CSVOrigen]  ) - FINDSTRING(REVERSE( @[$Package::CSVOrigen] ),"\\",1) +1 ))

Como se puede observar, hacemos uso de la nueva función Left() de la que hablamos en el artículo anterior.

Ahora, si introducimos la expresión en la Expression Task y lo asignamos a la variable RutaFicheros, quedaría como muestra la imagen:

---

Otro ejemplo sencillo puede ser obtener el tiempo de ejecución de un componente. Colocamos el componente al que queremos medir en un contenedor y conectamos un Expression Task, como se muestra en la imagen. Le añadimos la expresión:

@[User::TiempoEjecucion] = Datediff("ms", @[System::ContainerStartTime], getdate())

Podemos añadir un Breakpoint en el evento Post-Execute de la tarea y rescatar el valor de la variable en la ventana Watch 1:

---

Conclusiones

Expression Task nos permite asignar valores a parámetros y variables durante la ejecución del paquete, además de poder organizar en que momento del Control Flow debe realizarse. Anteriormente podíamos hacer algo similar con las variables y la propiedad EvaluateAsExpression pero la expresión se resolvía en primera instancia, no podíamos decidir cuando sin usar una Script task.

 

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

Nuevas funciones para el lenguaje de expresiones de SSIS en SQL 2012

Este artículo pertenece a la serie “Novedades de Integration Services en SQL 2012”.

El lenguaje de expresiones de Integration Services podemos utilizarlo en columnas derivadas, expresiones en propiedades de componentes, tareas, administradores de conexión, variables, en la nueva Expression Task, etc… Tiene su propia sintaxis, operadores, conjuntos de funciones, etc.. (se observan similitudes con las expresiones de C++). En la versión de SQL 2012 se han agregado tres nuevas funciones que se engloban en el conjunto de funciones para el tratamiento de cadenas: Left, Token y TokenCount.

LEFT(<expression>, len): Obtiene de la cadena pasada como primer parámetro un segmento con la longitud del número de caracteres expresados como segundo parámetro, partiendo de la parte izquierda de la cadena.

Left(“Podemos recortar por la izquierda”,7) => “Podemos”

A modo de recordatorio, mencionar que en versiones anteriores se puede conseguir el mismo efecto de varias formas:

Substring(<expression>,start, len): Esta función recoge un sub segmento de la cadena pasada como primer parámetro, pudiendo indicar en que carácter debe comenzar (parametro start) y que longitud tomar (parámetro len), para conseguir el mismo resultado que en ejemplo con Left():

SubString(“Podemos recortar por la izquierda”,0,7) => “Podemos”

Reverse(Right(Reverse(<expression>),len)): Es algo enrevesado, pero se consigue el mismo resultado utilizando esta combinación de funciones Reverse(<expression>) y Right(<expression>,len):

Reverse(Right(Reverse("Podemos recortar por la izquierda"),7)) => “Podemos”

Script component: Por supuesto, podemos utilizar todas las funciones para el tratamiento de cadena existentes en C# o VB.NET a través de los componentes Script que nos permiten escribir código y referenciar ensamblados.

TOKEN(<expression>,delimiter, ocurrence): Obtiene el segmento de una cadena que se encuentra entre los delimitadores definidos en el segundo parámetro. El tercer parámetro indica que ocurrencia debe tomar. Funciona de forma similar a un Split, pero en lugar de devolver un array con todas las ocurrencias, devuelve solo la ocurrencia indicada. Por Ejemplo

TOKEN( "c:\\rutaFicheros\\Carpeta 01\\Fichero 01.csv", "\\",2) => “rutaFicheros”

El delimitador del Token es carácter “\” por lo que se encuentran los siguientes Tokens en el ejemplo:

1. c:

2. rutaFicheros

3. Carpeta 01

4. Fichero 01.csv

Este comportamiento es mas complicado de simular en versiones anteriores utilizando el lenguaje de expresiones. Sin embargo, si en un Script Task escribimos lo siguiente:

string Cadena = "c:\\rutaFicheros\\Carpeta 01\\Fichero 01.csv"
string[] Tokens = Cadena.Split('\\');
System.Windows.Forms.MessageBox.Show( Tokens[1].ToString());

Nos devuelve el mismo resultado que la función Token():

TOKENCOUNT(<expression>,delimiter): Devuelve el numero de tokens, utilizando el delimitador que se pasa como segundo parámetro, que se encuentran en una cadena que se analiza en el primer parámetro. Siguiendo el ejemplo anterior:

TOKENCOUNT( "c:\\rutaFicheros\\Carpeta 01\\Fichero 01.csv", "\\") => 4

Para buscar una alternativa tendríamos que acudir a una tarea o componente Script:

string Cadena= "c:\\rutaFicheros\\Carpeta 01\\Fichero 01.csv"
string[] Tokens = Cadena.Split('\\');
System.Windows.Forms.MessageBox.Show(Tokens.GetLength(0).ToString());

Que nos daría el mismo resultado:

 

Conclusión

La inclusión de estas sencillas funciones en el lenguaje de expresiones nos ahorrará en algunos casos la inclusión de código a través de tareas y componentes Script.

 

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

Novedades en Integration Services de SQL 2012

 

Introducción

En la nueva versión de SQL 2012 se producen varios cambios importantes en Integration Services. El más relevante es el cambio de arquitectura en el servidor. En versiones anteriores el repositorio nativo para Integration Services se almacenaba en la base de datos MSDB que contenía las tablas necesarias para almacenar los paquetes y estructura del repositorio, procedimientos almacenados para la gestión de los paquetes, etc.. En SQL 2012 se mantiene compatibilidad con esta arquitectura para los proyectos de modelo de despliegue legado (Legacy deployment model):

Y que aporta la nueva arquitectura de servidor? El nuevo modelo de despliegue proyecto (Project deployment model) conlleva algunos cambios importantes:

1. Desaparecen las configuraciones y aparecen parámetros, a nivel de paquete y de proyecto con la misma intención (dinamizar propiedades de tares y componentes) con mayor flexibilidad y quedando integrado en el entorno de administración de Integration Services.
2. La unidad de despliegue pasa a ser el proyecto en lugar del paquete DTSX, y se genera un sólo archivo (.ISPAC) para importar, migrar, desplegar…
3. Posibilidad de crear Entornos en el servidor para la asignación de valores a parámetros
4. Nuevo base de datos SSISDB con una API T-SQL para la configuración, administración y ejecución de paquetes que gestiona el catálogo SSISDB.
5. Integration Services pasa a administrase desde el árbol de objetos del Motor de Base de Datos.
6. Versionado de proyectos  
7. Aparición de Dashboard

A nivel de desarrollo también han habido cambios y evoluciones. El principal y más notable, y quizás el que más vamos a agradecer los desarrolladores, es que el entorno de desarrollo es Visual Studio 2010. Sí, la shell de BIDS es Visual Studio 2010, el área de diseño es WPF y en las tareas Script y componentes Script (Control Flow y Data Flow, respectivamente) podremos referenciar ensamblado de .Net Framework 4.0. También ha habido mejoras en el XML que define el paquete DTSX, ahora es un XML well-formed legible y entendible. Disponemos de nuevas tareas y componentes (Expression Task, DQS cleansing, Asistentes para orígenes y destinos) y más funciones para el lenguaje de expresiones de SSIS (Left, Token y TokenCount). Se han implementado ayudas visuales que nos facilitan la localización de elementos condicionados por expresiones (administradores de conexión, variables, precedencias, etc…)

Hay bastantes cosas de las que podemos hablar así que para no alargar mucho este primer artículo vamos a seccionarlo en varios:

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

Mantente ‘sintonizado’ para las siguientes entregas