One of the most important and interesting new features of Windows PowerShell v3 is workflow. At first look, you might struggle to find real-world examples of where this feature might find use. But look deeper: This is a foundation feature that future Microsoft products will build on significantly. Rather than individual product teams burning cycles developing their own mechanisms for managing long-running administrative tasks, they can all now rely on PowerShell to provide that functionality.
What is “Workflow?”
PowerShell’s workflow features are built on Windows Workflow Foundation, or WWF, a part of the Microsoft .NET Framework since v3.5. A workflow is defined as a distinct set of tasks that all need to be completed in a particular order. Some of those tasks might involve a computer reboot, such as joining a computer to a domain, and the overall process might need to survive intermittent problems like network connection failures. Each step of the workflow can be logged for troubleshooting and auditing purposes as well. WWF provides scheduling capabilities for workflows, managing the flow of execution between specific tasks within the workflow, and so on.
More on PowerShell v3:
Windows Server 2012 and PowerShell v3 Runbook Automation
PowerShell v3 has some great GUI
WWF uses its own Application Programming Interface, or API, which until now has been in the domain of .NET developers. PowerShell v3 defines a new language construct, “workflow,” which looks and feels a lot like a function. PowerShell translates PowerShell commands and script code to the necessary WWF code for you, all behind the scenes, finally giving administrators a straightforward and relatively easy way to create workflows.
Like a function… almost
Because the PowerShell code in a workflow must be translated to something WWF understands, there are a few rules to play by. For the most part, anything that you could run from the PowerShell console or put into a PowerShell script will work inside a workflow, with just a couple of major exceptions.
First up is the switch construct, which has no equivalent in WWF and therefore can’t be used in a workflow. Second is the fact that WWF supports parallel execution, meaning you can use a special parallel foreach construct (which is actually a couple of constructs that work together) to have PowerShell perform multi-threaded activities. Think about that -- you get a big collection of objects to deal with and now you can run through them in parallel! Very cool! Parallelism only works in a workflow, and isn’t supported elsewhere in PowerShell.
There are a few other restrictions, most of which relate to the differences between PowerShell and WWF. Microsoft provides a complete list of these exceptions -- you’ll find a link to a document at the end of this article.
Sexy workflow words
You might not get all that excited about words in general, but consider some of the words that have all been applied to PowerShell workflow. Workflow enables you to create tasks that are…
- Frequently executed
Ponder those for a moment. This is big stuff. Imagine having a “workflow base station” server in your data center, where you submit all of your PowerShell workflow tasks. PowerShell hands off your code to WWF, which makes sure the tasks complete in order… with logging… no matter what. They can be paused. They can be restarted. They can run in parallel. This is an awesome new territory.
So how does it work?
When you create a workflow, you’re basically creating a new PowerShell command. You can ask for help on it, list the commands within it, and so forth. It can be as complex as you need it to be. When you run it, PowerShell translates it into WWF and asks WWF to execute it. You can even run workflows in the background as a job -- and use the new Suspend-Job and Resume-Job cmdlets to pause and resume the workflow’s execution.
PowerShell automatically adds about two dozen parameters to your workflow, enabling you to pipe objects into it, specify Remoting configuration information, provide alternate credentials, computer names on which to execute the workflow, and much more. You get all of that capability for free, meaning you have to do very little work other than write the commands that accomplish whatever task you’ve set out to perform.
One workflow can even call another, opening us up to incredible modularization and re-use opportunities.
Give it a try
It’s never too early to start getting this new technology in your head. Start by downloading PowerShell v3 CTP #2, as well as a document specifically related to PowerShell Workflow (which includes lots of cool examples). Don’t make the mistake of ignoring this technology: It’s going to be pervasive in a few years, and it’s easier to get in on the ground floor.
ABOUT THE AUTHOR
Don Jones is a Senior Partner and Principal Technologist for Concentrated Technology, LLC, a strategic consulting and analysis firm. Contact him through the company's Web site, http://ConcentratedTech.com.