Task Design

From PresenceWiki
Revision as of 07:10, 18 March 2009 by Graham (Talk | contribs)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

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 http://www.international-presence.com/images/nodes/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 http://www.international-presence.com/images/nodes/dataformatter.png, is quicker than splitting the data http://www.international-presence.com/images/nodes/split.png.

When logging http://www.international-presence.com/images/nodes/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.

http://www.international-presence.com/images/bestuse/writelogstothistask.png

When doing a compare, i.e. using comparison data in a Data Filter http://www.international-presence.com/images/nodes/datafilter.png be sensible with the data that you select.

e.g. If the data is coming from an SQL http://www.international-presence.com/images/nodes/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:-

'Where DATEORDERED > '&currentDate{"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.

http://www.international-presence.com/images/bestuse/dynamicmarker.png

A switch node http://www.international-presence.com/images/nodes/switch.png is generally better than a decision node http://www.international-presence.com/images/nodes/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.

http://www.international-presence.com/images/bestuse/switchtask.png

A multi append column http://www.international-presence.com/images/nodes/multi_appendcol.png is more flexible than it's single equivalent http://www.international-presence.com/images/nodes/appendcol.png.

Similarly a multi append variable http://www.international-presence.com/images/nodes/multi_variable_setter.png is neater than a series of single ones http://www.international-presence.com/images/nodes/setvariable.png.