Concetti relativi al flusso di lavoro di Windows PowerShell

Un tipo di runbook per Service Management Automation si basa sui flussi di lavoro di Windows PowerShell. Questo articolo offre una breve panoramica delle funzionalità critiche dei flussi di lavoro comuni ai runbook di Automazione. È possibile consultare informazioni complete sui flussi di lavoro nella pagina Getting Started with Windows PowerShell Workflow (Guida introduttiva ai flussi di lavoro di Windows PowerShell).

La struttura dei runbook è identica tra i runbook per Service Management Automation e per Microsoft Automazione di Azure anche se i due funzionano in genere con risorse diverse.

Flussi di lavoro di Windows PowerShell

Un flusso di lavoro è una sequenza di passaggi programmati e connessi che consentono di eseguire attività di lunga durata o richiedono il coordinamento di più passaggi tra più dispositivi o nodi gestiti. I vantaggi di un flusso di lavoro rispetto a un normale script includono la possibilità di eseguire simultaneamente un'azione su più dispositivi e di eseguire il ripristino automatico dagli errori. Un flusso di lavoro di Windows PowerShell è uno script di Windows PowerShell che usa Windows Workflow Foundation. Mentre il flusso di lavoro viene scritto con la sintassi di Windows PowerShell e avviato da Windows PowerShell, viene elaborato da Windows Workflow Foundation.

Struttura di base

Un flusso di lavoro di Windows PowerShell inizia con la parola chiave Workflow seguita dal corpo dello script racchiuso tra parentesi graffe. Il nome del flusso di lavoro segue la parola chiave Workflow , come mostrato nella sintassi seguente. Il nome del flusso di lavoro corrisponde al nome del runbook di Automazione.

Workflow Test-Runbook
{
   <Commands>
}

Per aggiungere parametri al flusso di lavoro, usare la parola chiave Param come illustrato nella sintassi seguente. Il portale di gestione richiede all'utente di fornire i valori per questi parametri quando avvia il runbook. In questo esempio viene usato l'attributo Parameter facoltativo, che specifica se il parametro è obbligatorio o meno.

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

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

Denominazione

Il nome del flusso di lavoro deve essere conforme con il formato verbo-sostantivo standard di Windows PowerShell. Per un elenco dei verbi approvati, consultare Approved Verbs for Windows PowerShell Commands (Verbi approvati per i comandi di Windows PowerShell) . Il nome del flusso di lavoro deve corrispondere al nome del Runbook di Automazione. Se il runbook viene importato, il nome del file deve corrispondere al nome del flusso di lavoro e terminare con l'estensione ps1.

Limiti

Per un elenco completo di limitazioni e differenze di sintassi tra i flussi di lavoro di Windows PowerShell e Windows PowerShell, vedere Differenze sintattiche tra flussi di lavoro di Script e script.

Impegni

Un'attività è un'operazione specifica in un flusso di lavoro. Proprio come uno script, che è composto da uno o più comandi, un flusso di lavoro è composto da una o più attività che vengono svolte in maniera sequenziale. Il flusso di lavoro di Windows PowerShell converte automaticamente molti dei cmdlet di Windows PowerShell in attività quando esegue un flusso di lavoro. Quando si specifica uno di questi cmdlet in un Runbook, l'attività corrispondente viene in realtà eseguita da Windows Workflow Foundation. Per i cmdlet senza un'attività corrispondente, il flusso di lavoro di Windows PowerShell esegue automaticamente il cmdlet all'interno di un'attività InlineScript . Esiste un set di cmdlet esclusi e non può essere usato in un flusso di lavoro, a meno che non vengano inclusi in modo esplicito in un blocco InlineScript . Per altre informazioni su questi concetti, vedere Uso di attività nei flussi di lavoro di script.

Le attività dei flussi di lavoro condividono un set di parametri comuni per configurare il proprio funzionamento. Per informazioni dettagliate sui parametri comuni dei flussi di lavoro, vedere about_WorkflowCommonParameters.

Moduli di integrazione

Un modulo di integrazione è un pacchetto che contiene un modulo di Windows PowerShell e può essere importato in Automazione. I moduli di Windows PowerShell contengono cmdlet che possono essere usati nei runbook di Automazione. I prodotti e i servizi come Operations Manager e Azure hanno moduli che includono cmdlet specifici per le loro particolari funzionalità.

I moduli di integrazione importati in Automazione sono automaticamente disponibili per tutti i runbook. Poiché Automazione è basata su Windows PowerShell 4.0, supporta il caricamento automatico dei moduli, ovvero i cmdlet dai moduli installati possono essere usati senza importarli nello script con Import-Module.

