Using PowerShell to make Azure Automation Graphical Runbooks – Part 2

The first article in this series introduced the Azure Automation Graphical SDK, targeting its use to produce a programmatic version of an existing graphical runbook, Get-DiceThrow. It then began covering the classes used by the SDK, referencing the portal elements and associated ones.

This second article continues the above, focusing on the largest and most challenging part of developing in this SDK, Activities.

Activities

An Activity refers to an action that is represented by an individual item on the graphic runook. Multiple Activity classes are available to be used. In the runbook we are developing, these are CommandActivity and WorkflowScriptActivity.

Workflow Script Activities

The WorkflowScriptActivity was briefly covered in the first article, when Workflows were outlined. As mentioned above, a workflow script activity is handled by the WorkflowScriptActivity class.

When an instance of this class is made, the following properties are available. Of these, only the first four are native to the class, with the other properties being inherited.

  • Begin
  • Process
  • End
  • CheckpointAfter
  • LoopExitCondition
  • EffectiveLoopExitCondition
  • LoopDelay
  • Name
  • EntityId
  • PositionX
  • PositionY
  • Description

Of note is that the Begin, Process and End properties match the options available in PowerShell advanced functions, providing the opportunity to perform pre-processing, record by record, and post-processing operations respectively.

In the script, Name, Process, PositionX, and PositionY are set. Name is visible on the graphical workbook diagram, as the text label on the activity. Process is the actual script being used. PositionX and PositionY dictate the location on the canvas of the activity.

 

Command Activities

Not mentioned yet are the command activities. A command activity is represented by the CommandActivity class.

On its own the CommandActivity class has a minimal number of properties that are available. From the screenshot below, only Name and Description are represented directly in this class.

4 - Command Activities

However, when a CommandActivity class is instantiated, other inhertied properties are available, making the following

  • CommandType
  • InvocationActivityType
  • ParameterSetName
  • Parameters
  • CustomParameters
  • CheckpointAfter
  • LoopExitCondition
  • EffectiveLoopExitCondition
  • LoopDelay
  • Name
  • EntityId
  • PositionX
  • PositionY
  • Description

Name, PositionX, and PositionY are implemented for the same use as that mentioned in the workflow script activity mentioned above. Also of note is EntityID, which is a unique identifier for the activity.

For the runbook we are developing CommandType, ParameterSetName, and Parameters to be set.

The first of these, CommandType, refers to one of the available Activity Types in the SDK.

Activity Types

Activity types detail the properties that make the action ‘tick’. That is, it describes what the activity does.

The CommandActivityType class has three properties that we set in the Runbook :

CommandName is the actual command. e.g. Write-Output

ModuleName refers to the module in which the command can be found. Write-Output for example uses Microsoft.PowerShell.Utility

5 - cmdlets

The next article in this series will cover the use of Parameters, and ParameterSets in an activity type, and the classes used by them.

Thanks for reading,

Tim

Leave a Reply

Your email address will not be published. Required fields are marked *