I've built several commands for deprovisioning workflows (Remove FCP Alias, Remove Qtree, Remove LUN, Remove Igroup...) by cloning the "add" version for that object and then modifying the command. I am now experiencing a rather odd phenomenon that the workflows using these commands often throw an error such as "Failed to resolve a mandatory parameter: 'Enable' for command: 'Remove igroup' using value '' in row: 1". Now, it is true that this command is empty in row 1 (I use it in row 2 and 3 in this workflow), but normally I don't have to explicitly set Enable=false in a workflow if a command is not used in a line.
The end effect is that I have to set Enable=false on all empty commands, so it's more of a cosmetic issue than functional; however, if it indicates an underlying problem with my commands, I'd like to know about that before I upload them to the communities!
So: has anybody dealt with this problem before and have a solution on hand? WFA version is 18.104.22.168.5-7752.
I have hit this once or twice when I cloned out a workflow for exactly the same reasons that you mentioned. IIRC the problem only went away when I deleted and recreated the row. It is not the prettiest of solutions but it worked. Are you reusing variable names in a different row/command? It might be possible that this is causing the issue. I seem to remember that I had theorized about this at the time but I was under a crunch to build the Cleanup workflow so I didn't spend a lot of time on trying to prove/disprove my theory.
I also found in some of my other 'more complicated' workflows where I am using the first row with a repeat row that builds an array of Storage Controllers and Aggregates, that I ran into this as well because there was nothing actually being done. I had to hard set one of the commands to false to prevent the error.
We have analyzed the ASUP file you sent and came up with the following findings:
Indeed, there was an issue with partial data appearing "allegedly" in the workflow table that we can see in the database.
We aren't exactly sure about the nature of the issue that made them appear there (Apparently, some combination of copy/pasting).
With that said, we attempted and formulated a quick workaround:
1) Point to the row in question, right click and select "Add Row"
2) A new row would appear underneath the current one
3) Copy the cells information from the problematic row to the new row (Manually).
4) Delete the problematic row - It should solve the issue in question
Save the flow and it would be fine from now on.
On top of that, we can confirm that the structure of the workflow in WFA 2.0 is different than previous releases,
and we don't expect that potential issue to "migrate" to WFA 2.0.
And for 2 more notes on find charts:
Regarding the values used for enabler fields - We highly recommend using the values true and false rather than Yes/No.
The value assignment is simpler (No need for quotes around true/false) and the statement is easier and less error prone
(As you are well aware, "=" might be easy to miss):
FoundLun00 seems much clearer than FoundLun00 == "Yes"
Second general note - When using enablers it is important to be consistent. If an enabler is evaluating to "false" - the variables associated with that command might not be evaluated and thus - referring to them later may result in an error.
Here's a doctored example of how that can happen:
If Lun00 wasn't found then FoundLun00 would be "No". Then => remove Igroup may fail while referencing Lun00.
Just my 2 cents here (I will also cross-post this into my blog).
thanks for analyzing the problem. I'll let you know if that fixes the issue. I'll change the phrasing of my questions to the user from "Do you want to mirror..." Yes/No to "Mirror..." true/false; the inclusion of Yes and No was primarily there to make the questions asked in the user mask friendlier in tone.