Customizing Processes with Specific Actions

Actions allow you to interact with objects while these are doing something, the most common one being setting the final process status. With Actions you can change the status to Completed even if the process reached status Error. You may define a set of conditions that must be met for this change to take place. If you want to interact with processes from many processes, it might be easier to use a trigger. See the Using Triggers and Using Actions sections of the documentation.

note

Actions require RedwoodScript which in turn requires an Module.Scripting license key.

There are three different types of actions that fire at three different times in the life-cycle of a process. The following three actions are available:

• On Change - When the status of a process changes but has not reached Queued (but does not fire when the status changes to Chained )
• Pre Running - Before a process has started running
• Post Running - After a process has completed

Post Running is the only action that allows changing the final status of a process, it is therefore the most used action. The other actions allow you to change the queue, start time or even hold the process if a set of defined conditions are met.

You need to understand the concepts of process states to get a clear understanding of when triggers and actions fire, see the Process States section for more information on the subject.

All actions have a log file, which will be attached to the process if it is not empty. When an error occurs in an action, the process will go to status Error, this can be changed in status handlers.

Since actions are dependent on the process state, you must be familiar with the various process states, see the Process States section for more information.

note

You are not allowed to persist in any of these actions, that is done for you at the end.

The following three Actions are available:

On change

• Any change before Queued and Dispatched
  • Does not fire on Chained status
• Can change scheduled start time, queue, or hold the process.

Pre running

• During Queued, Dispatched, EventWait and LockWait
• Can change scheduled start time, queue, or hold the process.

Post running

• Any transition from Running into a final state:
  • Error, Completed, Killed, Unknown, Canceled
• Can change the final state.

All actions have access to the process changing status, the old and new statuses as well as a jcsSession. The changes that are allowed in the actions are action dependent. You cannot change the scheduled start time in a post-running action, for example, because the process has finished running.

The source of the actions is written in RedwoodScript which allows interacting with the repository. The above uses are only the most common - it is perfectly possible to submit another process in any of the actions or even cancel the process in question if it has not reached status Running.

Contexts

The following predefined objects are available in process actions. These are defined in the Source Stub. You can reload the source tab from the context-menu to display them.

Before Process On Change

Object	Class	Example Code
jcsOutLog	com.redwood.scheduler.infrastructure.logging.api.Logger	jcsOutLog.warning("This is a warning!");
jcsOnChangeContext	com.redwood.scheduler.api.scripting.variables.PreExecutingActionScriptObject	jcsOnChangeContext.setFailJobOnError(false);
jcsSession	com.redwood.scheduler.api.model.SchedulerSession	jcsSession.getUserName()
jcsJob	com.redwood.scheduler.api.model.Job	jcsJob.hold();
jcsOut	java.io.PrintWriter	jcsOut.println("This text will be printed to a specific output file on the process.");

Before Process Pre Running

Object	Class	Example Code
jcsOutLog	com.redwood.scheduler.infrastructure.logging.api.Logger	jcsOutLog.info("This is an informational message!")
jcsSession	com.redwood.scheduler.api.model.SchedulerSession	jcsSession.getQueueByName("UNIX_Generic");
jcsJob	com.redwood.scheduler.api.model.Job	jcsJob.hold();
jcsPreRunningContext	com.redwood.scheduler.api.scripting.variables.PreExecutingActionScriptObject
jcsOut	java.io.PrintWriter	jcsOut.println("This text will be printed to a specific output file on the process.");

Before Process Post Running

Object	Class	Example Code
jcsOutLog	com.redwood.scheduler.infrastructure.logging.api.Logger	jcsOutLog.debug("This is a debug message!")
jcsPostRunningContext	com.redwood.scheduler.api.scripting.variables.PostRunningActionScriptObject
jcsSession	com.redwood.scheduler.api.model.SchedulerSession
jcsJob	com.redwood.scheduler.api.model.Job	jcsJob.restart();
jcsOut	java.io.PrintWriter	jcsOut.println("This text will be printed to a specific output file on the process.");

Values

Tab	Field	Description	Default Value
Actions	Type	The type of action to create.
Actions	Enabled	Enable/disable action
Actions	Action Subject
Actions	Source	Source code of the actions in RedwoodScript

Logging Verbosity

You can set verbosity levels in the submit wizard for the stdout.log and stderr.log files.

Example

A multi-step chain definition has a process in a step that may fail, but the rest of the chain must finish to clean up. The status of the chain should be Completed if all steps reach Completed and Error when a specific step went into error. The status handler on the step for status Error is Continue. The following action is used to check if the step reached status Error, and if so, throws a RuntimeException to force the chain into status Error.

{
  //Check if the first step failed, if it did,
  //throw an exception to put the Jobchain process into Error

  String stepName = "Run SystemBackup";
  String statusName = "Error";

  // Get an iterator over the child processes of the chain process
  for (Job job : jcsJob.getChildJobs())
  {
    String sName = (String) job.getDescription();
    String sStatus = (String) job.getStatus().name();

    if (stepName.equals(sName) && statusName.equals(sStatus))
    {
      throw new RuntimeException();
    }
  }
}

See Also

• Redwood Script
• Trigger Examples
• Triggers