2012-08-02 04:54 PM
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.
Solved! SEE THE SOLUTION
2012-08-03 12:40 AM
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).
2012-08-03 10:53 AM
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?
2012-08-06 02:54 PM
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?
2012-08-08 10:58 AM
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.
2012-08-13 03:38 AM
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,
2012-08-13 05:34 AM
Yes, definitely. There are several ways to set volume names in a workflow. When defining the volume here are some possibilities:
It is also possible to use a combination of these methods.
Hope this helps,
2012-08-14 01:38 AM
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")
[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:
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")
2012-08-15 10:29 AM
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.
2012-08-16 11:10 AM
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.