PowerShell Workflow: When Should You Use It?

Microsoft recently posted the online help for PowerShell v3 Workflow (http://technet.microsoft.com/en-us/library/jj134242), and I wanted to take an opportunity to explore some of what the help says - and perhaps offer an outsider's perspective.

What is Workflow?

Workflow is a set of technologies included with PowerShell v3, and is available on any computer running v3 (which can include Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows 8, and Windows Server 2012). A workflow is a special kind of PowerShell script that looks a lot like a function. When run, however, PowerShell translates the workflow to Windows Workflow Foundation (WWF) code, and hands it off to WWF to execute. That means the contents of a workflow are a bit different than the contents of a script.

When might you use workflow?

This is where I take issue with the help files, a bit. They state:

In general, you should consider using a workflow instead of a cmdlet or script when you must meet any of the following requirements.

  • You need to perform a long-running task that combines multiple steps in a sequence.
  • You need to perform a task that runs on multiple devices.
  • You need to perform a task that requires checkpointing or persistence.
  • You need to perform a long-running task that is asynchronous, restartable, parallelizable, or interruptible.
  • You need to run a task on a large scale, or in high availability environments, potentially requiring throttling and connection pooling.

I don't think that's an accurate list. I think it's incomplete, for one, and I think it includes some things it shouldn't. Understand that workflow is complicated. These things require some up-front planning. Not every PowerShell command can be used natively in a workflow (despite what the help files imply), because not every command has a WWF equivalent. For me, workflow is something you should use when no other, simpler mechanism will meet your specific needs. This list in the help file is supposed to help you identify situations where workflow is the only way to go - but I think it's a bit misleading.

Let's look at why.

You need to perform a long-running task that combines multiple steps in a sequence.

Well, that's what a script does. Any script. Just because you need to run multiple steps in a sequence doesn't mean you should be using workflow.

You need to perform a task that runs on multiple devices.

OK, workflow can do this, but so can the much easier-to-use Invoke-Command. Give it a command, or even a script, and you can run multiple steps, in a sequence, on multiple devices. Understand that workflow uses remoting to talk to remote devices; if you're using workflow, you've already enabled remoting - so why not use it when the need is simpler?

You need to perform a long-running task that is asynchronous, restartable, parallelizable, or interruptible.

It's really the "or" I have a problem with here. PowerShell jobs will let you run tasks asynchronously, and in parallel; restartable and interruptible are legitimate workflow-only features. If you need those, you need workflow; if you merely need asynchronous, consider using a job.

You need to run a task on a large scale, or in high availability environments, potentially requiring throttling and connection pooling.

I don't see why Invoke-Command, which supports throttling of connections, couldn't accomplish this criteria. I'll admit that this one's borderline for me; because workflows are executed by WWF and not by PowerShell per se, it's probably better at scale-out. But I wouldn't immediately head for workflow just because I needed to run some command on a few thousand machines. I might, after further evaluation of the situation, select workflow after all - but it's not an automatic for me.

You need to perform a task that requires checkpointing or persistence.

Truth. This is unique to workflow. As WWF executes your workflow tasks, it "checkpoints" its status to disk. That way, if the entire environment crashes, WWF can resume where it left off when things are rebooted. If you need this, it's a legitimate reason to head straight for workflow. And for a very long-running task with multiple steps that might well be interrupted, this would drive me right to workflow every time.

You need to perform a task that combines steps which can be run in parallel with those which must be run sequentially

This is really a unique workflow thing, and one that isn't listed in the help files. Workflow can designate specific chunks - activities is the term workflow uses - that contain commands which must be run in a strict sequence, and designate other chunks to be run in parallel, in any particular order. This can massively improve performance, and is one of the main advantages that would push me to use workflow over an ordinary script.

Features vs. Drivers

For me, this discussion is about workflow features - things it can do - versus workflow drivers - reasons you'd use workflow and workflow alone. My last two points - checkpointing and persistence, along with parallel/sequential mixing - are the main workflow drivers for me. The ability to target multiple machines is a feature; something I can do with workflow once I've decided to use it.

To be fair, I'm simplifying things a bit. Workflow's ability to target multiple machines in parallel may be more robust that remoting's ability to do so; I haven't tested that. Under the hood, though, I know that workflow relies on remoting for communications, so I suspect the two would perform similarly.

Hey, I Think Workflow is Cool!

Don't get me wrong. As I've outlined above, there are definitely reasons I'd choose to use workflow. But those aren't necessarily the reasons given by the help file. While I appreciate the time and effort Microsoft has put into workflow, I think they're a wee bit over-enthusiastic when suggesting that "you should use a workflow when you have a task that combines multiple steps in a sequence." Workflow is a challenging technology, with a fairly steep learning curve. As yet, troubleshooting and debugging tools are scant. I'll stick with simpler mechanisms when they meet my needs - and aim for workflow when I need some of the amazing things that it alone can do for me.

My concern with the help files is that they could drive relative newcomers to workflow by giving them the impression that it was the only way to achieve some of those things, or was the preferred way of achieving them. Those newcomers could easily be intimidated by workflow (heck, I still am), and just walk away from PowerShell entirely, not realizing that there were other, simpler ways of "performing a task that runs on multiple devices." Help files like this should provide direction and guidance... and I just think in this case that the guidance oversells workflow a teeny bit.

I've sent a longer, more detailed version of this feedback to Microsoft as well. Perhaps the help files can evolve over time (hey, that's why PowerShell v3 has updatable help!) to provide better, more accurate guidance on when you should use workflow over some other approach.

About Don Jones

Don Jones is a Windows PowerShell MVP, author of several Windows PowerShell books (and other IT books), Co-founder and President/CEO of PowerShell.org, PowerShell columnist for Microsoft TechNet Magazine, PowerShell educator, and designer/author of several Windows PowerShell courses (including Microsoft's). Power to the shell!

3 thoughts on “PowerShell Workflow: When Should You Use It?

  1. Dave Carnahan

    When to use workflow, on enterprise objectives?
    How about when multiple async predecessor events come in at differing times for the workflow - or not at all?
    You can't (or don't want) that 'stuff' cranking on your 'client' box, but the 'beefy' enterprise box - issuing the workflow and storing the logs for the job in an organized manner.

    Think of your box as only an authorized client talking to the machine where the log are being written to. Configured that way, you the admin, watcher or workflow responder can be on different boxes at different times, checking up on watching your baby every now and then, do its work over an extended period of time.

    - Life with PowerShell keeps getting better and better.
    Best regards guys-

  2. Dave Carnahan

    At the 50,000 foot level, workflow to me is a mainframe concept applied to today's technology.

    No one person, but rather a team, has responsibility over an activity - to build, execute, respond and correct the activity (or workflow).

    The activity could be a 7 by 24 perpetual job to monitor infrastructure, device well-being, or apps built to deliver a key product for the company. In this scenario, requirements can often bend and the glue to keep this whole must adhere.

    From a CIO's perspective, a certain type of activity must exist in their enterprise because of the nature of the business. Whether the support FTE's come an 'administrator', Help desk, database, network or development unit (or maybe one or more from each) - so x number of units might be required - to support the workflow well-being. That's the advantage gained by allowing this type activity.

    The bottom line is that they all need to get into the core area to do this chunk of work along with their other responsibilities.

    The team - all might have to get in and take a look around, maybe because of the statistics of the beast (min, max duration of runs, what else is concurrently is using the same resources?)

    Maybe to make tweaks in certain types of jobs, you don't really know until you start doing the work, what you might need to make 'it' easier.

Comments are closed.

denizli escort samsun escort muğla escort ataşehir escort kuşadası escort