Return parameters for operation results

[MPARDINIRTP]

I'm working on a custom command in WFA for polling two controllers for option differences. I have the results in an array, but I'm having a hard time figuring out how to get that output to the workflow user. I see the return parameters tab in the workflow results window and I'm wondering how I can get the results into that tab so the user can see the differences. Any ideas?

[paragp]

This is possible in WFA 2.2RC and onwards.  If you are using powershell commands you will need to add this line in your command

Add-WfaWorkflowParameter -Name volumeOptions -Value $volOptions -AddAsReturnParameter

and for perl it is

my $wfaUtil = WFAUtil->new();

$wfaUtil->addWfaWorkflowParameter(‘volumeOptions’, $volOptions, 1);

  The Add-WfaWorkflowParameter and Get-WfaWorkflowParameter are primarily used for transferring information between commands during execution. The last parameter -AddAsReturnParameter adds the value as a return parameter to the workflow

[sinhaa]

Add-WfaWorkflowParameter -Name volumeOptions -Value $volOptions -AddAsReturnParameter

-Value takes only a string argument, and as you said you have an Array, you can't use the array object directly. I suggest you join the array object to a string and then use it in the above command.. Something like below.

# Joining on a colon :

$volOptions = $volArray -join ":"

Add-WfaWorkflowParameter -Name volumeOptions -Value $volOptions -AddAsReturnParameter

[MPARDINIRTP]

Thanks for the info. I'll run an upgrade and try it out!

[francoisbnc]

Is there any improvements in wfa 4.0 version with Add-WfaWorkflowParameter.

Francois

[abhit]

No.

Anything specific you are looking for?

Regards

Abhi

[francoisbnc]

I think the main missing thing is add-wfaworkflowparameter accept only [string] type. Array of objects  will be great.

François

[sinhaa]

@francoisbnc

It may not be possible for the WFA cmdlets to accomodate other data types like array or hash etc.

But there is a simple way to get this done. You can easily use join and spilt methods to join the elements of an array to form a string.

 $a= @("1","2","3")

 $value = [System.String]::Join("~",$a)   #Choose a separator which you are sure not an element in the array. Typically ~ or _ can work,

Add-WfaWorkflowParameter -Name "MyArray" -Value $Value

-----

In the next command where you want this array, get the value and call split on it.

$value = Get-WfaWorkflowParameter -Name "MyArray"

$a = $value.Split("~")

Now you got your Array as you wanted.

Similar methods are available in Perl for the WFA command in perl.

sinhaa

[sinhaa]

@francoisbnc

I think you wanted array of Objects  and not just an array, did you?

This is not possible with cmdlet, the cmdlet writes this dynamic name-value pair into a file and then fetches this data back to you. 

The same join-split can help you in this case too.

sinhaa

[francoisbnc]

Yes it is.

Many return values is difficult to read and maintain, a simple objet or array of objects would simple to manage.

[sinhaa]

@francoisbnc

If you want to pass an object or even a array of objects between WFA commands, powershell itself provided you ways to do it. 

You can use Powershell cmdlet Export-Clixml to save the object into the file in comamnd-1

and Import-Clixml to retrieve that object from the above file in command-2

See how to use them here. If you need assistance in using this cmdlets, I can help as well.

sinhaa

[francoisbnc]

I will have a try. Many thanks.

[sinhaa]

@francoisbnc

It works like this:

In command-1

===

#Have an object parameter. Not string but a Powershell Object. You can have any data type, strings, arrays, array of objects.

$Date = Get-Date

Export-Clixml -Path ".\date.xml" -InputObject $Date

#It will create a file date.xml in the WFA temp directory. You can choose any other path as well

=====

In command-2

==

$Date = Import-Clixml -Path ".\date.xml"

#The date object is obtained successfully. Now you can call all methods on this obtained object as you could.

$Date.day

====

sinhaa

[francoisbnc]

@sinhaa

Your workaround looks good thanks, but just in case of simultaneous run of same workflow, I have to manage to name of the export file that cannot be the same.

I can add a random number at the end, pass it  to the next command with add-wfaparameter,  not so simple to have a clear overview of the workflow at the first look.

[mbeattie]

Hi @francoisbnc

Assuming you want to pass an array of variables between WFA commands within a workflow (without using the Add-WfaWorkflowParameter cmdlet) and you are exporting those variables to file locally on your WFA server, then the file name would need to be constant to ensure all the commands in your WFA workflow read the content from the same file name. To achieve that you might consider using the workflow ID as the file name as this is a unique identifier. EG

$workflowID = $(Get-WfaRestParameter "workflowId")

Also you might consider using a system environment variable or reading the registry to determine the file path (or the install location of WFA) as a path to save any temporary files.

Something like this:

#'------------------------------------------------------------------------------
#'Enumerate the WFA install path from the registry
#'------------------------------------------------------------------------------
[String]$registryPath = "hklm:\system\currentcontrolset\services\na_wfa_srv";
[Int]$workflowID      = $(Get-WfaRestParameter "workflowId")
Try{
   [System.Object]$result  = Get-ItemProperty -Path $registryPath -ErrorAction Stop
   [String]$wfaExeSpec     = $result.ImagePath.Split("/")[0].Trim() -Replace("""", "")
   [String]$wfaServicePath = $wfaExeSpec.SubString(0, $wfaExeSpec.LastIndexOf("\"))
   [String]$installPath    = $wfaServicePath.SubString(0, $wfaServicePath.LastIndexOf("\"))
   Get-WFALogger -Info -Message "Enumerated WFA installation Path from Registry key ""$registryPath"" as ""$installPath"""
}Catch{
   Get-WFALogger -Error -Message $("Failed Reading Registry Path ""$registryPath"". Error " + $_.Exception.Message)
   Throw "Failed Reading Registry Path ""$registryPath"""
}
#'------------------------------------------------------------------------------
#'Ensure the workflows XML file exists.
#'------------------------------------------------------------------------------
[String]$fileSpec = "$installPath\$workflowID.xml"
If(Test-Path -Path $fileSpec){
   Get-WFALogger -Info -Message "Reading WFA workflow XML file ""$fileSpec"""
}Else{
   Throw "The WFA workflow XML file ""$fileSpec"" does not exist"
}
#'------------------------------------------------------------------------------

Assuming you are creating custom WFA commands, each command can enumerate the current workflow ID and hence read from the correct configuration file which will ensure a uniquie file is created and read from for each workflow in the scenario where the workflow is being executed multiple times as the ID will always be unique.

Hope that helps

/Matt

[francoisbnc]

Did you speak of workflow id or runtime id?

Because, as we gave the WFA console to multiple users, workflows can be launched at the same time with a potential of multiple RW access on file.