A quick disclaimer: This post assumes you already are fairly comfortable with SMA, PowerShell Workflow, and external authoring tools for PowerShell. If that’s not true, I highly encourage you to start by reading our earlier posts on SMA.
There are two main challenges when developing SMA runbooks that will be triggered by events in a Windows Azure Pack framework.
- You might not know all of the data that is available as part of the event.
- Testing with real events (and thus real data) can be tedious, slow, or difficult because of the need to repeatedly use the browser. If you do your development work in an external tool like the ISE, this becomes even more challenging.
I’ve run headlong into both of these during the last few months. The more complex the actions are, the more difficult it is to simulate the data and be sure you’re handling the events properly. In order to facilitate faster testing with 100% real data, I’ve come up with a simple solution: Create a runbook that exports the event data.
The high level idea is very simple:
- Create a runbook that exports the object data to PowerShell CLIXML
- Attach the runbook to the event you want to test with.
- Trigger the event via the WAP portal (or whatever method production would use)
- Collect the exported CLIXML file
- Import the CLIXML into PowerShell ISE or your preferred dev/test tool
Here’s a simple runbook that logs all executions of an event to a log directory, with a simple data/time stamp filename.
For simplicities’ sake, I have it simply saving the file to the local drive of the runbook worker. It would be trivial to change this to be a central network location if you have multiple runbook workers, and of course you can customize the filename to your liking.
Once you’ve collected your new XML file, you can use the Import-Clixml cmdlet to import it into a variable in your preferred PowerShell development tool. The possibilities are now limitless. You can use the object as input to your workflows, or simply examine the structure of the event to discover what kind of data is embedded for events of that type. That information will help you develop more powerful and effective automations.
In follow-up posts, we’ll cover some example events, the kind input objects available, and how and when different events are triggered. Combined with the above workflow, we’ll be able to create some very complex automation in a Windows Azure Pack environment.