Runbooks secundarios en Service Management Automation

  • Artículo

Importante

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

Se trata de un procedimiento recomendado en Service Management Automation (SMA) para escribir runbooks modulares reutilizables con una función discreta que otros runbooks pueden usar. A menudo, un runbook primario llamará a uno o varios runbooks secundarios para realizar la funcionalidad necesaria. Hay dos maneras de llamar a un runbook secundario y cada uno tiene diferencias distintas que debe comprender para que pueda determinar cuál será el mejor para sus diferentes escenarios.

Invocación de un runbook secundario mediante la ejecución insertada

Para invocar un runbook en línea desde otro runbook, use el nombre del runbook y proporcione valores para sus parámetros, exactamente igual a como usaría una actividad o un cmdlet. Todos los runbooks del mismo entorno de SMA están disponibles para que todos los demás los usen de esta manera. El runbook principal esperará a que el runbook secundario se complete antes de pasar a la siguiente línea, y cualquier resultado se devolverá directamente al elemento primario.

Al invocar un runbook en línea, este se ejecuta en el mismo trabajo que el runbook primario. No habrá ninguna indicación en el historial de trabajos del runbook secundario que se haya ejecutado. Cualquier excepción y salida de flujo pertenecientes al runbook secundario, se asociarán al primario. Esto da lugar a menos trabajos y facilita el seguimiento y la solución de problemas, ya que las excepciones producidas por el runbook secundario y las salidas de flujo asociadas al trabajo del runbook primario.

Cuando se publica un runbook, los runbooks secundarios a los que llama deben tener ya una versión publicada. El motivo es que Automation crea una asociación con los runbooks secundarios cuando un runbook se compila. Si no lo están, el runbook primario parecerá publicarse correctamente, pero generará una excepción cuando se inicie. Si esto sucediera, puede volver a publicar el runbook primario para que haga referencia correctamente a los runbooks secundarios. No es necesario volver a publicar el runbook primario si se cambia alguno de los runbooks secundarios porque ya se habrá creado la asociación.

Los parámetros de un runbook secundario denominado inline pueden ser cualquier tipo de datos, incluidos los objetos complejos, y no hay ninguna serialización JSON , ya que hay cuando se inicia el runbook mediante el Portal de administración o con el cmdlet Start-SmaRunbook .

Tipos de runbook

Un runbook solo puede usar otro runbook del mismo tipo como runbook secundario mediante la ejecución insertada. Esto significa que un runbook de flujo de trabajo de PowerShell no puede usar un runbook de PowerShell como elemento secundario mediante la ejecución insertada y un runbook de PowerShell no puede usar un runbook de flujo de trabajo de PowerShell.

Cuando se llama a un runbook secundario del flujo de trabajo de PowerShell con la ejecución insertada, solo tiene que usar el nombre del runbook. Al llamar a un runbook secundario de PowerShell, debe preceder a su nombre con .\ para especificar que el script se encuentra en el directorio local.

Ejemplo

En el ejemplo siguiente se invoca un runbook secundario de prueba que acepta tres parámetros: un objeto complejo, un entero y un valor booleano. Los resultados del runbook secundario se asignan a una variable. En este caso, el runbook secundario es un runbook de flujo de trabajo de PowerShell.

$vm = Get-VM -Name "MyVM" -ComputerName "MyServer"
$output = Test-ChildRunbook -VM $vm -RepeatCount 2 -Restart $true

A continuación se muestra el mismo ejemplo con un runbook de script de PowerShell como elemento secundario.

$vm = Get-VM -Name "MyVM" -ComputerName "MyServer"
$output = .\Test-ChildRunbook.ps1 -VM $vm -RepeatCount 2 -Restart $true

Inicio de un runbook secundario mediante cmdlets

Puede utilizar el cmdlet Start-SMARunbook para iniciar un runbook con Windows PowerShell. Cuando se inicia un runbook secundario desde un cmdlet, el runbook primario pasará a la siguiente línea en cuanto se cree el trabajo para el runbook secundario. Si necesita recuperar todas las salidas del runbook, debe acceder al trabajo mediante Get SMAJobOutput.

Si inició el trabajo de un runbook secundario con un cmdlet, este se ejecutará en un trabajo independiente al runbook primario. Esto da como resultado más trabajos que invocar el flujo de trabajo en línea, lo que aumenta la sobrecarga en el servidor de trabajo y hace que sean más difíciles de realizar el seguimiento. Sin embargo, el elemento primario puede iniciar varios runbooks secundarios sin esperar a que se complete cada uno. Para realizar este mismo tipo de ejecución en paralelo, al llamar a los runbooks secundarios en línea, el runbook primario necesitará usar la palabra clave parallel.

Los parámetros para un runbook secundario que se inicia con un cmdlet se proporcionan como una tabla hash, tal y como se describe en Runbook Parameters. Solo se pueden usar tipos de datos simples, aunque puede proporcionar el nombre de un activo de credencial tal y como se describe en Credentials. Si el runbook tiene un parámetro con un tipo de datos complejo, debe llamarse en línea.

En el ejemplo siguiente se inicia un runbook secundario con parámetros y se espera a que finalice. Una vez completado, el runbook primario recopila la salida del trabajo.

$webServer = 'https://MyServer'
$port = 9090
$runbookName = "Test-Runbook"
$params = @{"VMName"="MyVM";"RepeatCount"=2;"Restart"=$true}

$job = Start-SmaRunbook -WebServiceEndpoint $webServer -Port $port -Name $runbookName -Parameters $params

$doLoop = $true
While ($doLoop) {
   $job = Get-SmaJob -WebServiceEndpoint $webServer -Port $port -Id $job.Id
   $status = $job.Status
   $doLoop = (($status -ne "Completed") -and ($status -ne "Failed") -and ($status -ne "Suspended") -and ($status -ne "Stopped")
}

Get-SmaJobOutput -WebServiceEndpoint $webServer -Port $port -Id $job.Id -Stream Output

Comparar métodos para llamar a un runbook secundario

En la siguiente tabla se resumen las diferencias entre los dos métodos para llamar a un runbook desde otro runbook.

En línea Cmdlet
Trabajo Los runbooks secundarios se ejecutan en el mismo trabajo que el primario. Se crea un trabajo independiente para el runbook secundario.
Ejecución El runbook primario espera a que el runbook secundario se complete antes de continuar. El runbook primario continúa inmediatamente después de que el runbook secundario se inicie.
Salida El runbook primario puede obtener los resultados directamente del runbook secundario. El runbook primario debe recuperar la salida del trabajo del runbook secundario.
Parámetros Los valores de los parámetros del runbook secundario se especifican por separado y pueden usar cualquier tipo de datos. Los valores de los parámetros del runbook secundario deben combinarse en una sola tabla hash y solo pueden incluir tipos de datos simples, de matriz y de objeto que usan la serialización JSON.
Publicación El runbook secundario debe publicarse antes de publicar el runbook primario. El runbook secundario debe publicarse en cualquier momento antes de que se inicie un runbook primario.

Pasos siguientes