Better understanding of filters

[JCASON]

Just gotten into WFA and have looked at a couple of the training videos.  Overall the tool is very impressive and polished. 

I'm trying to better understand the purpose of filters and finders.  I understand that a filter is essentially a one way query, while a finder is a multi-way query (multiple filters).  But the terminology is throwing me off.

What is strange to me is that it was very difficult to get a drop down list of arrays to work with a command.  If I choose the filter "Get all arrays," I would assume that I would have a drop down list of all arrays to work with.  But I don't.  Instead the behavior seems more like "randomly choose one out of all my arrays."  (And maybe it is just me, but I would think "randomly choose one of my arrays" would have to be one of the most useless things around!)

If I open up the user input, add a variable of type query, and put in the same query from that filter in...then I get my drop down.  Which is good, but very awkward.  Wouldn't it be nicer if when I wanted to choose an array (or aggregate, or volume, or interface, or....) with a drop down list, that I wouldn't have to manually intervene and write or paste in SQL code? 

To me the word filter could imply "I'm giving you a set of things to choose from."  It seems to not be the case here unless I'm using it wrong.  It could also imply "you can only use a specific set of values" which again seems to not be the case.  It seems more like, "narrow down my list of choices and then I will choose randomly from the pile."

Am I missing something?  Am I using the filters wrong?  I really hope I am, or that there is a better way to present simple drop downs that I'm unaware of. 

[hill · Accepted solution]

You seem to have a few questions / statements and I will attempt to answer them as best I can.  Others will likely have similar answers / responses.

1. Purpose of Filters?
   • Filters are (in my opinion) named appropriately.  Regardless of what they are named, they provide the ability to identify a list of "Objects" that come from the WFA DB tables.  They are typically very simple SQL statements that will allow you to choose an object by Name, under a certain size, under a certain utilization or whatever. 
2. Purpose of Finders:
   • The name Finder is, as you point out, a little odd.  That said, try to think of it as a label and leave it at that.  The name will not change.  The purpose of Finders, as you indicate is to link several Filters together.  The rquirement here is that you can ONLY link filters together for the same object type.  This means you can only have multiple Filters for an aggregate or a volume in a Finder... but not both.
   • The purpose of Finders is to give you the ability to select the BEST resource for your proccess... not a random one.  What makes it the best is up to you.  There are several samples of Filters and Finders to act as guidelines / templates, but if you need some other criteria, then that's where you would need to create a new Filter, Finder... or both.
3. Differences between Filters/Finders and User Inputs:
   • Filters/Finders will ultimately find ONE result for your command.  One.  User Input queries will provide you a list of objects to select from.
   • User Inputs do require that you provide SQL statements, very similar to Filters... and as you seem to have done, you can cut/paste some of the SQL from Filters in order to get a User Input drop-down list.
   • With User Inputs, it is possible to have 'staggered' dropdowns, where you can feed the selected value of one user input into another.  The drawback here is that you DO need to know more about SQL.  Is this akward?  Yes.  Are there efforts to make this simpler?  Yes.  Does that help us right now?  No. 
   • Advice - Look at the Reference Manual to help look at other example workflows user inputs.  You can get to the Reference Manual by clicking on Help from the Top menu bar, then select 'Reference Manual'...    The reference manual provides java-docs for ALL WFA content in your WFA system.
4. Getting a Drop-Down list in a command.
   • Uhm.  Not possible.  Unless someone else wants to correct me.
   • The closest thing you could get would be to have a user input for your command, and in your 'Resource Selection' for the applicable attribute (aggregate, volume, etc)
5. Are you missing something or are you using Fiters wrong?
   • I don't know how to answer that one .  I would say, however, you seem to be confusing Filters with User Inputs.  You can get VERY crazy/createive with SQL statements to tweak and hone the drop-down lists to present a selected set of availble information from your WFA DB.  Again, I would point you to the Reference Manual to take a look at some of the other possibilities there.

I hope this helps,

Best,

Kevin.

[JCASON]

Thanks for the thorough information Kevin, it is much appreciated.  I will check out the reference manual later today.

Based on this I think I will need to employ a combination of user input and filter for my desired result, if a command requires a reference variable.  I would enable a filter like "get array by name", and in the name section, put $array_name_var.  Then define a query for $array_name_var to give the user a drop down.  This will return the appropriate array object, based on user selection, to the command.

To hopefully clarify, my confusion with filters isn't at all with your point #1 (identify a list of objects based on certain criteria), it is with your point #3 (that they produce 1 result every time).  I understand now that you've explained it that the "get all arrays" will return one result, but I wouldn't expect something called a filter that said "get all arrays" to return one array.  Does that make sense, from a usability standpoint?  I don't think that the behavior itself is bad, I just think if it were somehow better named or better documented in the WFA tool itself, it could save confusion. 

