Passing values from one command to another in a workflow

[dhrumins]

Hi

I want to write a workflow, which has multiple commands.

For one of the commands, I need to get the ID of the snapMirror relationship from the OnCommand server and for this purpose I need to invoke the OnCommand API.

After getting the relationship-id, I need to use this ID to do some other operations in the next command.

My question is how do I pipeline variable values between the various commands in a workflow? I can access the OnCommand database to obtain the information.

Thanks

Dhrumin

[hland]

Hi Dhrumin,

unfortunately it's not possible to pass information between commands but this functionality has been requested by several people before 😉

I see two possible workarounds. You can either write information to a file or database in the first command and then read it out again it the second command or you can build one large command instead of several smaller commands. Both solutions are ugly but I'd prefer the second option (and did this in one case already).

Regards

Hendrik

[dhrumins]

Thanks Hendrik for the reply.

I am kind of using the second option as well, but will need the variable passing moving forward.

I wanted to know how to write the information in the WFA database? Is there a wiki or a document that I can follow somewhere?

Thanks.

Dhrumin

[dhrumins]

Can I create a temporary schema and write to it as a part of a WFA command, and then delete the schema at the end of the workflow as a part of another command?

Thanks

Dhrumin

[dhrumins]

I came across another scenario, where I would require variable passing from one command to another.

I modified the Create CM volume command to always choose a unique name for the volume to be created.

So I have a workflow with the following commands

1. Create CM volume - copy with unique volume name

2. Create SM relationship between source and destination volumes

3. Refresh the DFM monitors

4. Find the relationship ID on the DFM

So in the 1st command, I am creating the volume name for the destination volume to be created, in the command itself, by making sure that no other volume exists in the vserver on the same cluster.

Now I need this volumeName of the destination volume, to be used in command 2 and 4, for creating the SM relationship and for finding the relationship ID on the DFM server.

I am not sure how to achieve this functionality in WFA 2.0.

Any thoughts?

Thanks

Dhrumin

[bestinj]

Hi,

     Can we do the unique-volume-name creation logic in the workflow itself, not in the command?

This way, we can store this value in a workflow variable.

--

Thanks and Regards,

Bestin Jose.

[hill]

Hi Bestin,

Yes, definitely.  There are several ways to set volume names in a workflow.  When defining the volume here are some possibilities:

• Constants -  name: "volume_x"
• User Inputs - name: $volName  (where the name the Operator uses as user-input will be the volume name)
• Calculated - name: nextName(find_Volume.name)  - Where a volume name found by the workflow in the environment is passed into a WFA function to produce the next name in sequence

It is also possible to use a combination of these methods.

Hope this helps,

Kevin

[bdave]

Hi Bestin,

To add a little to what Kevin said...

The easiest and richest way I've done this in WFA is to use a <string><number> naming convention like vol01. The FindChart logic is:

First use a Finder like "Find last volume created in an aggregate (by name prefix)". (Use <string> prefix like 'vol')

For the Found branch, do a Define Volume node and in the name parameter, use the function nextNamePadded( foundVol.name ).

For the Not Found branch, do a Define Volume node and in this name parameter, use a constant describing the starting point "<string>01", like "vol01".

Use the same variable name for both Define Volume nodes. Then, use this volume object variable name to pass to the create volume command (and any subsequent commands or defines, etc.)

This covers both when no volumes with that string pattern exists and when you want to increment to the next number in the list of volumes in an aggregate.

Note: A good practice here is under workflow preferences make sure to check the box for "Consider Reserved Elements" so WFA will reserve the new, unique volume name in the WFA cache right away because you wouldnt want another workflow execution trying to create a volume with the same name. BTW, this is a good reason to create unique volume names with WFA framework instead of inside a command.

Hope this helps,

Dave

[dhrumins]

Dave

Do you have a sample Finder like "Find last volume created in an aggregate (by name prefix)". (Use <string> prefix like 'vol')"?

If yes, do you mind exporting it, so that I can use it in my workflow?

Thanks

Dhrumin

[bdave · Accepted solution]

Hi Dhrumin,

The good news here is that the Finder, "Find last volume created in an aggregate (by name prefix)" is Certified content and already included!    (At least it is in WFA 1.1.1, the version I checked.)

Let me know if you want screenshots showing how to add it to your workflow and what it looks like when done.

Cheers,

Dave

[dhrumins]

Thanks Dave, I was actually looking for something for C-mode, but that's ok, I will take a look at the existing 7-mode finder and construct my finder.

Thanks a lot Dave, this was really useful.

[hiyer]

Instead of using the database, a simpler alternative may be to use environment variables. You can set it in the first command like so:

[Environment]::SetEnvironmentVariable("foovar", "foovalue", "User")

Or

[Environment]::SetEnvironmentVariable("foovar", "foovalue", "Machine")

Note that you will not be able to use process-level environment variables since every command spawns a new instance of powershell.

In the second command, you can retrieve it using:

[Environment]::GetEnvironmentVariable("foovar","User")

To avoid contamination of future runs, you may also want to clean up the variable in the second command using:

[Environment]::SetEnvironmentVariable("foovar", $null, "User")

[yaronh]

While this method may work (As some other methods mentioned in this thread), we see this one as a little risky,
and may be potentially harmful.

At the moment we don't have a "formal" mechanism for passing parameters and info between commands nor we "formally" endorse any of the methods mentioned.

There are thoughts on the matter and we will surely update as soon as we will have something concrete.

Best,

Yaron Haimsohn

WFA team

[kleemola]

Wasn't passing values from one command to another supposed to be a feature of WFA 2.2 or 3.0?  It would really help me out right now...

Geoff

[bdave]

Hi hiyer,

Your idea is creative. I like the out-of-box thinking. A few things to consider.

If you set permanent environment variables (or registry entries 😉 ) on the WFA server, you run the risk of another workflow overwriting it. Also, there could be issues with cleanup later, especially if workflows don't complete successfully.  Remember that WFA doesn't have automatic rollback or cleanup.

Cheers,

Dave

[ninja]

Is there a feature request open to have parameters be available for other commands? The other solutions provided are a pain specially when you need to do many workflows. Without this feature you end up creating one huge command to do your stuff and removes a big piece of WFA's purpose. Call them passthrough or global parameters...just and idea.

[kleemola]

PowerShell Example :

Add-WfaWorkflowParameter -Name volumeId -Value 12345

$volumeId = Get-WfaWorkflowParameter -Name volumeId

Perl:

addWfaWorkflowParameter

getWfaWorkflowParameter

[ninja]

That's it. Thanks.