3

Update:

After some digging around, I have found a page for Update-TypeData that that has a method that states:

-SerializationMethod
String: Serialize the type as a string. You can use the StringSerializationSource to specify a property of the type to use as the serialization result. Otherwise, the type is serialized by using the ToString method of the object.

This appears to be the problem I am having, however I can't run Update-TypeData in a workflow.

Original Question

I have the following code:

workflow Deploy-Template
{
    Param
    (
        $Credentials, $resourcegroup, $count
    )
    $PSDisableSerializationPreference = $true
    $results = @() 

    $collection = (1..$count) 
    sequence
    {

        foreach -parallel ($item in $collection)
        {
            $subs = Add-AzureRmAccount -Credential $Credentials

            $deploy = New-AzureRmResourceGroupDeployment -Name ([guid]::NewGuid()).guid.tostring() `
                                                    -ResourceGroupName $resourcegroup `
                                                    -TemplateFile "E:\tmp\storage.json"
            $obj= New-Object -type PSObject -Property  @{ 
            output = $deploy
            }
            $workflow:results += $obj
        }
        Write-Output $results 
    }
}

$value = Deploy-Template -Credentials $TenantObject.credential -resourcegroup $resourcegroup -count 1

When I run it and try to query the result I get:

PS > $value[0].output.Outputs.storageAccountName
Microsoft.Azure.Commands.ResourceManager.Cmdlets.SdkModels.DeploymentVariable


PS > $value[0].output.Outputs.storageAccountName | gm 
TypeName: System.String

I've poked around and changed things and it seems that when run within a Workflow $deploy the DeploymentVariable is made a string.

If I just run:

$deploy = New-AzureRmResourceGroupDeployment -Name ([guid]::NewGuid()).guid.tostring() `
                                        -ResourceGroupName $resourcegroup `
                                        -TemplateFile "E:\tmp\storage.json"

I get:

PS > $deploy.Outputs.storageAccountName.Value 
y74ek7r67mq6c

Which is what I'm expecting. (there is no value property when it runs in a workflow)

I tried running it through convertto-json but it is doing the same.

Why can't I get my object out of my workflow?

edited to add

The relevant section of the storage.json file is

"outputs": {
    "storageAccountName": {
        "type": "string",
        "value": "[variables('storageAccount')]"

Run outside of the workflow

$deploy.Outputs.storageAccountName.GetType()

IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True False DeploymentVariable System.Object

While inside the workflow gives

$value[0].output.Outputs.storageAccountName.gettype()

IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True String System.Object

Running the code inline produces the same result

$deploy = InlineScript
{
  New-AzureRmResourceGroupDeployment -Name ([guid]::NewGuid()).guid.tostring() `
                                        -ResourceGroupName $Using:resourcegroup `
                                        -TemplateFile "E:\Git\Simplifed-Azure-Templates\storage.json"
}
4
  • The data which is shown as data type name should go inside "$()". Commented Jun 10, 2016 at 14:54
  • @SavindraSingh putting output = $($deploy.outputs.storageAccountName) gives the same result also (as well as adding .value on the end) Commented Jun 10, 2016 at 15:26
  • is the return type the same? e. g. $value[0].output.GetType() on the workflow and $deploy.GetType() if you just run the New-AzureRmResourceGroupDeployment cmdlet? Also, do you have the Value property within your workspace? Commented Jun 12, 2016 at 18:38
  • @jisaak that's the part I don't understand, I have two different return types as you can see in the new part of the question. There is only a value property when it is run outside of the workflow. When it is inside the workspace it becomes a string and doesn't have a value property. Commented Jun 12, 2016 at 23:40

1 Answer 1

1

Objects in workflows are deserialized.

The InlineScript activity is useful when you need to run one or more commands as traditional PowerShell script instead of PowerShell workflow. While commands in a workflow are sent to Windows Workflow Foundation for processing, commands in an InlineScript block are processed by Windows PowerShell.

Source is the above link.

You probably have to wrap your invoke within an InlineScript:

You can return output from an InlineScript by assigning the output to a variable.

Try this:

workflow Deploy-Template
{
    Param
    (
        $Credentials, $resourcegroup, $count
    )
    $PSDisableSerializationPreference = $true
    $results = @() 


    $collection = (1..$count) 
    sequence
    {

        foreach -parallel ($item in $collection)
        {
            $workflow:results += InlineScript {
                $subs = Add-AzureRmAccount -Credential $Credentials

                $deploy = New-AzureRmResourceGroupDeployment -Name ([guid]::NewGuid()).guid.tostring() `
                                                        -ResourceGroupName $resourcegroup `
                                                        -TemplateFile "E:\tmp\storage.json"
                New-Object -type PSObject -Property  @{ 
                    output = $deploy
                }
            }
        }
        Write-Output $results 
    }
}

$value = Deploy-Template -Credentials $TenantObject.credential -resourcegroup $resourcegroup -count 1
Sign up to request clarification or add additional context in comments.

5 Comments

$PSDisableSerializationPreference = $true should stop deserialization being the problem - and running in a workflow gives the same output (I will amend the question) - P.S. your code didn't actually have the inlinescript bit in ;)
Did you tried to access $deploy.Outputs.storageAccountName.Value within the InlineScript within the `workflow´?
I did, but because $deploy.Outputs.storageAccountName is still a string, there is no value
hmm, sorry. Then I have no more ideas.
not a problem, thanks for the thought! I think it might be a problem with the depth of the object, but I've yet to prove that

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.