Difference between revisions of "Task Design"
Line 3: | Line 3: | ||
Think about what you are doing with the dataset and respect the data. Beware of it's size. Split data into chunks. | Think about what you are doing with the dataset and respect the data. Beware of it's size. Split data into chunks. | ||
− | Clear the Data | + | Clear the Data [[file:cleardata.png]] when it is no longer needed. Beware of carrying excess data from node to node. |
− | Also be aware that built in iteration, such as that found in a data formatter | + | Also be aware that built in iteration, such as that found in a data formatter [[file:dataformatter.png]], is quicker than splitting the data [[file:split.png]]. |
− | When logging | + | When logging [[file:writelog.png]] it makes more sense to write locally (to the sub task) when testing and to the parent when in use. |
When you're happy with the task you may want to turn logging level down to High prioriry messages only. | When you're happy with the task you may want to turn logging level down to High prioriry messages only. | ||
− | + | [[file:writelogstothistask.png]] | |
− | When doing a compare, i.e. using comparison data in a Data Filter | + | When doing a compare, i.e. using comparison data in a Data Filter [[file:datafilter.png]] be sensible with the data that you select. |
− | e.g. If the data is coming from an SQL | + | e.g. If the data is coming from an SQL [[file:sql.png]] then it is better to add some extra condition in the where clause of the select rather than bringing back more and more data. |
Say for instance the task runs every day, then in theory your where clause could say:- | Say for instance the task runs every day, then in theory your where clause could say:- | ||
Line 25: | Line 25: | ||
i.e. replace the above clause with 'Where DATEORDERED > ?' then put the following in the dymanic marker. | i.e. replace the above clause with 'Where DATEORDERED > ?' then put the following in the dymanic marker. | ||
− | + | [[file:dynamicmarker.png]] | |
− | A switch node | + | A switch node [[file:switch.png]] is generally better than a decision node [[file:decision.png]], as it permits multiple decisions, so it's neater and easier to edit. |
Ensure that the paths and decisions are well spaced, and can be easily selected and edited. | Ensure that the paths and decisions are well spaced, and can be easily selected and edited. | ||
− | + | [[file:switchtask.png]] | |
− | A multi append column | + | A multi append column [[file:multi_appendcol.png]] is more flexible than it's single equivalent [[file:appendcol.png]]. |
− | Similarly a multi append variable | + | Similarly a multi append variable [[file:multi_variable_setter.png]] is neater than a series of single ones [[file:setvariable.png]]. |
Latest revision as of 09:48, 20 August 2015
Perhaps the most important thing to consider when designing a task is memory, which in turn relates to performance.
Think about what you are doing with the dataset and respect the data. Beware of it's size. Split data into chunks.
Clear the Data when it is no longer needed. Beware of carrying excess data from node to node.
Also be aware that built in iteration, such as that found in a data formatter , is quicker than splitting the data .
When logging it makes more sense to write locally (to the sub task) when testing and to the parent when in use.
When you're happy with the task you may want to turn logging level down to High prioriry messages only.
When doing a compare, i.e. using comparison data in a Data Filter be sensible with the data that you select.
e.g. If the data is coming from an SQL then it is better to add some extra condition in the where clause of the select rather than bringing back more and more data.
Say for instance the task runs every day, then in theory your where clause could say:-
'Where DATEORDERED > '¤tDate{"yyyy-MM-dd",-7}' ' to only retrieve the last weeks data and therefore take pressure off the comparison engine.
Also it is better to use dynamic markers in SQL, as they are easier to change and the data type can be defined.
i.e. replace the above clause with 'Where DATEORDERED > ?' then put the following in the dymanic marker.
A switch node is generally better than a decision node , as it permits multiple decisions, so it's neater and easier to edit.
Ensure that the paths and decisions are well spaced, and can be easily selected and edited.
A multi append column is more flexible than it's single equivalent .
Similarly a multi append variable is neater than a series of single ones .