How one can repair ‘CliXml’ in parameter enter Azure Automation

Azure Automation, Begin-AutomationRunbook, parameters, & CliXml…

I’m not going to clarify what Clixml is, or what it means, nor am I going to clarify precisely why this subject is occurring (primarily as a result of I don’t have a transparent reply for you).

I’ll provide the resolution and a attainable option to make this simpler for you.

To forestall CliXml parameter enter, embed it in double quotes "$ParameterInput"

Sure, that easy…

In stead of this:

$Variable = Get-Variable DebugPreference
$Params = @{"string3"=$Variable}
Begin-AutomationRunbook -Title 'RunbookName' -Parameters $Params

Do that:

$Variable = Get-Variable DebugPreference
$Params = @{"string3"="$Variable"}
Begin-AutomationRunbook -Title 'RunbookName' -Parameters $Params

The double quotes embedded $Variable – "$Variable" is the one distinction…

To stroll by means of it fully, I first present what occurred after which we take a look at higher options later

The perform under is an instance.
I request a variable after which I go it within the -Parameters parameter (which is a HashTable, also called Dictionary) for Begin-AutomationRunbook (inside Azure Automation cmdlet).

$runbookName="Test2"
$Variable = Get-Variable DebugPreference
$Params = @{"string1"="ValueForPosition1";"string2"="ValueForPosition2";"string3"=$Variable}
Begin-AutomationRunbook -Title $RunbookName -Parameters $Params

After I ran this, I see that the runbook has began, however after I open it I see CliXml within the String3 enter.
That is the $Variable object I handed within the String3 parameter.

Someplace inside Azure Automation it’s transformed to CliXml.

And after I open the enter it will get even worse…

It seems to be prefer it’s JSON & XML. Happily, solely the wrapper round it has develop into JSON and the property CliXml incorporates the enter (sadly nonetheless CliXml).

{"CliXml":"<Objs Model="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04">rn <Obj RefId="0">rn <TN RefId="0">rn <T>System.Administration.Automation.PSVariable</T>rn <T>System.Object</T>rn </TN>rn <ToString>System.Administration.Automation.PSVariable</ToString>rn <Props>rn <S N="Title">DebugPreference</S>rn <S N="Description">Dictates the motion taken when a Debug message is delivered</S>rn <S N="Worth">SilentlyContinue</S>rn <S N="Visibility">Public</S>rn <Nil N="Module" />rn <S N="ModuleName"></S>rn <S N="Choices">None</S>rn <Obj N="Attributes" RefId="1">rn <TN RefId="1">rn <T>System.Administration.Automation.PSVariableAttributeCollection</T>rn <T>System.Collections.ObjectModel.Assortment`1[[System.Attribute, System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]</T>rn <T>System.Object</T>rn </TN>rn <LST>rn <S>System.Administration.Automation.ArgumentTypeConverterAttribute</S>rn </LST>rn </Obj>rn </Props>rn </Obj>rn</Objs>"}

Let’s check out the runbook that’s began

The runbook’s content material and output:

param (
	$string1,
	$string2,
	$string3
)

Write-Output $String1
Write-Output $string2
Write-Output $String3

ValueForPosition1
ValueForPosition2
CliXml                                                                                                                  
------                                                                                                                  
<Objs Model="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04">...   

Apart from the truth that we will convert the XML to a PSObject ourselves, we will do little else right here.

As well as, changing Xml to a PSObject is tough. I wouldn’t burn my fingers on it (until the XML is all the time the identical)

So, what’s inflicting the CliXml?

However then why is that this occurring? At first I assumed I had a semi reply, however sadly it’s not appropriate as a result of it additionally happens in PS5.

I assumed that one thing went improper whereas changing the parameters to an object as a result of PS7 is constructed on dotnet core.
I’m guessing there’s nonetheless one thing improper right here, however sadly I can’t put my finger on it.

Parameters as JSON is an effective substitute!

The utmost parameters for Runbooks is 50 parameters.

Now, after all, you’re nearly by no means going to succeed in this, however I don’t like limitations.
The answer for that is 1 parameter that incorporates JSON which you then pars in your runbook to a PSObject.

Check out the instance under:

$runbookName="Test2"
$Variable = Get-Variable DebugPreference
$JsonString = @{
	String1 = 'String1'
	String2 = 'String2'
	String3 = $Variable
} | ConvertTo-Json -Compress
$Params = @{"Json"="$JsonString"}
Begin-AutomationRunbook -Title $RunbookName -Parameters $Params

As a substitute of including 3 parameter values I’ve 1 JsonString, which I transformed to JSON with ConvertTo-Json.

then I go this within the -Json parameter, after which it’s as much as the runbook you name to parse the JSON to a PSObject.

See under the runbook that known as and the consequence:

param (
$Json
)

$Content material = ($Json) | ConvertFrom-Json
Write-Output $Content material

String1 String3
------- -------                                                                
String1 @{Title=DebugPreference; Description=Dictates the motion taken when a D…

Associated