Qualsiasi modulo di Windows PowerShell può essere importato in Automazione, purché tutte le relative dipendenze si trovino in una singola cartella. Se il modulo dipende dalle impostazioni o dai file del Registro di sistema non nel percorso predefinito, può essere importato, ma probabilmente non funziona perché Automazione non sarà in grado di individuare le relative dipendenze. I moduli con dipendenze esterne possono essere usati in un runbook installandoli in un altro host ed eseguendo l'accesso con un blocco di script InlineScript .

Con Service Management Automation è possibile usare moduli con dipendenze esterne installandoli in ogni server di lavoro. Anche se i cmdlet in questi moduli possono essere usati nei runbook, non verranno individuati da Automazione per supportare funzionalità come l'Attività di inserimento guidata. Per utilizzare questa funzionalità, creare un modulo portatile con il cmdlet New-SmaPortableModule . Questo cmdlet crea un modulo che include uno stub per ognuno dei relativi cmdlet e può essere importato in Automazione. Quando un Runbook utilizza uno di questi cmdlet, lo stub reindirizza la chiamata al cmdlet effettivo del modulo esterno. Installare il modulo in ciascun server Worker per evitare che la chiamata abbia esito negativo.

Esecuzione in parallelo

Uno dei vantaggi offerti dai flussi di lavoro di Windows PowerShell consiste nella possibilità di eseguire un set di comandi in parallelo anziché in sequenza, come accade invece con uno script tipico. Si tratta di una funzione particolarmente utile con i Runbook, che consentono di eseguire numerose azioni che richiedono molto tempo. Ad esempio, un Runbook potrebbe eseguire il provisioning di un set di macchine virtuali. Invece di eseguire ogni processo di provisioning in sequenza tra loro, è possibile eseguire le azioni contemporaneamente, aumentando l'efficienza complessiva. Il Runbook continuerà la propria azione al completamento di tutti i processi.

È possibile usare la parola chiave Parallel per creare un blocco di script con più comandi che verranno eseguiti contemporaneamente. In questo scenario viene usata la sintassi seguente. In questo caso l'esecuzione di Activity1 e Activity2 sarà simultanea. Activity3 si avvierà solo dopo il completamento di Activity1 e Activity2.

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

È possibile usare il costrutto ForEach -Parallel per elaborare i comandi per ogni elemento di una raccolta simultaneamente. Gli elementi della raccolta vengono elaborati in parallelo, mentre i comandi nel blocco di script vengono eseguiti in sequenza. In questo scenario viene usata la sintassi seguente. In questo caso, Activity1 inizierà contemporaneamente per tutti gli elementi della raccolta. Per ogni elemento, Activity2 si avvierà al completamento di Activity1. Activity3 verrà avviato solo dopo il completamento di Activity1 e Activity2 per tutti gli elementi.

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

La parola chiave Sequence viene usata per eseguire i comandi in sequenza all'interno di un blocco di script Parallel . Il blocco di script Sequence viene eseguito in parallelo con altri comandi, ma i comandi all'interno del blocco vengono eseguiti in sequenza. In questo scenario viene usata la sintassi seguente. In questo caso, Activity1, Activity2 e Activity3 verranno avviati nello stesso momento. Activity4 verrà avviato solo al termine di Activity3. L'attività5 verrà avviata dopo il completamento di tutte le altre attività

