{"id":2241,"date":"2012-07-21T13:06:00","date_gmt":"2012-07-21T13:06:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/powershell\/2012\/07\/21\/new-workflow-makeiteasy-authoring-workflows-using-powershell-extended-syntax\/"},"modified":"2024-02-26T11:59:43","modified_gmt":"2024-02-26T19:59:43","slug":"new-workflow-makeiteasy-authoring-workflows-using-powershell-extended-syntax","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/powershell\/new-workflow-makeiteasy-authoring-workflows-using-powershell-extended-syntax\/","title":{"rendered":"New-Workflow \u2013MakeItEasy: Authoring Workflows using PowerShell Extended Syntax"},"content":{"rendered":"

Some time back, in his blog post<\/a>, Jeffrey Snover introduced one of the new Windows PowerShell 3.0 feature \u2013 Windows PowerShell Workflow<\/strong>. In that post, you saw a glimpse of how to author workflows using PowerShell syntax. This post dives into more details of authoring workflows using PowerShell syntax and various extensions to it.<\/p>\n

Why we chose to extend the PowerShell Language for Workflow Authoring<\/h2>\n

As Jeffrey mentioned in that blog post, Windows Workflow Foundation traditionally has been a developer-focused feature that requires Visual Studio and a lot of code to create a solution. To review the solution, another person has to understand XAML or they have to install Workflow Designer. Authoring workflows by using Windows PowerShell is much easier and overcomes the development hurdles. Additionally, you get the benefit of sharing the workflows by simply pasting them into an email or publishing them online.<\/p>\n

Another reason, as pointed out in another blog post<\/a>, is our promise to the PowerShell community about learning once and reusing that knowledge over and over again:<\/p>\n

\u201c \u2026 We respect your investment in learning Windows PowerShell by reusing concepts over and over to make sure learning Windows PowerShell was the best thing you ever did. \u2026\u201d<\/i><\/b><\/i><\/b><\/p><\/blockquote>\n

While designing the workflow authoring experience, we kept this promise in mind. We also thought of ways to work with existing tools and, hence, came up with two approaches to workflow authoring:<\/p>\n

    \n
  1. Script-based Workflow Authoring<\/b>: Leverage and extend the PowerShell language for workflows so IT Pros can reuse their existing PowerShell scripting skills.<\/li>\n
  2. XAML-based Workflow Authoring:<\/b> Plug into the Visual Studio Workflow Designer experience so developers can easily get the management activities in their existing environment and continue leveraging their XAML and Visual Studio knowledge.<\/li>\n<\/ol>\n

    This post will dive into details of the former approach for workflow authoring: PowerShell script-based workflows. In a later blog post, we will look into the XAML-based authoring experience.<\/p>\n

    Although there are multiple ways to showcase the new script-based workflow experience, we will explain it by using a real-world example: Creating virtual machines on a Hyper-V capable host machine and joining those virtual machines to a domain.<\/span> This example is a good workflow sample because it has all the necessary workflow characteristics \u2013 long running task across multiple machines that require robustness due to machine reboots.<\/p>\n

    The benefit of this approach is that by the end of this blog, you will have a real-world workflow sample that can easily be used in your environment. \"Image<\/a><\/p>\n

    Workflow Extensions to the PowerShell Language<\/h2>\n

    In next couple of sections, we will look at various extensions to the PowerShell language that expose and enable Windows Workflow Foundation concepts.<\/p>\n

    Workflow Keyword<\/h3>\n

    The most important of extensions to the PowerShell language is the workflow<\/b> keyword. To create a workflow, use the workflow<\/b> keyword, followed by a name for the workflow and, then, followed by the body of the workflow, such as:<\/p>\n

    \"Image<\/a><\/p>\n

    As you can see, if you know how to write a PowerShell function, you are 80% on the way to being able to write a workflow.<\/p>\n

    Note: The behavior of a workflow is different than a function and it has a few more rules that we will delve into in another blog post soon.<\/i><\/p>\n

    After knowing how easy it is to create a workflow, let\u2019s build our workflow for creating virtual machines (VM). We will name it Install-VM<\/b> \u2013 using a verb-noun name just like those of any other PowerShell command. We will add parameters to our workflow that will specify virtual hard disk (VHD) location for VMs, default prefix for VM name and the number of VM to create.<\/p>\n

    \"Image<\/a><\/p>\n

    Note: As you might notice, in Windows PowerShell Workflow, you can specify default values for the parameters, just like you do in functions.<\/i><\/p><\/blockquote>\n

    In the example above, notice that Windows PowerShell ISE recognizes the workflow and its content and colorizes them appropriately, just like it does for any other PowerShell command.<\/p>\n

    <\/a>Parallel Execution<\/h3>\n

    The underlying Windows Workflow Foundation runtime supports running activities or commands in parallel. We expose this capability in Windows PowerShell Workflow through the parallel<\/b> keyword, as well as foreach-paralle<\/b>l, an enhancement to the ForEach statement. With parallel execution, you can significantly reduce the operation time across a set of machines.<\/p>\n

    Additionally, to execute a collection of activities or commands in order (not in parallel) within a parallel <\/b>block, use the sequence <\/b>block, such as:<\/p>\n

    \"Image<\/a><\/p>\n

    Now let\u2019s go back to our previous Install-VM<\/a> workflow. We’ll use a foreach \u2013parallel <\/b>block to add logic for creating VMs in parallel.<\/p>\n

    \"Image<\/a><\/p>\n

    Note: In order to call New-VM<\/b> and New-VHD<\/b> commands, you need to install Hyper-V module.<\/i><\/p><\/blockquote>\n

    Checkpoint Workflow Execution<\/h3>\n

    Windows Workflow Foundation allows a workflow to persist or checkpoint all aspects of its state by using an explicit call to the Persist<\/b> activity. The same feature is exposed through the Checkpoint-Workflow<\/b> command in Windows PowerShell Workflow.. With the use of Checkpoint-Workflow,<\/b> Window PowerShell Workflow checkpoints the workflow state and saves the workflow data to the persistence store. In case of unintended interruptions (machine reboot, process crash, network disruption, etc.), the workflow execution resumes from the last persistence point. Alternatively, to achieve similar results, you can add -PSPersist $true<\/b> at the end of an activity or command.<\/p>\n

    Now let\u2019s add a Checkpoint-Workflow<\/b> call to our previous Install-VM<\/a> workflow to save the workflow state.<\/p>\n

    \"Image<\/a><\/p>\n

    Note: Just look at the param<\/b> and foreach \u2013parallel<\/b> block above and you will notice another cool ISE feature: <\/i>collapsible regions.<\/i><\/p><\/blockquote>\n

    <\/a>InlineScript: Running Isolated Blocks of Windows PowerShell Script<\/h3>\n

    By default, each command in a workflow is executed with no PowerShell state sharing. Variables created by one command are not visible to the next command. But, by using the inlineScript<\/b> keyword it is possible to execute a collection of PowerShell commands as a single execution unit<\/p>\n

    \"Image<\/a><\/p>\n

    Note: As mentioned in section 5 of <\/i>PowerShell Workflow architecture<\/i><\/a>, for reliability reasons, by default, inlineScript<\/b> runs in a separate process<\/i><\/i><\/p><\/blockquote>\n

    <\/a>Accessing Workflow Variables from Different Execution Scopes<\/h3>\n

    Just like PowerShell remoting in PowerShell 3.0, Windows PowerShell Workflow supports the $Using:<variable name> <\/b>scope modifier. This new scope modifier can access workflow variables into the context of an inlineScript<\/a>.<\/p>\n

    Unlike PowerShell, Windows Workflow Foundation does not support dynamic scoping of variables. This means that a variable that is defined in the parent scope cannot be redefined in a child scope. In Windows PowerShell Workflow, to change a workflow-scoped variable from any inner scope, use the $workflow:<variable name> <\/b>scope modifier.<\/p>\n

    \"Image<\/a><\/p>\n

    Now, we will use our new foreach -parallel<\/a>, inlineScript<\/a> and $using<\/a> concepts, to update our previous Install-VM<\/a> <\/b>workflow by adding logic for starting the VMs and getting their IP addresses in parallel.<\/p>\n

    \"Image<\/a><\/p>\n

    Note: All the commands in workflow have a \u2013DisplayName<\/b> common parameter to provide a custom or friendly name for the command. In the previous example, we used it on inlineScript<\/b>.<\/i><\/p><\/blockquote>\n

    Suspending a Workflow from within the workflow<\/h3>\n

    Windows PowerShell Workflow has a Suspend-Workflow<\/b> command that suspends the workflow during its execution. This command gives the workflow author complete control over the workflow suspension behavior independent of the workflow user. For example, a workflow can detect a problem that requires manual intervention, notify the operator of this condition, and then suspend operations until the operator corrects the situation and resumes the workflow.<\/p>\n

    Let us update our previous Install-VM<\/a> <\/b>workflow to send an email to a senior admin and suspend itself. Once the senior admin gets the email, he\/she can resume the workflow manually.<\/p>\n

    \"Image<\/a><\/p>\n

    Additionally, you can integrate the workflow execution with the Management Odata IIS Extension feature<\/a> of Windows Server 2012 to manage workflows from any Windows or non-Windows device that can understand HTTP requests. The PowerShell team demonstrated this feature at TechEd North America and TechEd Europe 2012. You can see a recording of this session here<\/a> (look at the 1:03:17 mark).<\/p>\n

    Workflow Calling Workflow<\/h3>\n

    This feature of Windows PowerShell Workflow enables you to re-use workflows to create higher-level workflows, while leveraging your existing workflow investment, workflows from other users, and workflows from the PowerShell Community. To use this feature, the child workflow (e.g. Join-Domain<\/b>) must be defined and imported into the PowerShell session in which the parent workflow is defined..<\/p>\n

    Let\u2019s define a Join-Domain<\/b> workflow that joins a machine to a domain. To complete the scenario, we will call Join-Domain<\/b> from our Install-VM <\/b>workflow.<\/p>\n

    \"Image<\/a><\/p>\n

    Updated Install-VM <\/b>workflow looks like as follows (and script is attached at the end of the blog post):<\/p>\n

    \"Image<\/a><\/p>\n

    NOTE: Notice that the param block of Install-VM<\/b> has two additional parameters: $domainCred and $localCred. The Join-Domain<\/b> workflow needs these values. <\/i><\/p><\/blockquote>\n

    Additionally, you can define nested functions or nested workflows inside the workflows as well, such as:<\/p>\n

    \"Image<\/a><\/p>\n

    Finding and Running Your Workflow<\/h3>\n

    As explained by Mir Rosenberg in an earlier blog post<\/a>, Windows PowerShell Workflows behave just like other Windows PowerShell commands. You can discover them by using Get-Command:<\/b><\/p>\n

    \"Image<\/a><\/p>\n

    You can run them interactively or use the AsJob <\/b>common parameter of workflows to run any workflow as a background job.<\/p>\n

    \"Image<\/a><\/p>\n

    \"Image<\/a><\/p>\n

    Join-In<\/h3>\n

    Now that you know how easy it is to author workflows using PowerShell syntax, please try your hand at creating couple of workflows for long-running multi-machine scenarios and tell us about your experience (and feature requests J ). As always, you can send feedback directly to us by using the Windows PowerShell Connect site<\/a>.<\/p>\n

    While we create our next set of blog posts about Windows PowerShell Workflow, enjoy some additional resources about Windows PowerShell 3.0 and Windows PowerShell Workflow:<\/p>\n