Using Actions

Actions and triggers allow you to interact with user actions, the most common one being the final status of jobs. With Process Definition actions, for example, you can change the status to Completed even if the process reached status Error.

Note: The main difference between triggers and actions is the scope. Actions apply only to the Process and Chain Definitions for which they are defined. Triggers apply globally.

Actions are also available in the Active Monitoring Module and the Promotion Module.

Warning: Never persist a session in an action. This is done for you at a later point.

Action Workers

Actions are executed by action workers. The action worker thread count is set to 100 by default. If you have a large number of concurrent processes and/or Chains that require actions to be executed, you may need to increase the number of action workers. The number of action workers can be set in the action registry entry. Redwood recommends that you consult Redwood Support Services or a expert consultant prior to changing this value.

RedwoodScript

The code you write must be valid RedwoodScript. Note that only a subset of Java classes are available for use in actions.

Tip: By default, RedwoodScript is based on Java 11. However, you can set the /configuration/javatoolkit/SourceVersion and /configuration/javatoolkit/TargetVersionregistry entries to your desired version and then use all the features of that version.

You can import your own classes for use in an action from a library. Redwood recommends storing as much of your code as possible in a library, especially if you plan on reusing it in other triggers or actions.

Action Execution

Actions fire at specific times during the life-cycle of a process. Actions fire immediately after triggers that carry the same name; for example, trigger Before Process Definition On Change fires immediately before a On Change action on a Process Definition, if specified. If a file search is configured on the Process Definition, that always fires first, followed by Before Process Post Running triggers, if specified, followed by any Post Running actions.

Note that no actions fire for status Canceled.

On Change

The On Change action fires for the following status changes:

  • New -> Scheduled
  • New -> Held
  • Held -> Scheduled
  • Scheduled -> Held
  • Scheduled -> EventWait
  • EventWait -> Scheduled
  • Scheduled -> Queued

Pre Running

The Pre Running action fires immediately before a process is set to status Running. This is the last point at which you can prevent a process from reaching status Running.

Post Running

The Post Running action fires immediately before a process is set to a final status, except for status Canceled. The final statuses this action fires before are Completed, Error, Killed, and Unknown.

OnUserMessageOperation

This action is only available on user messages and fires when a user interacts with a user message:

  • when a user message is created, forwarded, delegated, and replied to
  • an attachment is added (before being uploaded) and uploaded

Before Process User Change

This action fires when a user attempts to save a modified process or Chain, or when the job is created in a user session, including when a job is resubmitted or in a recurrence. For example, a user attempts to change the Queue of a process using the Submit Wizard. This action fires immediately after the user has chosen Submit, before the process has been persisted to the database. It allows you to veto certain specific modifications to processes or chains.

Import/Export Module

Actions are available in Import Rule Sets to customize objects before they are written to the database. You can rename objects or assign them to an application, for example.

Import Rule Sets

The context of actions in Import Rule Sets have a SchedulerSession object which allows you to rename the objects, for example, and the jcsImportRuleSet which is an iterator over the collection of objects that are to be imported. See the example below.

Object Class Example Code
jcsSession com.redwood.scheduler.api.model.SchedulerSession jcsSession.getQueueByName("PRD_QUEUE");
jcsImportRuleSet com.redwood.scheduler.api.scripting.variables.ImportActionScriptObject jcsImportRuleSet.getObjects();

Definition Actions

Actions are available in process and Chain Definitions to customize behavior before, while and after they have finished running. The following action-types are available:

Active Monitoring Module

Actions are available in the Active Monitoring Module in the following alerting objects:

  • Alert Escalation: After the alert is escalated
  • Alert Source: After the alert is created
  • Email Alert Gateway: Before the email is sent

Actions in RedwoodScript

The contexts of actions available in alerting objects have the Logger (jcsOutLog) as well as a object-specific context which is used to retrieve the alert, the alertSource or the message, for example.

Object Class Example Code
jcsOutLog com.redwood.scheduler.infrastructure.logging.api.Logger jcsOutLog.info("This is an informational message");
jcsAlertSourcePostAlertContext com.redwood.scheduler.api.scripting.variables.AlertSourcePostAlertActionScriptObject jcsAlertSourcePostAlertContext.getAlertSource();
jcsEmailAlertGatewayPreSendActionContext com.redwood.scheduler.api.scripting.variables.EmailAlertGatewayPreSendActionScriptObject jcsEmailAlertGatewayPreSendActionContext.getMessage();
jcsAlertEscalationPostAlertContext com.redwood.scheduler.api.scripting.variables.AlertEscalationPostAlertActionScriptObject jcsAlertEscalationPostAlertContext.isResend()

Example

Sample code that is to be used in Post Import import action of Import Rule Sets and changes the application of all imported objects, except applications, to Finance, which has Example as parent application.

Checks are made for the imported object, making sure it can have an application (ApplicationObject) and that the imported object is not an application (to avoid errors, if the application or its parent are part of the import).

Copy
{
  Application parentApplication = jcsSession.getApplicationByName("Example");
  Application application = jcsSession.getApplicationByName(parentApplication, "Finance");
  for (Object o : jcsImportRuleSet.getObjects())
  {
    if (o instanceof ApplicationObject && !( o instanceof Application))
    {
      ((ApplicationObject) o).setParentApplication(application);
    }
  }
}

See Also