Parallel
{
  <Activity1>
  <Activity2>

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

Checkpoint

Un checkpoint è uno snapshot dello stato corrente del flusso di lavoro che include il valore corrente per le variabili e gli output generati fino al punto corrispondente. L'ultimo checkpoint da completare in un runbook viene salvato nel database di Automazione in modo che il flusso di lavoro possa riprendere anche in caso di interruzione. I dati del checkpoint vengono rimossi dopo il completamento del processo del Runbook.

È possibile impostare un checkpoint in un flusso di lavoro con l'attività Checkpoint-Workflow . Quando si include questa attività in un Runbook, viene immediatamente creato un checkpoint. Se il Runbook viene sospeso a causa di un errore, il processo riprenderà dal punto indicato dall'ultimo checkpoint impostato.

Nel codice di esempio seguente si verifica un errore dopo Activity2, causando la sospensione del runbook. Un processo ripreso inizia eseguendo Activity2, ossia l'attività specificata prima dell'ultimo checkpoint impostato.

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

È consigliabile impostare checkpoint in un runbook dopo le attività che potrebbero essere soggette a errori e non devono essere ripetute se il runbook viene ripreso. Ad esempio, il Runbook potrebbe creare una macchina virtuale. È possibile impostare un checkpoint sia prima che dopo i comandi di creazione della macchina virtuale. Se la creazione non dovesse avere esito positivo, i comandi verranno ripetuti alla ripresa del Runbook. Se la creazione ha esito positivo ma il runbook avrà esito negativo in un secondo momento, la macchina virtuale non verrà creata di nuovo quando il runbook viene ripreso.

Per altre informazioni sui checkpoint, vedere l'articolo relativo all' aggiunta di checkpoint a un flusso di lavoro di script.

Sospendere un runbook

È possibile forzare la sospensione di un runbook con l'attività Suspend-Workflow . L'attività imposterà un checkpoint e sospenderà immediatamente il flusso di lavoro. La sospensione di un flusso di lavoro è utile per i runbook che potrebbero richiedere un passaggio manuale prima di eseguire un altro set di attività.

Per maggiori informazioni sulla sospensione di un flusso di lavoro, vedere Making a Workflow Suspend Itself (Autosospensione di un flusso di lavoro).

InlineScript

L'attività InlineScript esegue un blocco di comandi in una sessione separata non del flusso di lavoro e ne restituisce l'output al flusso di lavoro. Mentre i comandi di un flusso di lavoro vengono inviati a Windows Workflow Foundation per l'elaborazione, i comandi in un blocco InlineScript vengono elaborati da Windows PowerShell. L'attività usa i parametri comuni del flusso di lavoro standard, tra cui PSComputerName e PSCredential, che consentono di specificare che il blocco di codice deve essere eseguito in un altro computer o usando credenziali alternative.

InlineScript usa la sintassi seguente.

InlineScript
{
  <Script Block>
} <Common Parameters>

L'uso più comune di InlineScript in un runbook consiste nell'eseguire un blocco di codice in un altro computer. Questa operazione è necessaria quando i cmdlet nel runbook non sono installati in Automazione o se l'azione dispone solo delle autorizzazioni da eseguire localmente nel computer di destinazione. La situazione viene illustrata nel diagramma seguente.

Per eseguire il blocco di codice in un altro computer, i parametri PSComputer e PSCredential vengono usati con l'attività InlineScript . Una risorsa globale come una Credential o una Connection viene usata generalmente in un runbook per fornire valori per questi parametri. Il codice di esempio riportato di seguito esegue un set di comandi su un computer indicato dalla connessione 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

Anche se le attività InlineScript possono essere critiche in determinati runbook, devono essere usate solo quando necessario per i motivi seguenti:

• Non è possibile usare checkpoint all'interno di un blocco InlineScript . In caso di errore all'interno del blocco, questo deve essere ripreso dall'inizio.

• InlineScript influisce sulla scalabilità del runbook perché contiene la sessione di Windows PowerShell per l'intera lunghezza del blocco InlineScript.

• Le attività come Get-AutomationVariable e Get-AutomationPSCredential non sono disponibili in un blocco InlineScript.

Se è necessario usare un codice InlineScript, è consigliabile ridurre al minimo l'ambito. Ad esempio, se il runbook esegue l'iterazione su una raccolta durante l'applicazione della stessa operazione a ogni elemento, il ciclo deve verificarsi all'esterno di InlineScript. In questo modo si otterranno i seguenti vantaggi:

• È possibile eseguire il checkpoint del flusso di lavoro dopo ogni iterazione. Se il processo viene sospeso o interrotto e ripreso, il ciclo potrà riprendere.

• È possibile usare ForEach "Parallel per gestire gli elementi della raccolta contemporaneamente.

Tenere presenti i suggerimenti seguenti se si usa un codice InlineScript nel runbook:

• È possibile inviare i valori allo script con il modificatore di ambito $Using . Ad esempio, una variabile denominata $abc impostata all'esterno di InlineScript diventerà $using:abc all'interno di un inlineScript.

• Per restituire l'output da un oggetto InlineScript, assegnare l'output a una variabile e restituire i dati da restituire al flusso di output. Nell'esempio seguente la stringa viene assegnata a una variabile denominata $output.

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

• Evitare di definire flussi di lavoro all'interno dell'ambito InlineScript . Anche se alcuni flussi di lavoro potrebbero sembrare funzionare correttamente, questo non è uno scenario testato. Di conseguenza, è possibile visualizzare messaggi di errore ambigui o comportamenti imprevisti.

Per altre informazioni sull'uso di InlineScript, vedere Esecuzione di comandi di Windows PowerShell in un flusso di lavoro e about_InlineScript.

Passaggi successivi

• Creare runbook di automazione.