23 julio 2012

Trabajando con varios motores de Scripting

Hola a tod@s!

En estos tiempos que corren hoy día, hay una palabra que suena bastante dentro del mundo de la consultoría informática. No, no estamos hablando de la maldita palabra crisis. Estamos hablando de la palabra transición.

Empresas que cierran, empresas que abren, empresas que se fusionan, etc, etc.. Y en medio de esta vorágine nos encontramos muchos de nosotros trabajando a destajo, automatizando lo que podemos y por qué no decirlo, automatizando lo que nos dejan.

En muchas ocasiones podemos encontrarnos en tipos de consultoría en donde se pretende pasar de una tecnología a otra. En otras ocasiones nos encontramos en sitios en donde el personal informático se ha cambiado por completo, y otras veces, por ejemplo, podemos encontrarnos ante empresas que quieren adoptar otro tipo de tecnología para automatizar tareas.

Estos ejemplos, de los que seguro que el lector se verá claramente identificado con alguno de ellos, implica la transición de “algo”. En el caso que nos ocupa, me gustaría hablaros de la automatización de tareas unitarias y repetitivas mediante tecnologías de scripting.

El chascarrillo que conté en la Rooted, en el que bromeaba con realizar tareas repetitivas con Batch frente a otros lenguajes de scripting, provocó una serie de comentarios en algunos casos a favor, en otros en contra, y que Lorenzo Martínez, acertadamente, publicó un artículo llamado Scripts de seguridad, qué lenguaje elegir?, que seguro hizo pensar a más de uno, entre los que me incluyo.

Uno de los mensajes que lanzaba Lorenzo se podía resumir con una frase como la siguiente: “Si a ti te funciona, estás cómodo, es de rápida implementación y se ejecuta eficientemente, debes usar ese”.

Habiendo (espero) puesto en antecedentes, imaginemos una pequeña historia.

Recread por ejemplo la siguiente situación. Qué pasaría si por ejemplo al cambiar de empleo, entras en una empresa en donde la automatización de tareas relacionadas con la seguridad o con cualquier otra disciplina se realiza en un lenguaje que a priori no controlas? Yo particularmente tengo una especie de “biblioteca” de scripts realizados en Python, PowerShell y BATCH (Con dos ·$%$!). Pero, y si al realizar una consultoría, o realizar un cambio de puesto de trabajo, me encuentro con la adopción de otra tecnología de la que no tengo la menor idea? Quiere decir esto que mi “biblioteca” de scripts ya no vale? Realmente la única opción es transigir?


Yo personalmente me las he visto y deseado en consultorías en donde el lenguaje predilecto era Perl, del cual no tengo ni la menor idea. Consultorías en donde tienes que realizar una tarea automática y que la relación horas-->coste-->persona no iban favor. Aunque la curva de aprendizaje sea poco elevada si dominas otros lenguajes de scripting, en la gran mayoría de ocasiones no vas a poder aprender un lenguaje de scripting al estilo Matrix. ¡Ojalá!



Podemos imaginar innumerables ejemplos. Para ayudar a la transición de un lenguaje obsoleto como BATCH a otros más potentes, o para integrar scripts que sean más eficientes en un entorno donde prima ya un motor, o para automatizar tareas utilizando la potencia de varios motores de scripting, en Windows existe una tecnología llamada Windows Script Host. Esta tecnología provee al sistema de opciones de automatización mediante un lenguaje independiente, y que implementa un modelo de acceso a objetos a través de una serie de interfaces (Component Object Model).



Entre las capacidades de esta tecnología se encuentra la de poder trabajar con varios lenguajes de scripting. Entre los lenguajes a los que se ofrece soporte, se encuentran Perl y Python por ejemplo, siempre y cuando se tengan instalados en el equipo los motores correspondientes.



Para ofrecer este soporte, la herramienta por línea de comandos CSCRIPT, proporciona un parámetro llamado IE, en el que se puede elegir el motor de script en función del fichero a pasarle como argumento.


Imagen 1.- Ejecutando código Perl desde CSCRIPT

Gracias a este tipo de soporte, se hace posible la utilización de varios motores en un script único. Lo único que tendríamos que hacer es realizar una llamada a la herramienta CSCRIPT, indicándole como parámetro extra el motor que necesitamos que utilice.

Si por el contrario tuviésemos la necesidad de ejecutarlo todo a través de un único script, o si desde una función en VBS (Visual Basic Script) necesitamos llamar a una función en Perl por ejemplo, Windows ofrece una tecnología llamada Windows Script File. A través de este fichero, es posible mezclar varios lenguajes de scripting en un único fichero, y ejecutarlo todo a través de la herramienta CSCRIPT por ejemplo. El modelo de fichero utiliza una jerarquía básica XML, en donde tendremos una serie de etiquetas disponibles para llamar a un motor u otro.

A continuación os dejo con un ejemplo utilizando para ello la inclusión de un script en VBS y otro en Perl, todo incluido en un único fichero WSF. Una vez ejecutada la función de VBS, éste llama a una función en Perl. Todo ello ejecutado a través de la herramienta CSCRIPT.



Imagen 2.- Ejecución de ficheros WSF a través de CSCRIPT

Si alguna vez tienes algún problema en decidir qué tipo de lenguaje elegir a la hora de automatizar alguna tarea, o tienes algún problema de “transición”, o piensas que el script que tienes en tu biblioteca es más eficiente que el que proponen, o quieres aunar varias tecnologías tomando lo mejor de cada una, Windows Scripting File es tu amigo.

Saludos a tod@s!

Contribución por Juan Garrido

2 comments :

silverhack dijo...

El código del fichero Windows Script File aquí:
http://pastebin.com/sNSEaF8i

Salu2!

Madrikeka dijo...

Que buen post!! y muy clarito!!

Voy a echarle un vistazo al código, a ver si me entiendo con él.

Un saludo.