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 advanced alerting module as well as in the import/export module, both require specific license keys that enable the respective module. The alerting 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 Note

You must never persist a session in an action, that is done for you at a later point.

End of the note.

Note Note

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

End of the note.

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();

Note Note

You should not persist the session in import rule set actions, this is done for you at a later stage.

End of the note.

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

Alerting

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 Import Rule Sets and changes the application of all imported objects, except applications, to Finance, which has Masalan 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 parentApp = jcsSession.getApplicationByName("Masalan");

Application app = jcsSession.getApplicationByName(parentApp, "Finance");

for (final Iterator it = jcsImportRuleSet.getObjects().iterator(); it.hasNext();)

{

Object o = it.next();

if (o instanceof ApplicationObject && !( o instanceof Application))

{

((ApplicationObject) o).setParentApplication(app);

}