Each month this year, Don Jones will present an installment in a 12-part tutorial on Windows PowerShell Workflow. We encourage you to read through the series in order, beginning with the January 2013 column.
Workflows look and feel a lot like a Windows PowerShell function or script, but they’re not. Their similarity is only skin-deep, and it may not even be all the way through the skin.
You have to remember that Windows PowerShell has to translate workflows into a totally separate technology—Windows Workflow Foundation (WF). That means you can only do things you can duplicate in WF. Your code will run in an entirely different kind of environment that has its own rules and restrictions. In fact, the differences between a workflow and a “normal” script can be significant.
In a normal script, everything in the script runs in a single runspace, with a single scope hierarchy. A runspace is roughly equivalent to a Windows PowerShell process. If you think of a Windows PowerShell console window, that’s a single runspace. That means everything is the same, consistent and persistent within that runspace.
Variables, commands, drives and everything else all start one way. They stay the same unless you change them. Within that runspace, any changes you make “stick” for the duration of that process.
In a workflow, every activity—every command, inline script block and so on—can have its own runspace. That means if you make a change in one, it might not be visible in any others. Setting a variable in one part of your workflow might not make any change in another part of the workflow, unless you take special steps to ensure otherwise.
As you saw in last month’s article, if you define a variable at the top level of the workflow, it exists throughout the workflow (the system takes steps to make sure this is true). If a command within the workflow creates a variable, that variable won’t be available to the rest of the workflow.
This means module use is also different. Importing a module at one point doesn’t necessarily make commands available at a later point. You need to take a lot more care, because a single workflow can essentially span multiple independent scopes.
There are a number of syntax differences within a workflow, some of which I’ve pointed out in previous articles in this series:
Yeah, that’s a lot of differences. If you’re a careful Windows PowerShell programmer, you’ll run up against fewer of these, such as naming your parameters. You’ll still encounter differences you forgot until you become really familiar with writing workflows.
Windows PowerShell Workflow isn’t all bad-news differences—in fact, it gives you a ton of functionality for free. Every workflow gains built-in parameters, including:
Notice a number of these parameters start with –PS? That’s called a namespace. You should avoid creating your own parameters that also start with –PS. If a future version of Windows PowerShell adds new parameters, they’ll likely start with –PS. If you generally avoid that prefix you’ll avoid collisions with your own parameter names.
The practical upshot here is that workflows aren’t Windows PowerShell scripts. They’re different. They have some differences that can make your life easier. Some other differences can require a bit more work from you. Knowing the differences can help you more quickly start writing effective workflows.
Don Jones is a Windows PowerShell MVP Award recipient, and a contributing editor to TechNet Magazine. He has coauthored four books about Windows PowerShell version 3, including free ones on Windows PowerShell remoting and creating HTML reports in Windows PowerShell. Find them all at PowerShellBooks.com, or ask Jones questions in the discussion forums at PowerShell.org.