How does WFA decide if "Enable" is mandatory?

[jont]

Hi,

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 1.1.1.22.5-7752.

[goodrum]

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.

[jont]

Hi,

I am reusing variables across commands and rows in all of these cases, so that could have something to do with it. I've sent the ASUP to Kevin and we'll see if he or engineering find an issue.

--Jon

[hill]

Hi Jonathan,

This does sound a bit like a bug.  One of the things here that will help is to get an extended ASUP from your system so the engineering team can take a look at things.  To do this:

• log into WFA as an admin
• Click on 'Tools' in the upper left corner
  • click on WFA Configuration
• The first tab will be the ASUP configuration
  • make sure ASUP is enabled by 'checking' Enable ASUP
  • select 'send configuration and cache extended data' from the content drop-down list
  • click on Download
• send the *7z file that is created.  You can either attach that file to this discussion, or you can feel free to email it to me and we can tackle this offline.

screenshot for the above:

         

Hope this helps,

Kevin

[jont]

Hi Kevin,

thanks for getting back to me. I'll contact you directly with more details.

--Jon

[yaronh]

Hi Jon,

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).

Hope that helps - Let us know...

Yaron Haimsohn

WFA Team

[jont]

Hi Yaron,

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.

--Jon