Mes: diciembre 2006

Uno de los puntos de SSIS que muchas veces nos pasa desapercibido y que sin embargo conviene conocer, utilizar y amar, es el soporte para transacciones. Estamos cargando un DataMart, y ¡zas! la carga falla a mitad de camino. ¿Qué hacemos? ¿Parece mentira que la ejecución de un ETL que puede hacer infinidad de cambios en nuestro DataMart se pueda deshacer en caso de fallo, verdad? ¡Pues se puede!

Para controlar las transacciones, todos los objetos del «Control Flow» (incluido el propio control flow) tienen una propiedad llamada «TransactionOption», que puede tomar los siguientes valores:

• Required: Este elemento se ejecuta en el contexto de una nueva transacción.


• Supported: El elemento se ejecuta en el contexto de la transacción que ya estuviese abierta (por alguno de sus «padres»). En caso de que no se hubiese iniciado ninguna transacción, el objeto no es transaccional. Es el valor por defecto que da Integration Services a todos los elementos del flujo de control.


• NotSupported: El objeto no es transaccional, aunque esté ejecutándose en el contexto de una transacción

 

Entonces, hacer un ETL transaccional es tan sencillo como pulsar en el fondo del «Control Flow» de un paquete y establecer TransactionLevel a «Required». Eso hará que todos los elementos que arrastremos al flujo se ejecuten por defecto en el contexto de una transacción. Si uno de estos elementos falla, se desharán los cambios realizados por el resto de elementos que se hubiesen ejecutado dentro de la misma transacción.

El segundo parámetro a tener en cuenta es IsolationLevel, que especifica cómo gestionará SSIS la transacción. Podéis buscar información en MSDN sobre este parámetro… yo sólo os dejo caer un par de notas:

• Cuanto menos restrictivo sea el modo de funcionamiento de la transacción, mayor será el rendimiento. Por ejemplo, ReadUncommited y Chaos permiten ver los cambios antes de que estos se hagan permanentes con un Commit. O sea, que si estamos cargando un DataMart y mientras tanto alguien accede al mismo, obtendrá datos inconsistentes. Si nuestras circunstancias permiten «evitar» el acceso al DataMart mientras esté siendo cargado, puede ser una buena opción.


• Serializable es el más restrictivo, pero a la vez más seguro: evita que se pueda acceder a los datos nuevos que insertemos en el DataMart hasta que se haga un Commit, y evita que se modifiquen los datos anteriores al inicio de la transacción. Generalmente es el más adecuado para cargar un DataMart (es la opción por defecto). 


• Snapshot es nuevo en SQL Server 2005, y permite trabajar a la transacción sobre una «copia» de los datos tal y como estaban al inicio de la transacción, sin bloquearlos. Al finalizar la transacción, se consolidan los cambios. Esta es la que menos impacto supondrá en el resto de aplicaciones que accedan al DataMart mientras lo estamos cargando, pero a costa de usar parte de nuestro espacio de almacenamiento. Personalmente no le veo demasiado uso en la carga de un DataMart, porque por su propia naturaleza, los datos del DataMart no suelen sufrir modificaciones (por lo que Serializable puede ser una mejor opción)

Espero que después de esto en vuestras oficinas dejen de oirse gritos y lamentos debido a ese corte de luz que sucede siempre justo en medio de la ejecución de un ETL…

Y ya sabés, feliz navidad…. ¡y prósperas transformaciones!

Hay dos cosas que me pierden: el merchandising de los eventos de Microsoft, y casi todo lo nuevo que voy probando. Sí, si, lo se… soy un poco «pattern happy», un poco amante de los gadgets y muy, muy «friki» (en el sentido más puramente hispano de la palabra). Actualmente me está atrayendo poderosamente la idea de las Software Factories y los Domain Specific Languajes (DSL). Me atrae tan poderosamente que, como me conozco, empiezo a dudar sobre si lo que me atrae es real, o son cantos de sirena.

¿Software factoqué?

Cuando el famoso cocinero de la tele nos prepara un delicioso Marmitako, o nos deleita con una chuletitas de cordero ricas, ricas, ricas… nos está enseñando una receta. Nos da un conjunto de pasos, técnicas y conocimientos, que nos ayudan a triunfar en un determinado dominio: la cocina. Digamos que la distancia para sorprender a nuestra churri, es más corta si seguimos una receta que si tratamos de improvisar en los fogones.

