Windows PowerShell: Un gran parecido con los flujos de trabajo

Durante este año, Don Jones presentará todos los meses la entrega de un tutorial en 12 partes sobre los flujos de trabajo de Windows PowerShell. Le recomendamos que lea la serie en orden, empezando por el columna de enero 2013.

Don Jones

Flujos de trabajo apariencia mucho como funciones de Windows PowerShell o secuencias de comandos, pero no lo son. Esa similitud es sólo superficial, y tal vez incluso que no extienda completamente a través de la piel.

Hay que recordar siempre que Windows PowerShell debe traducir los flujos de trabajo en una tecnología totalmente separada, Windows Workflow Foundation (WF). Eso significa que sólo se pueden hacer cosas que pueden ser reproducidas en WF. Entonces, su código se ejecutará en un tipo diferente de medio ambiente que tiene sus propias reglas y restricciones.

Ejecutar cualquier script como un flujo de trabajo

La forma más fácil de ejecutar un flujo de trabajo es simplemente ejecutar cualquier script de Windows PowerShell estándar como un flujo de trabajo. Usted puede hacer esto con el comando Invoke-AsWorkflow. Este comando se vive en el módulo PSWorkflow, aunque Windows PowerShell versión 3 deben ser capaces de descubrir y ejecute el comando sin tener que cargar explícitamente el módulo primero. Este comando ajusta esencialmente el guión entero en un bloque de JSON, lo que significa que funciona dentro de WF como un solo paso.

Eso significa que no tienes que preocuparte mucho por las restricciones del flujo de trabajo de Windows PowerShell. Sin embargo, también no llegar a tomar ventaja de ciertas características de flujo de trabajo de Windows PowerShell, como la posibilidad de reanudar un proceso interrumpido. El "proceso", en este caso, estará conformado el guión entero en un solo paso. No hay forma de retomar a medio camino a través de si tienes que hacer una pausa o interrupción. Este es un ejemplo, en la que he creado un bloque de script con algunos comandos y luego ejecutarlos como un flujo de trabajo:

$script = { $name = Get-Content Env:\COMPUTERNAME $name | Out-File c:\MyName.txt Get-Service } Invoke-AsWorkflow -Expression $script -PSComputerName DC,CLIENT

He utilizado una variable aquí una de las razones era demostrar que WF todo esto funciona como una sola JSON. Tenga en cuenta que cada comando WF ejecuta obtiene su propio, ambiente fresco. No hay ninguna manera incorporada para conservar los datos entre los comandos. Eso significa variables son nativo bastante inútiles. Sin embargo, porque todo esto se envuelve implícitamente como JSON de un solo paso, la variable creé persistirá a lo largo.

Así que, ¿por qué te molesta? Flujo de trabajo de Windows PowerShell todavía le da unas ventajas adicionales. Hay un cierto número de parámetros compartidos por todos los flujos de trabajo. Éstos permiten especificar cosas como nombres de la computadora de destino y así sucesivamente. El script va a heredar una infraestructura básica para el trabajo de 16.3. Para los scripts de larga duración, puede poner en marcha un flujo de trabajo, luego desconecte el equipo remoto, mientras que el flujo de trabajo continúa funcionando, que es bonito.

Sintaxis formal del flujo de trabajo

Aquí es un flujo de trabajo muy sencillo:

Workflow New-Server { Get-Content -Path Env:\COMPUTERNAME | Out-File -FilePath C:\MyName.txt Get-NetAdapter -Physical } New-Server -PSComputerName CLIENT,DC

Flujos de trabajo son una especie de comando de Windows PowerShell, como un cmdlet, script o función. Es el caso, usted puede ejecutarlos simplemente llamando su nombre, como lo he hecho en la última línea de este ejemplo. Recuerde, todos los flujos de trabajo heredarán un cierto número de parámetros incorporados como –PSComputerName. Flujos de trabajo también dependen de la función de Windows PowerShell Remoting, que está habilitada en ambos equipos en este ejemplo.

El resultado práctico es que ambos mandos del flujo de trabajo se están funcionando bien en los equipos remotos, con los resultados, volviendo a mi ordenador. No tengo nada de eso código o incluso crear un parámetro de nombre de equipo. No necesito enumerar los nombres de equipo, crear conexiones o cualquier otra cosa. Flujo de trabajo de Windows PowerShell hace todo para mí. No hay absolutamente nada en esta secuencia de comandos que no podía han conseguido sin flujo de trabajo de Windows PowerShell, sólo haría falta un poco más de trabajo de mi parte.

