Using Actions
Actions and triggers allow you to interact with user actions, the most common one being the final status of jobs. The main difference between triggers and actions is the scope, actions only apply to the definitions for which they are defined, triggers apply globally. With job definition actions, for example, you can change the status to Completed even if the job reached status Error based on advanced criteria. Actions are also available in the Active Monitoring Module as well as in the import/export module, both require specific license keys that enable the respective module. The Active Monitoring Module requires the Module.Alerting and the import/export module requires the Module.ImportExport license key. Actions can make use of a library in which you can store frequently used classes.
note
You must never persist a session in an action, that is done for you at a later point.
Actions are executed by action workers. The action worker thread count is set to 100, by default. If you have a great number of concurrent processes and/or chains that require actions to be executed, you might have to increase the number of action workers. Redwood highly recommends you consult Redwood Support Services or a expert consultant prior to changing the value. The number of action workers can be set in the action registry entry.
RedwoodScript
The code you write must be valid RedwoodScript; note that only a subset of Java classes are available for use in actions. You import your own class from your library for use in an action. Redwood recommends to store as much of the code as possible in a library, especially if you plan on reusing it in other triggers or actions.
note
You must never persist a session in your action code, that is done for you at a later point.
By default, RedwoodScript is based on Java 11; you set the /configuration/javatoolkit/SourceVersion and /configuration/javatoolkit/TargetVersionregistry entries to your desired version and can use all the features of the version you specify.
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
This action fires for the following status changes:
- New -> Scheduled
- New -> Held
- Held -> Scheduled
- Scheduled -> Held
- Scheduled -> EventWait
- EventWait -> Scheduled
- Scheduled -> Queued
PreRunning
This action fires immediately before the process is set to status Running. This is the last point at which you can prevent a process from reaching status Running.
PostRunning
This action fires immediately before 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).
{
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
OnBeforeJobUserChange OnUserMessageOperation PreRunning PostRunning