Una Software Factory sigue el mismo principio: es un conjunto de patrones, documentación (recetas), plantillas y mucha, mucha, mucha… ¡generación automática de código! Personalmente estoy usando la Smart Client Software Factory, que te ayuda a desarrollar Smart Clients que se sustentan sobre Composite UI Application Block (CAB).

Vale, eso tiene sentido… ¿y los DSL?

Las Software Factory casi siempre van de la mano de los DSL, o «Domain Specific Languajes». ¿Te imaginas que el programa de Arguiñano se hiciese en el plató de Bricomanía? ¿Sería raro, verdad? Cada situación requiere un conjunto distinto de herramientas, y cada dominio, un lenguaje adaptado a su contexto. El problema de los lenguajes de propósito general, es que son como el plató de Bricomanía… por el simple hecho de que tengamos una sierra de calar, podemos sentir la tentación de usarla para trinchar el pavo. La solución para evitar el error, es deshacerse de la sierra de calar.

Hace poco, alguien, tratando de hacerme bajar de mi nube, me decía que hace 20 años que tratan de vendernos los lenguajes de 4ª generación, y me insinuaba que esto es el mismo perro con distinto collar. Bueno, en cierto modo los DSL se parecen a los 4GL en que buscan ser declarativos (yo digo lo que quiero, y no cómo lo quiero) pero no pretenden ser tan ambiciosos. Ciñéndose a un dominio, es más fácil tener éxito con un lenguaje declarativo.

Lo cierto es que cada vez que abrimos el diseñador de interfaces de Visual Studio, ya estamos usando un DSL. Nosotros añadimos controles a un formulario y enlazamos eventos con código usando un lenguaje visual, basado en el paradigma de arrastrar y soltar. Lo mismo ocurre cuando desarrollamos un ETL con Integration Services… los DSL llevan años acompañándonos.

En algunos casos, el DSL ni siquiera requiere que se abandone el lenguaje de propósito general… simplemente, se limita a ocultar la complejidad del mismo, y nos guía para que sólo utilicemos aquella parte del lenguaje adecuada a nuestros fines. Llevamos años encapsulando para tratar de ocultar la complejidad… ¿por qué somos tan reacios a que una herramienta nos abstraiga del propio lenguaje procedural?

Lo pasamos por la batidora, y directo al horno (220ºC)

Microsoft nos está preparando un buen plato a base de DSLs, patrones, Software Factories y demás ingredientes. Los muchachos se llaman GAX, GAT (Guided Automation Extensions y Guided Application Toolkit, respectivamente) y DSLTools y están a punto de llegar a este lado del Mississippi.

Esta pretende ser una revolución en la forma en la que desarrollamos software. Paremonos a pensar en la mayoría de ISVs y sus catálogos de software… es habitual que los ISV se especialicen en un dominio, ¿verdad? Los hay quienes hacen herramientas de desarrollo, software de tratamiento de imágenes, productos de seguridad… pero generalmente, igual que cada cabra tira a su monte, cada ISV va a su terreno. Luego hay consultoras capaces de hacer de todo (hasta botijos, si estuviesen bien pagados), pero bueno, estamos hablando de desarrollo de software, y no de tratantes de carne humana (huy lo que he dichoooooo…), y estoy seguro que hasta éstas pueden beneficiarse de las Software Factories.

Imaginaos este mundo idílico, en el que nuestro arquitecto desarrolla la Software Factory adecuada a nuestro dominio, y nuestros desarrolladores la utilizan para programar aplicaciones específicas para el dominio. ¿Acaso no es una forma estupenda de transferir el conocimiento?

¡Camarero una manzanilla!

Para acabar sin indigestión, os voy a recetar un poco de descanso (a poder ser en vuestro sofá más cómodo) y cuando vuestro cerebro pida guerra, unos cuantos links:

• Tom Hollander’s blog: Habla mucho sobre GAT y GAX, y también da noticias sobre nuevos «application blocks»


• Matias Woloski: Sobre todo habla de la Smart Client Software Factory


• Patterns & Practices: Software Factories: Noticias sobre las software factories de Microsoft.

Y ahora, ya puedes opinar… ¿Estamos hablando de la Piedra Rossetta del desarrollo de software, o son cantos de sirena?