Preconditions

Steps and Chain Processes have a single, optional precondition setting that controls whether they are allowed to execute.

A precondition must evaluate either true or false. If a precondition evaluates to true, the Step or Chain Process is allowed to execute. If it evaluates to false, the Step or Chain Process is skipped.

A precondition has several parts, all of which are optional.

• If you only want the Step or Chain Process to execute at specific times, you can use a Time Window. You can specify that the Time Window must be open or closed, and you can specify which time zone it should be evaluated in. If you do not specify a time zone, the current time zone is used.

• If you only want the Step or Chain Process to execute if certain other conditions are met, you can use a REL expression that evaluates to true or false. When creating such an expression, you can use your own custom libraries.

• If you want the precondition to be evaluated more than once, you can specify a number of desired restarts.

In order for a Step or Chain Process to be allowed to execute, both the Time Window portion and the expression portion (if any) must evaluate to true.

Preconditions on a Step are evaluated immediately before the Step is about to execute. Preconditions on Chain Processes are evaluated when their parent Step is about to execute.

Preconditions are executed each time its Chain Process or Step is executed. Consequently, if you have configured a Step or Chain Process to restart, its precondition is evaluated every time it restarts.

Tip: A special Repository.shouldRunAgain() precondition function returns true if a Chain Process has not yet reached status Completed. You can use this to restart Chain Processes, but beware that it can create loops, especially if you use it in combination with automatic restarts.

Note: Preconditions may be executed before a Chain Process is persisted to the RunMyJobs database. This can occur if a Step reaches Console status and is restarted. As a result, it is not possible for a Chain Process with a precondition to access itself or any other Chain Process in the Chain.

Examples

Using a REL Time Window Function

In addition to using the precondition user interface to check a Time Window, you also can do so with REL expression.

In this example, a test is done to see if the Time Window System_Week_WorkDays is open when the precondition executes. The function Time.now() returns the current system date time in the specified time zone. The function Time.isTimeWindowOpen(time, time_window) tests if the Time Window time_window is open at a given time time. (Note that you can specify only the Time Window, in which case the current time zone will be used.) Using the REL expression below, you can specify another time zone or even dynamic time (three hours before now, for example).

Assume that the following is true:

• Time Window System_Week_WorkDays is open on workdays only.
• The time now Time.now('GMT') is 2023/07/27 10:50:44,910 GMT.

If the following expression evaluates to false, the Step or Chain Process is skipped.

=Time.isTimeWindowOpen(Time.now('GMT'), 'System_Week_WorkDays')

Using a Custom Function

In this example, a developer has created two RedwoodScript functions in the built-in Custom library: one that always returns true, and another that always returns false.

// Example code to illustrate
package example;

public class func
{
  public static boolean alwaysTrue()
  {
    return true;
  }
  public static boolean alwaysFalse()
  {
    return false;
  }
}

The developer has added the following two REL entry points, so the code can be called from REL in precondition functions:

The format for a REL precondition function is as follows.

=<library_name>.<method_name>([<arg1>, <arg2> ..., <argN>])

So, to use the alwaysTrue() function, the developer could enter this:

=Custom.alwaysTrue()

And to use the alwaysFalse() function, the developer could enter this:

Custom.alwaysFalse()

Note: Redwood recommends you create your REL Entry Points in a precondition-specific library to avoid unnecessary recompiling. Note that all RedwoodScript scripting contexts (Process Definitions, triggers, etc.) that use a library are recompiled when the library is modified. Note also that your library names must always have a Custom_ prefix.