Windows PowerShell Workflow Concept

While the PowerShell workflow is itself a vast topic for the discussion, I will try to summarize it.

What is the PowerShell Workflow?

PowerShell Workflow is the sequence of programmed, connected steps that perform multiple actions on multiple devices either parallel or sequentially based on how they are designed. It has a separate engine called PowerShell windows Workflow foundation and which translates the code into the XAML and then compiles the program.

PowerShell workflow was introduced in the Windows Server 2012 and Window 8 and from the PowerShell version 3 onwards but it is discontinued after PowerShell version 6.0. Azure cloud has introduced the PowerShell workflow-based runbooks for Azure Automation account.

https://docs.microsoft.com/en-us/azure/automation/learn/automation-tutorial-runbook-textual

Why Do you need PowerShell Workflow?

Have we ever remembered how many times we have used the script parallelly when we had to work with 50 or 100s of machines without using the third-party tool?
Have we ever created such an environment where we can run some commands sequentially and some parallelly?
What if the remote servers go offline in the middle of the long-running script?
PowerShell Workflow is the answer to all of these but it has also some flaws that are discussed in the latter part of this article.
In Short Windows PowerShell Workflow has the below benefits.

• Used for Long-Running activities.
• For the Bulk Deployments
• Repeatable activities
• Adding checkpoints and restart the workflow execution in case of remote servers go offline.

However, there are few keywords and methods don’t support in the PowerShell workflow techniques. You can get the list from here.

https://devblogs.microsoft.com/scripting/powershell-workflows-restrictions/

Below are the snippets of the above link. These techniques ain’t supported in the Workflow.

How do the PowerShell Workflow works?

Workflow declaration is similar to the PowerShell functions. We provide the Workflow keyword and the name of the workflow. To declare the workflow,

Workflow WorkflowName{
    //Statement1
    //Statement2
}

To call the workflow, we need to use the workflow name like we call the PowerShell function. For example,

Workflow TestWorkflow{
    Write-Output "First Workflow output"
}

TestWorkflow

Output:

Workflow takes sometime for the first time to load into the memory and for the execution but once it is loaded it works as the normal operation.

We can use the Workflow like the normal function.

Workflow TestWorkflow{
    if(Get-Service -Name Winrm -EA Ignore){
        Write-Output "WinRM service exist"
    }
    else{
        Write-Output "WinrRM service doesn't exist"
    }
}

TestWorkflow

Now let’s check the Command type.

It mentions that the CommandType is the Workflow and to check the XAML code provided to the workflow engine for the execution,

Get-Command TestWorkflow | Select -ExpandProperty XamlDefinition

This is just the Front End code, to check what exactly Workflow converts the code into background,

Get-Command TestWorkflow | Select -ExpandProperty Scriptblock

In the next article, we will learn the techniques supported by the PowerShell workflow.