Version 4.4 (which is currently undergoing internal beta-testing) will introduce a new action - “Skip actions on condition”. This action will simplify conditional branching in EasyMorph.
At this point conditional branching in EasyMorph is arranged using conditionally derived tables. While versatile, this approach sometimes feels cumbersome, especially in cases when you only need to optionally run 1-3 actions. For instance, send by email a list of bad records only when they are present in data, or add a new column only if it was missing in the original dataset.
The “Skip actions on condition” is a new, simpler way to arrange conditional workflows in EasyMorph. It makes EasyMorph skip all the actions that follow “Skip…” in the current table, when the action’s condition is satisfied. The condition is defined in exactly the same way as in the “Halt on condition” or “Derive table” (in the conditional mode). See the screenshot below:
In the table below, the condition of the “Skip…” action is not fulfilled, and therefore the following actions have been executed. Their pictograms look usual.
The same table, but this time the condition is fulfilled. The actions after the “Skip…” action are skipped.
Notice 2 things:
- The small “fast forward” icon over the skipped actions’ pictograms.
- The icon of the “Skip actions on condition” action looks different when the condition is fulfilled.
The new action will supposedly make EasyMorph workflows less cluttered because fewer tables will be required to arrange conditional branching. It will also make workflows easier to read, because it’s simple and very visual.
5 Likes
+1 very good transformation + intuitive pictograms design
Hi Dmitry,
Can we also use this to skip only 1 action but the others not.
E.g. I want to trigger different easymorph tasks on our EM-server.
Now I have a flow that triggers them using the EM-server command.
Suppose we have 3 tasks: A, B and C.
Now, Suppose that I want to trigger A on a specific date, B on another date and C also on another different date.
How can I achieve that efficiently ?
I would like to state something like of date = X then run A, If date = Y then run only B and if date = Z, then run C.
Can we achieve this without creating derived tables for each task to run ?
This would be nice to orchestrate our ETL tasks in one ETL-flow.
Thanks
Nikolaas
1 Like
Hi Nikolaas,
If you only have 3 tasks and 3 days - then derived tables would be the simplest way of building such conditional flow.
If you have many tasks to run on different dates, another approach may be required:
Notice that in the actions Call and Iterate, the name of the called module/project can be specified using a parameter. Which means that you can create a table, e.g.
DateA, ModuleA
DateB, ModuleB
DateC, ModuleC
Now you can filter the table date using the current date. Then Iterate a helper module with 2 parameters - Date and ModuleName. The helper module, in turn, would Call the module which name is specified by the parameter {ModuleName}.
Hi Dmitry,
I don’t know if I understand exactly your proposal :). I shall think about it.
The problem is that we have several ETL-jobs that have to be coordinated. The tasks should be triggered in the correct order. Some tasks need to run on specific days once a year, other tasks should run monthly and maybe others would run daily in the future.
In the EM-server schulder there’s no way to chain all these tasks in a GANTT-chart like manner. That would be a real added value I think.
Therefore I need to create a master project that orchestrates all tasks. Also when we move from one environment (dev-space, test-space, production-space), I need to be able to run that master project without having to change all underlying tasks to be triggered in the EM-server command manually. As discussed before, there’s no possibility to add a parameter for the task to be triggered in that action. So when I roll out to the test-envorment, I have to manually select all tasks because their task ID is different in that space.
For the moment, the number of tasks is quite limited but it wil grow, so I need to anticipate on that.
An alternative that I see is to create a table with all TASK_ID’s, their required frequencies (or specific run date) and then construct a derived table for each type of frequency (run on a specific date, monthly, daily). Then iterate over these tables executing the run command in the EasyMorph server command line utility.
Kind regards
Nikolaas