The key to this method is the way in which the standard workflow
constraints are manipulated dynamically by the ActiveX script in the SetupPath task.
The first point to note is that a workflow constraint can use either the result
(ExecutionResult Property) or status (ExecutionStatus Property) of the source step to determine
its outcome. This is set via the PrecedenceBasis property of the precedence
constraint (PrecedenceConstraint Object).
If we chose the True path, the constraint between the last step in that path (C) and the
final step (End) is setup just like a normal on success constraint. The precedence basis
is on the result and that result must indicate success, DTSStepExecResult_Success.
For the second constraint, leading from the False path, we need to ensure
satisfaction of the constraint even though
the step will not execute. For this we set the precedence basis to be on the status,
and the status must indicate that the step has not run.
The obvious choice would be to detect for a status of DTSStepExecStat_Inactive,
however the internal DTS workflow engine does not always cascade the status to all
downstream steps. To ensure we do not run into this we will also accept waiting status,
DTSStepExecStat_Waiting. Notice the logical Or between the two accepted values.
If we choose the False path, the reverse is implemented. The main If
statement in SetupPath tests our global variable to decides between the two paths,
and sets these properties accordingly.
The final statement within each block of the If statement is used to
ensure the current status value for the last step in the inactive path is
correct (DTSStepExecStat_Inactive). Without this we may
read the status value from a previous execution of the package.
A fully working sample package is available for download,
which should illustrate this method better than any description.