Also, even though I don't think I will be using filters/finders much, I do think it would be better to display the result before the command runs.  Again, just my opinion, but if I did include a filter for find volume < 50% full, I would still appreciate it telling me "I chose user_data_volume" before the workflow executes, even if it is in a different section of the window for user input.  Right now it seems to select and keep that information in the background, and I can only see what was chosen by looking at the execution details. 

[goodrum]

I think I understand your confusion and I would like to add my two bits.  Kevin did a great job of explaining how Filters and User Input queries work but I would like to expound upon it further. 

Filters: The idea of a filter is to tell the WFA server to give me the top returned value based upon the id column of a SQL query.  The best practice is to create a SQL query that looks for a single object type and would not be an overly complicated query.  For Example: Get All Arrays would be a query that returns a list of Array objects with a LIMIT 1 value.  Why only one value?  I think that this is where some of the confusion lives.  In order to create an object, we need only one value in the Command, right?  So if this is the case, then how would the command understand a list of values.  Now for this reason, we need to only return the top value from a filtered list.  Also, there is the concept of a Reference Variable.  When you look at the Command object, there are some inputs that have a small R beside them.  This indicates that it is a reference variable to a 'found' or 'declared' object.  Think of this variable as the foreign key to a different table.

Finders: Kevin mentioned this and I think that it warrants some further definition.  Finders are made by combining one or more Filters.  Why would I want to have multiple Filters executing at once?  Remember how I mentioned that Filters are going to return the output of a simple query and only the top value based on the ID column?  Well, Finders allow me to do more with my Filters.  Now, I can set my Sort by Column for the Filter and/or I can combine multiple simple Filters to unlock more of the power of WFA.  This is one of the keys to the real power behind WFA - Filters and Finders.  Now with a Finder, I can choose the best array based on License Type (I need to create an NFS export), Data ONTAP version (the feature I want to use is only available in 8.1+) and the NetApp model.  This is an example of combining Filters to make a more complex Finder object. 

User Inputs: Sometimes, it is helpful to control what options a user can enter into the workflow form.  There are four different types of User Input types (defined below) that can be used.  The big difference between Filters/Finders and User Inputs  is pre-execution selection criteria.  Before a user executes, the selection criteria can be limited.  This is good for manipulating specific objects but limiting possible typo issues.  I can have a user select a Vfiler based on a name and then have a second drop down User Input which displays the volumes of that vFiler.  After the volume is selected, a third User Input of String type is available for the Qtree name and so on.  This is a great example of using a cascading User Input.  Now what if I want my Junior storage admin to provision a new volume in an existing vFiler but I want that new volume in the best aggregate on my controller (let's say that I have four of varying capacity).  I don't want the Junior Admin tracking down the controller and pulling out his calculator to determine the best place.  I will make it easier by combining User Inputs and intelligent Filter/Finders.  Now, I have a User Input query which shows the available vFilers in the environment.  He selects the vFiler and enters the new volume name and other required inputs.  This time, the Junior admin hits execute and based on my previously defined criteria, WFA finds the best available aggregate in the controller that owns the vFiler.  Now, I can have my Junior admin provision new storage and he only has to have a very high level of NetApp knowledge.

User Input Types

• String - Text entry and the variable will be declared as a type of 'string'.  Should not be used for numbers as further mathamatical manipulation can be tricky.
• Number - Text entry and the variable will be declared as a type of 'int'.  Should be used for any number and can be limited by the Values section of the User Input management screen
• Enum - a hard coded list of values that will be user selectable via a drop down.  This is list is defined in the Values section of the User Input management screen.
• Query - a SQL statement that is executed in real time against the WFA cache Database.  This can be either simple or very complex SQL statements as is used by the WFA Architect to help control user inputs while providing some dynamic capabilities.  As Kevin stated, these types of User Inputs can be cascaded where a lower User Input is defined based on a previously selected/entered value of an earlier User Input.

I hope that this helps further explain the difference between these two approaches.  If you consider Filters/Finders as used during the planning phase of Preview and Execution and User Inputs as used prior to the planning phase, then it might help as you define/design your workflows.  Filters/Finders help to limit the number of required User Inputs while maintaining a level of control of the selection criteria.  In regards to the last portion of your post,  don't forget to use the Preview button if you want to see what WFA is planning to use based on your Filters/Finders.

Jeremy Goodrum, NetApp

The Pirate

Twitter: @virtpirate

Blog: www.virtpirate.com