Let's take a real-life example where we have an EasyMorph project that parses web server logs. But since the log files can be zipped, we need to unzip them first, if they're not unzipped yet. (For simplicity, the logic related to defining whether a file is already unzipped or not is excluded from this example).
In an imperative language this would be something like
IF logfile.iszipped THEN
logile.unzip()
END IF
In EasyMorph such workflow is arranged using derived tables and filters. With the help of derived tables we create two branches of logic, and filters define what part of data will be processed in each branch. See the screenshot below (click to zoom):
 |
| Conditional workflow (click to zoom) |
In this screenshot we see a table with two columns -- a file name, and a flag that shows if this file is unzipped or not.
Then the calculation logic is split into two derived tables -- in one table we can see a filter (field Unzipped is 'No') and a call to 7z.exe which unzips the file. In the other table we only see a filter (field Unzipped is not 'No') and nothing else -- this branch of logic does nothing.
Depending on whether Unzipped flag equals to Yes or No, the filters make either one or the other table empty (no rows). And if a table is empty, then no data processing happens in it. Therefore only one branch of logic would work, which is the same thing as IF...THEN statements in imperative languages.
Further you can see that both tables are appended into a new table. But since one of the two tables is always empty it basically means that the result is just the table that contains data.
Using exactly the same approach it's possible to organize more complex branching that would be equivalent to SWITCH...CASE statements in some programming languages.