mitchelldavis.github.io

home

PSAL

18 Feb 2014

President's Day presented a long weekend for me this last weekend. I had already done everything around the house that needed to be done, so I wanted to persue a coding project. See if I could get a projects started and completed in a single weekend. Well, plus one day given the holiday. This idea came to me while working on some PowerShell scripts. Those scripts were calling cmdlets (pronounced command let) that I would consider critical and that I did not want ran every time I tested the script. Cmdlets that would send e-mails, or access Ftp servers. An immediate solution would be to abstract those cmdlets, and set a switch to determine if the abstractions were calling the base cmdlets or not. I did that and it seemed to work. So, why not setup a small framework to allow this abstraction to happen in a little more automatic fashion.

What came out of this is PSAL-PowerShell Abstraction Layer. This is a simple module that, once imported, has a few cmdlets that can be used to interact with an abstraction layer.

Import-Module .\psal.psm1
# To see a simple write up of how to use the module.
Get-Help about_PSAL

Some of the Commands

An Example

Import-Module .\psal.psm1
New-Abstraction "Invoke-Command"

#Now Call the Abstracted command.  It's always postfixed with 'Abstraction'.
Invoke-CommandAbstraction "TestServer" .\TestScript.ps1

Notice, this small script will execute the TestScript.ps1 script on the TestServer because the abstraction layer is off by default. Mix in an Enable-AbstractionLayer and the command will be properly abstracted so that the TestServer machine is never touched.

Credit where credit is due...

I want to give a shout out to @scottmuc for his work with Pester. Not only do I use it to test the PSAL module, I also got some inpiriation from the Mocking framework within Pester.