Extracción a Excel con SSIS

La verdad es que no había pensado en hacer una entrada sobre SSIS y la extracción a un XLS o XLSX. Esto es bastante straightforward pero recientemente recibí la llamada de un cliente que quería hacer esto teniendo un error al hacer el mapeo final. La solución es bastante sencilla para un usuario avanzado de Integration Services, pero me pareció mas que valido hacer este post detallando qué alternativas tenemos.

En este caso voy a realizarlo con la versión 2012 de SSIS y veran que el IDE es de Data Tools, pero es exactamente lo mismo en las versiones anteriores, al menos en 2008 y 2008R2.

Básicamente para reproducir la situación por la que me pidieron soporte solo necesitamos un DataFlow dentro de un paquete, obviamente.

Dentro del DataFlow solo agregamos un componente OLE DB Source y un objeto Excel Destination.

Paquete:

DataFlow:

Generalmente lo primero que suelo hacer en configurar el origen para que sea luego SSIS el que configure rápidamente el destino con sus mappings.

Antes les comento cual fue el inconveniente de esta persona. Se encontró con que quería hacer una extracción de una columna varchar de SQL Server hacia Excel. Entonces su instinto lo llevó a hacer manualmente el query dentro del Source, algo correcto. Luego lo unió con el Excel Destination y creo la hoja en el Excel Connection existente. Hasta ese momento estaba todo bien, el problema lo tuvo cuando intento realizar el mapping. El error que arrojaba estaba relacionado con los Unicode y Non-Unicode Data Types.

Microsoft en su motor de base de datos maneja tipos de dato de ambas clases. Excel en cambio solo maneja tipos de dato Unicode. Al ser incompatibles entre si aparece este error.

La solución es sencilla, simplemente el output del objeto OLE DB Source debía ser un tipo de dato unicode. Las opciones son aquellos llamados n*******.:

• nvarchar
• ntext
• ...

Pueden usar el que mejor se adapte al tipo de dato que tenían originalmente.

Una cosa importante, que tiene mas que ver con como se maneja SSIS. Si hicieron el OLE DB Source primero con el output en el Tipo de Dato incorrecto, al cambiarlo en el query no se actualiza automáticamente en el output de la tarea. Eso lo tiene que hacer manualmente en el Editor avanzado. Busquen el Output y van a ver que tiene el Tipo de Dato original, cámbienlo por Unicode.

La alternativa es borrar la tarea y regenerarla ya con la columna en Unicode.

Para este ejemplo utilice, con la idea de que sea mas visible, un objeto de conversión de tipos de datos. Donde en el mismo convertí el campo “Texto” a unicode.

Con esto ya no deberíamos tener inconveniente en el mapeo de campos en el destino.

Veamos el resultado de la ejecución y terminamos por esta vez.

Reporting, Excel o PerformancePoint?

Bueno, esta pregunta me la han hecho mucho y la verdad que la respuesta no es más que otra pregunta.. ¿Para qué lo queres? ¿Qué es lo que se quiere hacer?...
Como sabrán estos 3 componentes de Microsoft BI tienen la capacidad de mostrar la información almacenada en diferentes orígenes de datos (OLTP y OLAP). Entonces, si los 3 tienen la misma capacidad, porque no usar uno para todo? Bueno eso es posible y es lo he visto. Pero en realidad cada uno tiene una función debido a sus características particulares. Vamos a ir uno por uno charlado para qué lo usaríamos.


Reporting Services:

Esta herramienta de Microsoft viene integrada como componente del motor de bases de datos MSSQL Server. Apareció fuerte en la versión 2000 como un componente accesorio y luego en las versiones 2005 y 2008 es la herramienta de Reportes por excelencia para MS. Las características son las mismas que todo diseñador de reportes (Agrupación, Drilldown, etc.).
¿A quienes van dirigidos los resultados de los reportes? Bueno el resultado es algo mas operacional, la distribución de la información es a través de la web y es estática y generalmente fue realizada por una persona con conocimientos técnicos. El reporte no es una herramienta de análisis.
¿Se puede hacer un tablero de control en un reporte? Como poder se puede, el costo (Tiempo) de hacerlo es relativamente más alto que otras herramientas de MS.


Office Excel 2007:

Para poder trabajar con Excel es obvio que tenemos un requerimiento que no teníamos, la licencia de Office 2007. Si mal no recuerdo para estar 100% legal hay que tener una CAL de Office Enterprise. Pero esto se lo dejo a quien sabe.
Bueno… para que usamos Excel? Excel como lo conocemos sigue siendo una herramienta muy poderosa, es muy difícil llegar hoy a una empresa y que Excel no sea la herramienta Nro. 1 en el uso diario, tanto operacional como analítica. En esta última parte es donde Excel aplica como herramienta de Business Intelligence poderosísima. Es la herramienta de análisis principal, la que más a mano tiene cualquier usuario y claramente en la que más cómodo se siente, ya que para acceder a datos de un Data Mart solo se usa una tabla dinámica. Excel tiene conectividad nativa con Analysis Services, con lo cual, cada vez que se quieran ver datos nuevos solo hace falta actualizar.
Como dato importante y aclaratorio (me han preguntado este tema) los datos no se pueden modificar si se quiere mantener la conectividad a una base de datos.


PerformancePoint Sever:

Bueno, PPS es la herramienta de MS para el diseño de tableros de control. Lo bueno de este producto es que rápidamente se pueden tener tableros de control avanzados listos para implementar. Fácilmente se pueden relacionar indicadores con gráficos o grillas que muestren mayor detalle. Esta no es la primera versión de este tipo de productos, sino que ya existía el BSM (Business Scorecard Manager).
La desventaja de PPS es el licenciamiento, se requiere un Sharepoint Enterprise con las CAL correspondientes. Y un tema importante es que en mi experiencia no se pudo hacer que siempre tome el último día como default en una lista de días, ya que siempre se vuelve a que tome el último día seleccionado por el usuario. Con las demás herramientas siempre fue un problema pero se soluciona con algún artilugio, acá no hay más opción que acostumbrarse.
Acá estoy terminando mi primer post técnico/funcional. Espero que el próximo salga un poco mas rápido. Seguramente iremos poniendo temas más técnicos.


Saludos y gracias por la lectura!!

Entrada Presentación

Bueno, esta es mi primer entrada en el blog. Este blog que quizás no le dedique tanto tiempo como debería ser, pero que tiene la sana intensión de ayudar a gente. En que se preguntaran… bueno… en lo único que se hacer bien… que da la casualidad que vivo de eso…Business Intelligence.
Intentare ser lo más imparcial posible… pero les cuento que actualmente trabajo con herramientas de Microsoft y Business Objects, con lo cual dejo afuera muchas alternativas… Pentaho, MicroStrategy, TeraData, Cognos… etc… Cada una con más o menos características, componentes y funciones pero todas son aplicables a Business Intelligence.
Bueno, creo que como presentación está bien. Nos vemos en la próxima entrada.