4

Using PowerShell Switch vs. Boolean Parameters in SMA Runbooks

Using PowerShell Switch vs. Boolean Parameters in SMA Runbooks

Hey Readers.  In this article, I wanted to take the opportunity to talk about a scenario that may be “edge case” but a case just the same within the constructs of leveraging switch parameters in PowerShell workflow.  In fact, this scenario becomes less of an edge case as you start to write SMA Runbooks that leverage nested Runbooks.  Still don’t know what SMA is and want more information?  Check out the series http://aka.ms/IntroToSMA and my first article for PowerShell Magazine here http://www.powershellmagazine.com/2013/12/11/be-smart-with-windows-azure-pack-and-sma/ for more information.

Scenario

For me, a journey started with PowerShell workflow as I started diving into SMA (Service Management Automation). SMA leverages PowerShell workflow under the hood for its automation engine.  Due to the nature of how SMA uses inline Runbooks (PowerShell workflow) to execute tasks and return back to the main calling Runbook, certain behaviors exist that may be unexpected. In this scenario, the switch parameter capabilities get somewhat lost and your approach will need to change to accommodate.  Here are some examples to illustrate.

Example 1

Executing a PowerShell workflow directly specifying a switch parameter (not nested)

Workflow Invoke-NestedWorkflow
{
    Param([switch]$SomeSwitch)
    $SomeSwitch.IsPresent
}

Invoke-NestedWorkflow -SomeSwitch

Example 1 Results

image001

A switch parameter was sent that should indicate a value of True and in fact was validated as True. No surprises.

Example 2

To mimic a nested Runbook in SMA, I’ve combined two workflows and am leveraging a switch parameter.


Workflow Invoke-NestedWorkflow
{
    Param([switch]$SomeSwitch)
    "I'm in the nested Runbook"
    $SomeSwitch.IsPresent
}

Workflow Invoke-ParentWorkflow
{
    "I'm in the parent Runbook"
    Invoke-NestedWorkFlow -SomeSwitch
}

Invoke-ParentWorkflow

Example 2 Results

image002

This time you’ll notice that as we send -SomeSwitch into the nested workflow, it is not interpreted properly and we receive an error message. [PowerShell v4]

Same script [PowerShell v3 below]

image003

Note  Different results between versions of PowerShell but error(s) still thrown.

Example 3

In order to retain the switch parameter, you have to do some extra work and it isn’t necessarily as clean as a native PowerShell switch parameter usually is.  Specifying -SomeSwitch:$True now allows you to retain the “$True” through the execution on this switch parameter.  But it isn’t pretty :).

Workflow Invoke-NestedWorkflow
{
    Param([switch]$SomeSwitch)
    "I'm in the nested Runbook"
    $SomeSwitch.IsPresent
}

Workflow Invoke-ParentWorkflow
{

    "I'm in the parent Runbook"
    Invoke-NestedWorkFlow -SomeSwitch:$true
}

Invoke-ParentWorkflow

Example 3 Results(no errors and True retained)

image004

Example 4 [Recommendation]

Why not use Boolean?  We’re nearly there anyway at this point.  See below, the call to the parent Runbook is now using -SomeSwitch $True. Instead of -SomeSwitch:$True and the parameter types have been updated to [bool].

Workflow Invoke-NestedWorkflow
{
    Param([bool]$SomeSwitch)
    "I'm in the nested Runbook"
    $SomeSwitch
}

Workflow Invoke-ParentWorkflow
{
    "I'm in the parent Runbook"
    Invoke-NestedWorkFlow -SomeSwitch $true
}

Invoke-ParentWorkflow

Note -SomeSwitch is now a Boolean parameter and should be renamed of course, but left “as is” for consistency.

Example 4 Results

image005

Summary and Takeaways

So in summary, switch parameters used in SMA (and nested PowerShell workflow) can still be used but require some modifications to function properly.  Taking a closer look, Booleans fit nicely here and take on their native look at feel so why not use them instead!  Want to get a bit more information on where this topic came from?  Check out this blog post Automation–Service Management Automation–SMA Runbook Toolkit Spotlight–SMART for Runbook Import and Export on the Building Clouds blog that triggered this topic where Aleksandar Nikolic and me debated on this subject which ended up driving quality and awareness around SMA and PowerShell workflow!

Till next time …

Happy Automating!

Filed in: Articles, Online Only Tags: , , , , ,

2 Pingbacks/Trackbacks

4 Responses to "Using PowerShell Switch vs. Boolean Parameters in SMA Runbooks"

  1. Rob Campbell says:

    Another option is to leave it as a [switch] parameter and use [bool]::Parse() to evaluate it in the workflow script. That will return $True on both $True and the string value ‘True’. Your parameters can remain consistent through the workflow functions and you don’t need to remember to use the -Parameter:Value syntax for the switches.

  2. Greg Bray says:

    Looks like there are a number of differences when using workflows vs native PowerShell scripts. The workflow is being converted to Windows Workflow Foundation, which has different requirements than native PowerShell. You have highlighted one difference, but there are many others described at http://technet.microsoft.com/en-us/magazine/dn151046.aspx

    Also the Switch parameter is more like a nullable bool that defaults to $true when -SomeSwitch is included. When the switch is not included then the value is null or not specified ($SomeSwitch.IsPresent would equal $false). Using -SomeSwitch:$false is the only way to set the value of $SomeSwitch to false, as -SomeSwitch $false is not valid syntax for setting the parameter to false.

    Keep up the great work!

Leave a Reply

Submit Comment

© 2014 PowerShell Magazine. All rights reserved. XHTML / CSS Valid.
Proudly designed by Theme Junkie.
%d bloggers like this: