Status Handlers

Status Handlers let you control what happens when a Step in a Workflow enters an error status. You can set Default Status Handlers at the Workflow level, and then you can override them with Status Handlers set via a Status Decision Point.

The following screen shot shows Status Handlers applied via a Status Decision Point.

There are two types of Status Handlers.

  • Status Handlers at the Workflow level are called default Status Handlers. A Status Handler defined at Workflow level acts as default for the Steps in the Workflow. Default Status Handlers are overruled by any Status Handlers configured at the Step level as part of a Status Decision Point. Note that if you want to use Workflow level Status Handlers, you must disable Request Restart By Default for the Workflow.
  • Status Handlers at the Step level are called Step Status Handlers. If a Status Decision Point after a Step does not define a Status Handler that matches a given status, RunMyJobs looks for a match in the default Status Handlers.

Note: Only one Status Handler at most is triggered for each iteration of a Step.

You can configure Status Handlers to respond to the following states.

  1. A Completed Status Handler executes only if all Job Calls in the Step have reached the status Completed, Skipped, or Ignored.
  2. A Canceled Status Handler executes if the Step contains at least one Job Call with the status Canceled.
  3. An Error Status Handler executes if the Step contains at least one Job Call with the status Error.
  4. A Killed Status Handler executes if the Step contains at least one Job Call with the status Killed.
  5. An Unknown Status Handler executes if the Step contains at least one Job Call with the status Unknown.
  6. If no other Status Handler executes, the Otherwise Status Handler (if any) executes.

Configuring a Status Handler

To configure an individual Status Handler, click in the corresponding field. A menu displays.

Note: Note that some of the options in this menu include both Current and Master options. If you choose the Current version of a menu option, RunMyJobs will restart the Workflow Call or Job Call as it was defined when the process was originally submitted. If you choose the Master version of an option, RunMyJobs will restart the Workflow Call or Job Call as it is currently defined, regardless of how it was defined when it was originally submitted. The Master options give you a chance to correct any problems with a Job or Workflow Definition before you restart it.

The options for configuring a Status Handler are as follows.

  • None: Do nothing.
  • Continue: Continue with the next Step (if any) as if the current Step or the Workflow has reached status Completed.
  • Request Restart: Attempt to restart the Step or Workflow. For more information, see Request Restart.
  • Go to: Go to another Step or to the end of the Workflow. If you choose Go to End of Workflow, the options are:
    • Mark Workflow Error: Puts the Workflow into Error status.
    • Mark Workflow Completed: Puts the Workflow into Completed status.

  • Restart: Attempts to restart the Step or Workflow.

    • Step

      • Restart Step Current: Restart the Step.
      • Restart Step Master: Restart the latest version of the Step.
    • Step Delayed
      • Restart Step Delayed Current: Restart the Step after a delay.
      • Restart Step Delayed Master: Restart the latest version of the Step after a delay.

    • Failed Jobs

      • Restart Failed Jobs Current: Restart the Job Call that reached status Error.
      • Restart Failed Jobs Master: Restart the latest version of the Job Call that reached status Error.

    • Workflow

      • Restart Workflow Current: Restart the Workflow.

      • Restart Workflow Master: Restart the latest version of the Workflow.

  • Ignore Workflow Default: Ignores the Workflow's default Status Handler for this status and uses the system default Status Handler for the status (if any).

Note: You can change the order of Status Handlers can be changed via RedwoodScript. However, any Status Handler that comes after Otherwise will be ignored.

Note: If a Job Call has already reached status Skipped, and previous iterations in the same Workflow never reached Completed, you can use the Otherwise Status Handler to control what happens next.

Note: Restart Behavior is used to control when a Advanced Schedule should be interrupted and its recurrence stopped. By default, final states resume the recurrence of an Advanced Schedule.

Note: Status Handlers do not fire for manual actions on the upper-most Jobs of a Workflow. For example, Status Handlers do not execute when an Operator cancels or kills a Workflow.

Tip: Step-level Status Handlers are not evaluated for disabled or skipped Steps. If you want to use a Condition and Status Handlers (to match Otherwise), set the precondition on all of the Job Definitions in the Step individually, rather than on the Step itself.