when it is no longer needed.
Beware of carrying excess data from node to node.PresenceBPM - Task Design
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 
.