Original article is posted here.
Whether this is a great, or extensible, or lazy, or short-sighted solution is likely quite debatable. However, I use this method for nearly every variable value evaluation, and have never had a terrible issue with it.
Let’s set up a situation — say you’re doing a search for a set of values in a SQL table. The results need to be mapped to another variable, but if there are no results (null), the mapping component fails. We need to verify that a value exists prior to leading the data to the mapping component.
What about the "Variables Exist" rule?
The "Variable Exists" and Variables Exist" rules only check for the variable itself, not whether the variable has value. What this means is that any variable that has been declared (always a good idea to declare your variables, in an "Initialize Data" component, for example) will pass a "Variables Exist" rule.
As far as validating value, I’ve seen many, many different ways of doing this. Here are several examples.
Determining whether a value has a length greater than zero by using a Text Compare Rule.
Using a Compare Numbers Rule to determine whether a value (usually the “count” part of an array) is greater than zero.
Checking whether a value (usually the “count” part of an array) equals zero or not, using an Equals Rule.
I’m personally very guilty of having overused the Equals Rule in my early days.
Then one day, someone showed me the Text Exists component, and that’s almost all I’ve used ever since. Need to check a SQL return? No problem. Test a Guid part of a complex data type in an SMP component result? Also no problem.
Not to say that there won’t be situations in which this will be problematic, of course. I’m just saying I haven’t come across any.
I use Text Exists for nearly every Visibility model for form elements. I use it prior to doing any data copies with the Copy Data Element to New Location component. I use it every time I need to check to see if a database entry exists for a proposed insert or edit to prevent duplicates. Here’s an example of that last one:
First, take the proposed new row values and run it through a “get this value from the database” fetching component. Then, using a Text Exists component, we can determine if, by commiting the proposed transaction, we will be producing a duplicate row. We only allow the edit if the item does not already exist, which is assured by the Text Exists component.
When validating a complex data type, make sure you validate a part that is “null not allowed” (like a primary key, name, or a Guid) to discourage false negatives.
That’s it! I hope it helps make your Workflow development a little easier.
Featured Components
Text Exists
Text Compare Rule
Equals Rule
Compare Numbers Rule
Copy Data Element To New Location