Using embedded triggers

This section provides a exercise showing the use of embedded triggers. These are trigger expressions embedded within the task scrips using the --wait command. Whilst the expression is not true, the job will hold i.e. continue to wait.

Whenever possible, giving preference to triggers on the suite definition is considered a better approach, as this allows extra validation upon creation, whereas embedded triggers are checked at run time.

Update Task Script

Consider the task t2.ecf script as follows:

Listing 27 $HOME/course/test/f1/t2.ecf
%include <head.h>
ecflow_client --wait="t1 == complete" # wait for expression to become true
%include <tail.h>

Update Suite Definition

Consider the following suite definition, with no trigger on task t2.

# Definition of the suite test.
suite test
    edit ECF_INCLUDE "{{HOME}}/course" # replace '{{HOME}}' appropriately
    edit ECF_HOME    "{{HOME}}/course"
    family f1
        edit SLEEP 20
        task t1
        task t2
    endfamily
endsuite

What to do

  1. Modify the task script and the suite definition as shown above.

  2. Replace the suite, using:

    ecflow_client --suspend /test
    ecflow_client --replace /test test.def
    
  3. Observe the tasks in ecflow_ui.

  4. Notice the wait icon on task t2.

  5. Introduce an error in the wait expression and requeue the suite. Observe how the job now aborts:

    Listing 29 Introduce error in wait expression
    ecflow_client --wait="t == complete"  # Error: no node with name `t`
    
  6. Introduce an impossible expression in the wait expression and requeue the suite. What is the effect?

    Listing 30 expression that will never be satisfied
    ecflow_client --wait="1 == 0"