Usted notará que he detalla los nombres de comando en mi flujo de trabajo. También he utilizado parámetros con nombre en cada instancia. Siempre es una mejor práctica en cualquier secuencia de comandos de Windows PowerShell, pero es obligatorio en un flujo de trabajo. Se pueden utilizar parámetros posicionales. Tienes que explicar todo u obtendrá un error.

Ahora si deseas este flujo de trabajo (no es que usted tendrá que importar la sesión de PSWorkflow a su instancia de shell en orden para la palabra clave "Workflow" ser legal):

Workflow New-Server { $name = Get-Content -Path Env:\COMPUTERNAME Get-Content -Path Env:\COMPUTERNAME | Out-File -FilePath C:\MyName.txt Get-NetAdapter -Physical $name | Out-File -FilePath C:\MyOtherName.txt } New-Server -PSComputerName CLIENT,DC

Cuando primero escribí este ejemplo, pensé, "MyOtherName.txt estará vacía". Recuerde que el contenido del flujo de trabajo cada ejecuta como un comando separado, con ningún contexto compartido entre ellos. Cuando me encontré este ejemplo, sin embargo, funcionó. El nombre del equipo fue escrito hecho a MyName.txt y MyOtherName.txt. ¿Qué pasa?

Windows PowerShell realmente hace un montón de cosas bajo el capó para tratar de asegurarse de que obtendrá los resultados que usted espera de un flujo de trabajo. Por ejemplo, se escribe un comando de "normal" de flujo de trabajo de una manera muy específica. WF nativamente no puede ejecutar a cualquier edad cmdlet de Windows PowerShell. El equipo de Windows PowerShell ofrece equivalentes WF para una enorme lista de cmdlets nativos, por lo que a menudo hay una asignación unívoca entre cmdlets y actividades WF.

Cuando usas un cmdlet que no tiene una actividad correspondiente, Windows PowerShell implícitamente ajusta el código dentro de una actividad de WF JSON. Tiene el efecto de hacer WF ejecutar Windows PowerShell, ejecutar el comando dentro de Windows PowerShell y luego retomar los resultados en WF. Así que un montón de cosas que "no deberían" trabajar funcionará, porque Windows PowerShell hacks lo juntos para usted.

El peligro es que problemas pueden ser increíblemente difícil, porque no siempre serás capaz de ver lo que Windows PowerShell está haciendo bajo el capó. En el caso de este ejemplo, Windows PowerShell asegura que las variables de nivel superior persisten a lo largo del flujo de trabajo.

Donde vamos siguientes

Créalo o no, ya tienes suficiente para comenzar a escribir los flujos de trabajo básicos. Usted puede tener estos apuntar cualquier ordenador donde hayas instalado Windows PowerShell versión 3 y habilitado Remoting. Parte de la razón para permitir la comunicación remota es que crea una configuración de sesión que utiliza el flujo de trabajo de Windows PowerShell. Si has activado la comunicación remota en un ordenador con Windows PowerShell versión 2 y luego instala la versión 3, usted querrá volver a ejecutar Enable-PSRemoting para crear la configuración necesaria.

Mantenga sus flujos de trabajo bastante simple. Ejecutar una secuencia de comandos y no hacer muchas maniobras de lujo. Usted no debería tener ningún problema, y usted conseguirá aprovechando el Remoting de flujo de trabajo integrado de Windows PowerShell, targeting 16.3 y otras características.

El mes que viene, voy a empezar consiguiendo más complicado. Te miro las profundas diferencias entre un flujo de trabajo y una secuencia de comandos de Windows PowerShell normal y comenzar a explorar algunas de las posibilidades más interesantes de flujo de trabajo de Windows PowerShell.

Don Jones

Don Joneses un ganador del premio MVP de Windows PowerShell y editor colaborador para la TechNet Magazine. Él ha coautor de cuatro libros sobre Windows PowerShell versión 3, incluyendo varios títulos libres en la creación de informes HTML en Windows PowerShell y Windows PowerShell Remoting. Encontrarlos todos en PowerShellBooks.com, o Jones su pregunta en los foros de discusión en PowerShell.org.

Contenido relacionado