Conceptos de flujo de trabajo de Windows PowerShell

Importante

Esta versión de Service Management Automation (SMA) ha alcanzado el final del soporte técnico. Se recomienda actualizar a SMA 2022.

Un tipo de runbook para Service Management Automation se basa en flujos de trabajo de Windows PowerShell. En este artículo se proporciona una breve introducción a las características críticas de los flujos de trabajo que son comunes a los runbooks de Automation. Encontrará información detallada y completa sobre los flujos de trabajo en Introducción al flujo de trabajo de Windows PowerShell.

La estructura de los runbooks es idéntica en los runbooks para Service Management Automation y los de Microsoft Azure Automation, si bien ambos funcionan con recursos diferentes.

Flujos de trabajo de Windows PowerShell

Un flujo de trabajo es una secuencia de pasos conectados y programados que realizan tareas de larga duración o requieren de la coordinación de pasos múltiples a través de varios dispositivos o nodos administrados. Las ventajas de un flujo de trabajo en un script normal incluyen la capacidad de realizar una acción en varios dispositivos simultáneamente y la capacidad de recuperarse automáticamente de los errores. Un flujo de trabajo de Windows PowerShell es un script de Windows PowerShell que usa Windows Workflow Foundation. Aunque el flujo de trabajo se escribe con Windows PowerShell sintaxis y se inicia mediante Windows PowerShell, Windows Workflow Foundation lo procesa.

Estructura básica

Un flujo de trabajo de Windows PowerShell se inicia con la palabra clave Workflow, seguida del cuerpo del script cerrado entre llaves. El nombre del flujo de trabajo sigue a la palabra clave Workflow , tal como se muestra en la sintaxis siguiente. El nombre del flujo de trabajo coincide con el nombre del runbook de Automation.

Workflow Test-Runbook
{
   <Commands>
}

Para agregar parámetros al flujo de trabajo, use la palabra clave Param, como se muestra en la sintaxis siguiente. El portal de administración solicitará al usuario que indique los valores para estos parámetros cuando inicie el runbook. En este ejemplo se usa el atributo Parameter opcional, que especifica si el parámetro es obligatorio o no.

