PowerShell Workflow

In the previous activities, you learned about runbooks, types of runbooks and how to create a runbook that interacts with Azure resources to switch off machines. You also discovered how to leverage webhooks to perform two-way communication.

When we looked at runbook types, you were introduced to the workflow runbook. The workflow runbook is an important and useful tool for any IT administrator. In this step, we’ll explore workflow runbooks and learn how to create checkpoints that allow you to recover your runbook at its failure point.

What is PowerShell Workflow?

A Windows PowerShell workflow is a sequence of programmed, connected steps that perform long-running tasks or require the coordination of multiple steps across multiple devices or managed nodes. Workflows let IT pros and developers author sequences of multidevice management activities, or single tasks within a workflow, as workflows.

By design, workflows can be long-running, repeatable, frequent, parallelisable, interruptible, stoppable, and restartable. They can be suspended and resumed and can also continue after an unexpected interruption, such as a network outage or computer restart.

The benefits of using workflows include:

• Windows PowerShell scripting syntax. Workflows extend PowerShell, which makes it is easy for IT professionals who are already familiar with scripting.

• Multidevice management. You can simultaneously apply workflow tasks to hundreds of managed nodes. Workflows automatically add common parameters to enable multidevice management scenarios.

• Running a single task to manage complex end-to-end processes. You can combine related scripts or commands that act on an entire scenario into a single workflow. Status and progress of activities within the workflow are visible at any time.

• Automated failure recovery. Workflows survive both planned and unplanned interruptions, such as computer restarts. You can suspend workflow operation, then restart or resume the workflow from the point at which it was suspended. You can author checkpoints as part of your workflow so that you can resume the workflow from the last persisted task (or checkpoint), instead of restarting the workflow from the beginning.

• Connection and activity retries. By using workflow common parameters, workflow users can retry connections to managed nodes if network-connection failures occur. Workflow authors can also specify activities that must run again if the activity cannot be completed on one or more managed nodes (for example, if a target computer was offline while the activity was running).

• Connect and disconnect. Users can connect and disconnect from the computer that’s running the workflow, but the workflow remains running. For example, if you are running and managing the workflow on two different computers, you can log off or restart the computer from which you are managing the workflow. This enables you to monitor workflow operations from another computer (such as a home computer) without interrupting the workflow.

• Task scheduling. Workflow tasks can be scheduled and then started when specific conditions are met, as with any other Windows PowerShell cmdlet or script.

Workflow Syntax

To write the workflow, you can use a script editor such as the Windows PowerShell Integrated Scripting Environment (ISE), which enforces workflow syntax and highlights syntax errors. A benefit of using this tool is that it automatically compiles your code and allows you to save the artefact. The syntactic differences between scripts and workflows are significant, so a tool that knows workflows, as well as scripts, will save you significant coding and testing time.

Steps for creating the Workflow Syntax:

1. Begin with the workflow keyword, which identifies a workflow command to Windows PowerShell. The workflow keyword is required in a script workflow.
2. The name of the workflow follows the workflow keyword.
3. The body of the workflow is enclosed in braces. A workflow is a Windows PowerShell command type. Select a name with a verb-noun format.

**workflow Test-Workflow**

**{**

**...**

**}**

To add parameters to a workflow, use the **Param** keyword. These are the same techniques that you use to add parameters to a function. Lastly, simply add your standard PowerShell commands.

**workflow MyFirstRunbook-Workflow**

**{**

**Param(**

**[string]$VMName,**

**[string]$ResourceGroupName**

**)**

**....**

**Start-AzureRmVM -Name $VMName -ResourceGroupName $ResourceGroupName**

**}**

Checkpoint and Parallel Processing

Workflows let you implement complex logic within your code. Two unique features of workflows are checkpoints and parallel processing.

Checkpoints

A checkpoint is a snapshot of the current state of the workflow that includes the current value for variables and any output generated to that point. If a workflow ends in error or is suspended, the next time it’s run it will start from its last checkpoint instead of the start of the workflow.

You can set a checkpoint in a workflow with the Checkpoint-Workflow activity. For example, in the following sample code, if an exception occurs after Activity2, the workflow will end. When the workflow is run again, it starts with Activity2 because this followed just after the last checkpoint set.

<Activity1>

Checkpoint-Workflow

<Activity2>

<Exception>

<Activity3>

Parallel Processing

A Parallel script block has multiple commands that run concurrently instead of sequentially, as occurs with a typical script.

In the following example, two VMs will be started concurrently:

Parallel

{

Start-AzureRmVM -Name $vm0 -ResourceGroupName $rg 
 Start-AzureRmVM -Name $vm1 -ResourceGroupName $rg

}