There are always interesting shortcuts and magical techniques to discover in PowerShell, and “splatting” is one of them. Splatting allows you to bundle a set of parameters into a hashtable and then simply using it as single parameter to a PowerShell function or cmdlet. For example, instead of specifying a command line with a bunch of parameters in a long command line like this (which could get longer):

Get-WmiObject –computername SERVER-R2 –class Win32_LogicalDisk –filter "DriveType=3" –credential "Administrator"

You can use a hashtable to define parametername – value pairs like this:

$params = @{'class'='Win32_BIOS'; 
           'computername'='SERVER-R2'; 
           'filter'='drivetype=3';
           'credential'='Administrator' }

And then all you need to do is specify a command line like this:

Get-WMIObject @params

While initially this may not seem like such a magical solution, the more parameters you have to a script, function or cmdlet, the more elegant this becomes. Now take this concept and apply it to activities in a runbook, either using the Run .NET Script activity or using custom activities built using the Command Line Activity Wizard in the Toolkit. You can imagine that having to create 10 or 20 input parameters or the same number of outputs for an activity can be kind of cumbersome.

Here’s what a custom command-line activity would look like if you called it with 10 parameters:

image

You can’t even see all of the command line or the parameters in the same screen!

Or, here is what the Run .Net Script activity would look like with 10 output parameters:

image

Now imagine having to map individual published data items to and from these inputs and outputs across several activities. Well that’s how many people build runbooks with PowerShell. Believe me when I tell you that splatting is WAY easier!

Here’s an example of using splatting. First of all, I’ll start the runbook with an Initialize Data activity in order to gather the 10 parameters I need:

image

Next I need to convert those 10 individual inputs into a “here-string”, which is essentially a multi-line string:

image

Now that’s the hardest you’ll have to work in the whole runbook, because from now on, you can really simplify by using splatting. In the next activity I have a function that uses these parameters.In order to use these parameters, I will need to wrap the string that comes from Published Data in a “here-string” again, because when it’s created in the first activity, it’s actually an object type and gets output to string for the databus (but it retains the line breaks). When transferred on the databus it loses it’s “object-like” nature, so it needs to be put into an object again. I then use the “ConvertFrom-StringData” cmdlet to convert the string into a hashtable.

image

At the end of this script, I just call the function with the following command line:

Test-MyCode @params

Now you might be saying this simple example doesn’t really show me how I would save time with splatting, because I still had to create an Initialize Data activity with 10 parameters, and I had to put in an extra activity to create the here-string before I got to my script. OK, well, you’re right. Sort of. What I *didn’t* have to do was to create 10 special PowerShell input or output parameters like I showed above. I’ve also set myself up for an easier time if I decide to re-user this script activity in a number of other runbooks. I know that whenever I need to re-use it, I can just send it a single parameter as a here-string and it will take care of all the parameters it needs.

I also know that if I need to pass data from one Run .Net Script activity to another, I don’t have to transfer anything other than one parameter, and simply do it as a here-string and then convert to a hashtable for splatting. Now passing data across multiple script activities gets a LOT easier and less time consuming (and less chance for error too).

So be sure to try this out and use it across your own scripting activities!