Microsoft is starting to release more details on Windows PowerShell Workflow. Also known as PSWF, this feature of PowerShell 3 allows administrators to “reliably executing long-running tasks across multiple computers, devices or IT processes”. Since we are talking about Windows Workflow, the term “long-running” can mean hours or even days.
Workflows for PSWF can be written using the same XAML notation used for Windows Workflow Foundation. However, most PowerShell users would probably feel more comfortable using the new script-based workflow syntax. This syntax is an extension to PowerShell that adds constructs such as:
- workflow: Defines a workflow. Note: work flows can be nested within other workflows using this construct.
- inlinescript: Normally each line in a workflow is executed in isolation. This construct groups a set of lines so that they can share local variables. Inline scripts blocks also allow you to use some PowerShell syntax that is otherwise not allowed inside a workflow.
- foreach –parallel: Executes the body of the construct against each item in parallel.
- parallel: Executes each task in the body of the construct in parallel, which of course means there are no ordering guarantees.
- sequence: Executes each task in the body of the construct in order. This is usually used inside a parallel block to form a group of ordered statements.
It is important to note that PowerShell workflow is in many ways a subset of the full PowerShell syntax. Unlike normal PowerShell scripts, PowerShell workflows are statically compiled. This prevents a lot of dynamic features such as positional and dynamic parameters. The need to be able to persist a workflow at any time also prevents invoking methods using a the dot-notation. “This implies that you've got a live object to work on, which is not possible if the workflow is persisted in-between the call that generates the object and the call that uses its method.”
There are also many cmdlets that won’t work as a workflow activity. As mentioned before, each line in workflow is executed in its own isolated PowerShell session; thus cmdlets that alter the state of the PowerShell session do not make sense. Likewise cmdlets that support transactions are off limits.
PSWF is designed with scalability in mind. More specifically, it is designed to scale out. One workflow can be distributed across “thousands of managed nodes”, allowing you to manage large server farms almost as easily as you would a single machine. For example, to launch a workflow across several machines, one can simply invoke workflow with the PSComputerName parameter, passing in the list of machine names. These features replace the normal PowerShell remoting features.
Long running workflows should probably be run in the background. To facilitate this, PSWF is integrated into the PowerShell job infrastructure. Simply invoke the workflow with the AsJob parameter and the usual job cmdlets can then be used.