Workflow Test-Runbook
{
  Param
  (
   [Parameter(Mandatory=<$True | $False>]
   [Type]$<ParameterName>,

   [Parameter(Mandatory=<$True | $False>]
   [Type]$<ParameterName>
  )
  <Commands>
}

Nomenclatura

El nombre del flujo de trabajo debe ajustarse al formato verbo-sustantivo estándar en Windows PowerShell. Para obtener una lista de los verbos aprobados que se pueden usar, vea Approved Verbs for Windows PowerShell Commands (Verbos aprobados para los comandos de Windows PowerShell) . El nombre del flujo de trabajo debe coincidir con el nombre del runbook de Automation. Si se va a importar el runbook, el nombre de archivo debe coincidir con el nombre del flujo de trabajo y debe terminar en. ps1.

Limitaciones

Para obtener una lista completa de limitaciones y diferencias de sintaxis entre flujos de trabajo de Windows PowerShell y Windows PowerShell, consulte Diferencias sintácticas entre los flujos de trabajo de scripts y los scripts.

Actividades

Una actividad es una tarea específica de un flujo de trabajo. Al igual que un script se compone de uno o varios comandos, un flujo de trabajo se compone de una o varias actividades que se realizan en secuencia. El flujo de trabajo de Windows PowerShell convierte automáticamente muchos de los cmdlets de Windows PowerShell en actividades cuando se ejecuta un flujo de trabajo. Cuando se especifica uno de estos cmdlets en el runbook, Windows Workflow Foundation ejecuta realmente la actividad correspondiente. En el caso de los cmdlets sin una actividad correspondiente, Windows PowerShell Flujo de trabajo ejecuta automáticamente el cmdlet dentro de una actividad InlineScript. Hay un conjunto de cmdlets que se excluyen y no se pueden usar en un flujo de trabajo a menos que los incluya explícitamente en un bloque InlineScript . Para obtener más información sobre estos conceptos, consulte Uso de actividades en flujos de trabajo de script.

Las actividades de flujo de trabajo comparten un conjunto de parámetros comunes para configurar su funcionamiento. Para más información sobre los parámetros comunes del flujo de trabajo, vea about_WorkflowCommonParameters.

Módulos de integración

Un módulo de integración es un paquete que contiene un módulo de Windows PowerShell y se puede importar en Automation. Los módulos de Windows PowerShell contienen cmdlets que se pueden usar en runbooks de Automation. Algunos productos y servicios, como Operations Manager y Azure, cuentan con módulos que incluyen cmdlets específicos para su funcionamiento.

Los módulos de integración se importan en Automation y automáticamente están disponibles para todos los runbooks. Dado que Automation se basa en Windows PowerShell 4.0, admite la carga automática de módulos, lo que significa que los cmdlets de los módulos instalados se pueden usar sin importarlos en el script con Import-Module.

Cualquier módulo de Windows PowerShell se puede importar en Automation siempre que todas sus dependencias puedan encontrarse en una única carpeta. Si el módulo depende de la configuración del Registro o de los archivos que no están en la ruta de acceso predeterminada, se puede importar, pero probablemente no funcionará porque Automation no podrá localizar sus dependencias. Los módulos con dependencias externas se pueden utilizar en un runbook instalándolos en otro host y accediendo a ellos con un bloque de scripts de InlineScript .

Con Service Management Automation, puede usar módulos con dependencias externas instalándolos en cada servidor Worker. Aunque los cmdlets de estos módulos se pueden usar en runbooks, Automation no los detectará para admitir características como el Asistente para insertar actividad. Para poder usar esta característica, puede crear un módulo portátil mediante el cmdlet New-SmaPortableModule . Este cmdlet crea un módulo que incluye un código auxiliar para cada uno de sus cmdlets y se puede importar a Automation. Cuando un Runbook usa uno de estos cmdlets, el código auxiliar redirige la llamada al propio cmdlet en el módulo externo. Ese módulo debe estar instalado en cada servidor Worker o se producirá un error en la llamada.

Ejecución paralela

Una ventaja de los flujos de trabajo de Windows PowerShell es la capacidad para realizar un conjunto de comandos en paralelo en lugar de hacerlo secuencialmente como con un script típico. Esto resulta particularmente útil en los Runbooks, ya que es posible que ejecuten varias acciones que tardan mucho tiempo en completarse. Por ejemplo, supongamos que usa un Runbook para aprovisionar un conjunto de máquinas virtuales. En lugar de realizar cada proceso de aprovisionamiento en secuencia entre sí, las acciones se podrían realizar simultáneamente, lo que aumenta la eficacia general. El Runbook continuará únicamente cuando todas las acciones se hayan completado.

Puede utilizar la palabra clave Parallel para crear un bloque de scripts con varios comandos que se ejecutarán simultáneamente. Usa la sintaxis que se muestra a continuación. En este caso, Activity1 y Activity2 se iniciarán al mismo tiempo. Activity3 se iniciará después de que se hayan completado Activity1 y Activity2.

Parallel
{
  <Activity1>
  <Activity2>
}
<Activity3>

Puede utilizar la construcción ForEach-Parallel para procesar comandos para cada elemento de una colección simultáneamente. Los elementos de la colección se procesan en paralelo mientras que los comandos del bloque de scripts se ejecutan secuencialmente. Usa la sintaxis que se muestra a continuación. En este caso, Activity1 se iniciará al mismo tiempo para todos los elementos de la colección. Para cada elemento, Activity2 se iniciará una vez completada Activity1. Activity3 se iniciará solo después de que Activity1 y Activity2 se hayan completado para todos los elementos.

ForEach -Parallel ($<item> in $<collection>)
{
  <Activity1>
  <Activity2>
}
<Activity3>

La palabra clave Sequence se usa para ejecutar comandos en secuencia dentro de un bloque de script Parallel. El bloque de script Sequence se ejecuta en paralelo con otros comandos, pero los comandos dentro del bloque se ejecutan secuencialmente. Usa la sintaxis que se muestra a continuación. En este caso, Activity1, Activity2 y Activity3 se iniciarán al mismo tiempo. Activity4 solo se iniciará después de que Activity3 se haya completado. Activity5 se iniciará después de que se hayan completado todas las demás actividades

Parallel
{
  <Activity1>
  <Activity2>

  Sequence
  {
   <Activity3>
   <Activity4>
  }
}
<Activity5>

Puntos de control

Un punto de control es una instantánea del estado actual del flujo de trabajo que incluye el valor actual de las variables y todos los resultados generados para ese punto. El último punto de comprobación que se debe llevar a cabo en un runbook es guardarlo en la base de datos de Automation para que el flujo de trabajo puede reanudarse incluso en caso de una interrupción del servicio. Los datos del punto de control se eliminan una vez finalizado el trabajo del Runbook.

Puede establecer un punto de control en un flujo de trabajo con la actividad Checkpoint-Workflow . Al incluir esta actividad en un Runbook, inmediatamente se toma un punto de control. Si el Runbook se suspende debido a un error, cuando se reanude el trabajo, se reanudará desde el punto del último punto de control establecido.

En el código de ejemplo siguiente, se produce un error después de Activity2, lo que hace que el runbook se suspenda. Cuando se reanuda el trabajo, se inicia ejecutando Activity2, ya que se encontraba justo detrás del último punto de control establecido.

<Activity1>
Checkpoint-Workflow
<Activity2>
<Error>
<Activity3>

Debe establecer puntos de control en un runbook después de las actividades que pueden ser propensas a errores y no deben repetirse si se reanuda el runbook. Por ejemplo, supongamos que usa un Runbook para crear una máquina virtual. Puede establecer un punto de control antes y después de los comandos para crear la máquina virtual. Si se produce un error en la creación, los comandos se repiten cuando se reanuda el Runbook. Si la creación se realiza correctamente, pero el runbook se produce un error más adelante, la máquina virtual no se volverá a crear cuando se reanude el runbook.

Para obtener más información acerca de los puntos de control, consulte Adición de puntos de control a un flujo de trabajo de scripts.

Suspender un runbook

Puede forzar que un runbook se suspenda a sí mismo con la actividad Suspend-Workflow. Esta actividad establecerá un punto de control y hará que el flujo de trabajo se suspenda inmediatamente. Suspender el flujo de trabajo resulta útil para los runbooks que pueden requerir realizar un paso manualmente antes de ejecutar otro conjunto de actividades.

Para obtener más información sobre la suspensión de un flujo de trabajo, vea Making a Workflow Suspend Itself (Hacer que un flujo de trabajo se suspenda a sí mismo).

InlineScript

La actividad InlineScript ejecuta un bloque de comandos en una sesión independiente y sin flujo de trabajo, y devuelve los resultados al flujo de trabajo. Mientras que los comandos de un flujo de trabajo se envían a Windows Workflow Foundation para su procesamiento, los comandos de un bloque de InlineScript se procesan mediante Windows PowerShell. La actividad usa los parámetros comunes del flujo de trabajo estándar, incluidos PSComputerName y PSCredential, que permiten especificar que el bloque de código se ejecute en otro equipo o mediante credenciales alternativas.

InlineScript usa la sintaxis que se muestra a continuación.

InlineScript
{
  <Script Block>
} <Common Parameters>

El uso más común de InlineScript en un runbook es el de ejecutar un bloque de código en otro equipo. Esto es necesario cuando los cmdlets del runbook no están instalados en Automation o si la acción solo tiene permisos para realizarse localmente en el equipo de destino. Esto se ilustra en el diagrama siguiente.

Para ejecutar el bloque de código en otro equipo, se usan los parámetros PSComputer y PSCredential con la actividad InlineScript. Se suele usar un recurso global, como una Credential o una Connection en el runbook para proporcionar valores para estos parámetros. El siguiente código de ejemplo ejecuta un conjunto de comandos en un equipo representado por una conexión denominada MyConnection.

$con = Get-AutomationConnection -Name 'MyConnection'
$securepassword = ConvertTo-SecureString -AsPlainText -String $con.Password -Force
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $con.Username, $securepassword
InlineScript
{
  <Commands>
} -PSComputer $con.ComputerName -PSCredential $cred

Aunque es posible que las actividades de InlineScript resulten críticas en algunos runbooks, solo deberían usarse cuando sea necesario por los siguientes motivos:

• No se pueden usar puntos de control desde dentro de un bloque InlineScript . Si se produce un error dentro del bloque, se debe reanudar desde el principio.

• InlineScript afecta a la escalabilidad del runbook, ya que retiene la sesión de Windows PowerShell para el bloque InlineScript en su totalidad.

• Las actividades como Get-AutomationVariable y Get-AutomationPSCredential no están disponibles en un bloque InlineScript.

Si necesita usar un InlineScript, debe minimizar su ámbito. Por ejemplo, si el runbook itera en una colección mientras aplica la misma operación a cada elemento, el bucle debería producirse fuera de InlineScript. Esto ofrecerá las siguientes ventajas:

• Puede establecer un punto de control del flujo de trabajo después de cada iteración. Si se suspende o se interrumpe el trabajo, y se reanuda, el bucle podrá reanudarse.

• Puede usar ForEach "Parallel para controlar simultáneamente los elementos de la colección.

Tenga en cuenta las siguientes recomendaciones si usa un InlineScript en su runbook:

• No obstante, puede pasar valores al script mediante el modificador de ámbito $Using . Por ejemplo, una variable denominada $abc que se ha establecido fuera del InlineScript, pasaría a ser $using:abc dentro de un InlineScript.

• Para devolver una salida de un InlineScript, asigne la salida a una variable y genere datos para que vuelvan al flujo de salida. En el ejemplo siguiente se asigna la cadena hi a una variable denominada $output.

  $output = InlineScript { Write-Output "hi" }
  

• Evite definir flujos de trabajo en el ámbito del InlineScript. Aunque algunos flujos de trabajo parecen funcionar correctamente, no se trata de un escenario probado. Como resultado, puede que encuentre mensajes de error confusos o un funcionamiento inesperado.

Para obtener más información sobre el uso de InlineScript, vea Ejecución de comandos Windows PowerShell en un flujo de trabajo y about_InlineScript.

Pasos siguientes

• Creación de runbooks de automatización.