RED Action Processing Scripts are scripts that perform a set of scheduler actions for a given object in RED. Action Processing Scripts are required for each RED object involved in a scheduled job task except stand-alone scripts. An Action Processing Script is generated by a template (or manually) for a particular object and contains the code required to run each available action on the external scheduler for that object type.

When the Scheduler runs a particular task on an object it passes the task action code as an argument to the Action Processing Script so that the script runs the corresponding action routine in the script.

Action Processing Scripts for a table object would typically contain code to perform:

  • Processing Actions

    • Pre Actions - Index drop, Pre-SQL, Truncate, etc

    • Primary Routine - Load/Update Script and Procedure execution

    • Secondary Routine - Post-Load/Custom Script and Procedure execution

    • Post Actions - After-Load Transformations, Index rebuild

  • Object DDL

    • Create

    • Drop

Work with Action Processing Scripts

Enablement Pack Templates

Action Processing Scripts normally be auto-generated using templates but can also be created by hand. Your WhereScape Target Enablement Pack has suitable templates included for Action Processing. Typically these templates are named with the following naming convention:

wsl_<target_platform>_<pyscript|pscript>_action

  • <target_platform> - the Enablement Pack target platform
  • <pyscript|pscript> - either a python or PowerShell based template

While RED provides the ability to define separate templates for Linux processing vs Windows processing, WhereScape Target Enablement Packs will in most cases only supply a single Action Processing Script template that is suitable for both Windows and Linux/Unix job processing environments.

Object types supported

The below RED object types can have Action Processing Scripts assigned:

  • Table - all except Retro tables
  • View
  • Export
  • Source Mapping
  • Index - only required if you perform tasks directly on indexes
  • Procedure/SQL Block - only required for stand-alone Procedures or SQL Blocks

Settings

Connection - Target Settings

Default Action Processing Script Templates are set in the Target Settings tab of your Data Warehouse Connections (RED Connections with Target Table Location).

Default Unix Action Processing Script Template:

  • When set to a valid template then this template is assigned to new objects created on this target at creation time enabling the auto-generation of the Unix/Linux Action Processing Script to occur.
  • Set this when you have Azkaban Executors on Unix/Linux

Default Unix Action Processing Script Template:

  • When set to a valid template then this template is associated with any new objects at creation time enabling the auto-generation of the Unix/Linux Action Processing Script to occur.
  • Set this when you have Azkaban Executors on Windows

Properties - Action Processing tab

To adjust or set an Action Processing template on an existing object open the Properties of the object and navigate to the Action Processing tab. From this tab you can choose the Windows and Unix processing options from:

  • Generated Script - templated code generation, requires a template to be selected
  • Existing Script - requires an existing script to be selected
  • None - when no Action Script is required

The edit button opens the script in the script editor and closes the properties dialog.

Generating Action Processing Scripts

Auto-generation

In most cases RED will prompt to generate action scripts for newly created objects and for changes to existing objects which may affect the contents of the action script. If both Windows and Unix Action Processing is configured then both scripts will be generated or regenerated from the single prompt.

If you prefer to defer generation of action scripts to a bulk regenerate at a later stage or if you know you need to make further changes to the object which will affect the action script also then select ‘No’ at the prompt.

To avoid the prompt recurring in the same circumstances throughout your RED session then select the ‘Remember for this session’ check box before selecting Yes or No.

Note that there is a setting that affects the prompting behavior under User Preferences.

The setting can be found under: User Preferences->Common->Look and Feel->Confirmation Prompts

Setting: ‘Prompt to Regenerate Action Scripts’ default=checked (on)

When unchecked this will cause Action Scripts to always be regenerated as required without prompting.

Manual Generation

Each object that supports Action Processing Scripts will have an additional item added to its context menu under the Code sub-menu for Windows and Unix Actions Scripts provided there are Action Processing templates set on the object.

Bulk generation

If you would like to generate or regenerate the Windows or Unix Action Processing Scripts on multiple objects at once this can be done by first listing those objects in the middle pane and then multi-selecting the objects you’d like to regenerate. Then the same context menu can be used as in single object regeneration under the Code submenu items.

Application Deployment

For command line driven deployments there is an option that can be set in in deployment options XML to turn on auto-generation of Actions Scripts during deployment:

<Generate_Action_Scripts>YES</Generate_Action_Scripts>

For interactive deployments using RedDeploy.exe this option is set in the UI as shown, using the Generate Action Scripts for objects option:

When this option is set to yes any given object in the deployment application will be assessed for regeneration of its action script.

Regeneration Conditions:

When the setting is 'YES' generate the action script only if the deployment application does not include either a Windows or Unix action script for the object being deployed and when an object is being created or modified by the deployment if either:

  • For modifications - If there is an associated action template set on the object, either within the application itself or in the target repository.
  • For new objects - if a template is not already associated (in the application itself) then use the default action template(s) in the Target Connection of the object.
RedCli object generate-routine

Action Processing Scripts, along with other template generated scripts, can also be generated from the command line. The following would be the typical format of the command:

RedCli.exe object generate-routine --routine-owner-type <[object|source-mapping]> --routine-owner-name <parent_object> --routine-operation <[windows-action|unix-action]> --version-and-modify-existing-routine

For command line help and other options refer to the inbuilt help:

RedCli.exe --help

Available Actions

The supported codeable Actions directly map to the Object Task Actions context menu in the Task Definition page of Jobs in the Scheduler.

When the Scheduler runs a particular task on an object it passes the task action code as an argument to the Action Processing Script so that the script runs the corresponding action routine in the script.

The image below shows the Action Name to Action Code mappings:

Primary and Secondary Routine script execution

  • Primary = Load, Export, and Update routines
  • Secondary = Post-Load and Custom routines

When an action script is executed by the Scheduler with an Action that leads to the execution of another script such as Load, Process, Custom, and Update then the corresponding script as well as the Action Processing Script are written to the work directory for execution. The main action script will be set up with the special environment variables that contain the script run command as defined in the Host Script Language Definition for the script type. When the Primary or Secondary routine is a Procedure object then the actual SQL statements are written to disk and the file made available to the Action Processing Script.

Action Processing Scrip Environment Variables:

When the Routine Type is script based:

  • WSL_SCRIPT_1_COMMAND - The Primary Routine (load, update) run command
  • WSL_SCRIPT_2_COMMAND - The Secondary Routine (post-load, custom) run command

When the Routine Type is a Procedure or Function and only for the Action type ‘Create/Compile’:

  • WSL_SCRIPT_1_COMMAND - The full path to the file containing the Procedural code

When the Routine Type is an SQL Block

  • WSL_SCRIPT_1_COMMAND - The full path to the file containing the Primary SQL Block code
  • WSL_SCRIPT_2_COMMAND - The full path to the file containing the Secondary SQL Block code

Audit and Error Logging

Refer to WhereScape Azkaban Job and Task Logging and the Script Output Protocol sections


  • No labels