variables to provide execution context
Please provide built in variables so that an executing runbook can know stuff about itself. e.g.:
-Me (would return the name of the runbook).
Here's an example of why this would be useful. I want to call New-AzureAutomationSchedule & Register-AzureAutomationScheduledRunbook so that the current executing runbook can schedule itself to run again after a specified period of time. Unfortunately New-AzureAutomationSchedule has a required parameter "AutomationAccountName". This obviously isn't something that I want to hardcode into the runbook so I need a way to access the containing account. The only way to do this is to deploy a variable that contains the name of the account.
This Is. Stupid. Please just provide a built-in variable that always returns the name of the account.
Another example. At the start of each runbook I would like to call a utility function that writes the name of the runbook to the verbose output stream. If there were a variable called "Me" that returned the name of the runbook then i could simply pass that variable value to my utility function.
Unfortunately there are not resources to work on this request, so we are closing it to give you heads up. We appreciate your feedback and ask you to keep providing it.
Khandelwal, Nikhil commented
You can get the current job Id from the $PSPrivateMetadata variable in a runbook.
Wayne Hoggett commented
We could use the Automation Account name and Runbook name as well, as simple variables. Also it would be nice to have these not just in workflow Runbooks. A variable asset will work, but sometimes we just need it to whatever Account and Runbook context we are in.
Trevor Sullivan [MVP] commented
This kind of information is sometimes essential, depending on the purpose of the Runbook. Any kind of "meta" Runbooks might need access to these fields:
- The Resource Group Name that the Automation Account belongs to
- The Automation Account that the Runbook belongs to
- The name of the Runbook
- The execution time of the Runbook
- The current Runbook instance's Job ID
- The Azure subscription ID, and name, that the Runbook belongs to
Microsoft MVP: PowerShell
Tim Curwick commented
I can't specifically speak to how long $WorkflowCommandName has been available in Azure Automation, but I believe it exists at the Windows Workflow layer, rather than being an AA or SMA feature. I found it last August when I was working with SMA. http://www.madwithpowershell.com/2014/08/get-name-of-powershell-script-or.html
If you look at the XAML translation of a workflow, you will see WorkflowCommandName defined in the Sequence.Variables at the bottom.
Jamie Thomson commented
Is $WorkflowCommandName something new? Pretty sure it wasn't there a year or so ago when I was looking into this.
Tim Curwick commented
There is already a built-in variable for returning the name of the runbook: $WorkflowCommandName
Within an inline script, you would, of course, use $Using:WorkflowCommandName
Andy Bates commented
I can only second this, to be able to get context information for the current job and automation account name!
This is probably not quite what you are looking for with the "Me" variable, but close as it gets the parent runbook instead of the current runbook. This code will find the runbook that started the chain of runbooks. IE. If you have Runbook1 that calls Runbook2 and you have this code in Runbook2, then this will set $strRunbookName to "Runbook1". You will notice that $ParentJobName is not defined anywhere...this is a reserved variable. I'm not sure if there is a reserved variable for the current job name though.
$strWebServicePoint = "https://$strSMAMgmtServer"
$objRunbookJob = Get-SmaJob -WebServiceEndpoint $strWebServicePoint -ID $ParentJobName
$strRunbookID = ($objRunbookJob.RunbookID | Select -First 1).GUID
$objRunbook = Get-SmaRunbook -WebServiceEndPoint $strWebServicePoint -Id $strRunbookID
$strRunbookName = $objRunbook.RunbookName