Organizing scheduling objects into folders

Move a set of scheduling objects in batch mode to specified folders using the scheduling object naming convention to name the folders.

Before you begin

The following scheduling objects can be defined in or moved into folders:
  • jobs
  • job streams
  • workstations
  • workstation classes
  • calendars
  • event rules
  • prompts
  • resources
  • run cycle groups
  • variable tables
  • workload applications
You can organize your existing scheduling objects that use a specific naming convention into folders. Folders might represent a line of business or any other meaningful category to help you identify and monitor your workload. When moving scheduling objects into folders, you can choose to use part of the object's name as the folder name. The folder name might be a prefix or suffix used in the object's name. Removing this string from the object name frees up some characters in the object name allowing you to create more readable or descriptive names.

Wildcards are used to represent tokens in the object names which are then used to indicate the folder names. Folders with these designated names must already exist. Rename the objects and move them to specified folders in batch mode using the composer rename command. The ;preview option is provided so you can first test the command, without actually submitting it, to get a preview of the output and verify the expected result.

Before you go ahead and move scheduling objects into folders, it is recommended that you first verify if there are any existing event rule definitions that reference these objects. If references are found, duplicate the event rule and update the references to the objects using the new name and folder path. Then, proceed to rename and move the object to the desired folder as described in the following procedure. You can remove the original event rule definition that references the old object name only after verifying that no other instances of the object with the old name exist in the plan.

About this task

The high-level steps for organizing your scheduling objects into folders are as follows:

Procedure

  1. Create the folders first. Create the folder hierarchy with the required names in the HCL Workload Automation database. See mkfolder for creating folders from the composer CLI. See Designing Folders to create folders from the Dynamic Workload Console.
  2. Rename and move the scheduling object into the desired folder. Run the composer rename command mapping the object name to folder names using wildcards. Use the ;preview option the first time to ensure you obtain the expected result, and then run the command a second time without the ;preview. There are several approaches to organizing your jobs and job streams into designated folders with meaningful names. The following are some examples of how to use wildcards to map tokens contained in the object definitions to folder names. The examples are divided in two categories: renaming objects without the workstation name in the object identifier and renaming objects with the workstation in the object identifier.
    Renaming objects that do not have the workstation name as part of their object identifier (calendars, event rules, prompts, workstations, workstation classes, variable tables, workload applications, run cycle groups)
    Move a workstation from the root folder to a child folder
    Before:

    AA_BB_WS1
    AA_BB_WS2

    After:

    /AA/BB/WORKSTATION1
    /AA/BB/WORKSTATION2

    composer rename ws @_@_ws@ /@/@/workstation@
    Move a variable table to a child folder using a combination of the "@" and "?" wildcards
    Before:

    AA_BB_EF_GHI
    AB_CD_GH_IJK
    BB_CC_EF_GHI

    composer rename vt ??_??_@ /??/??/@

    After:

    /AA/BB/EF_GHI
    /AB/CD/GH_IJK
    /BB/CC/EF_GHI

    Renaming objects that have the workstation name as part of their object identifier (jobs, job streams, resources)
    Note: If you define a rule to rename objects whose object identifier includes the workstation, for example, a job, job stream, or resource, then remember that the wildcard character can also be used for the workstation, with respect to positional order.
    Move them from the root to a first-level folder named after the prefix in the object name
    Before: WS_NAME#ABC_JSNAME
    composer rename js @#ABC_@ @#/ABC/@

    After: WS_NAME#/ABC/JSNAME

    Move them from the root to a first-level folder named after the suffix in the object name
    Before: WS_NAME#DEFG_JSNAME_ABC
    composer rename js @#@_ABC @#/ABC/@

    After: WS_NAME#/ABC/DEFG_JSNAME

    Move them from the root to a first-level folder where a wildcard character is used to represent the root and is replaced with a blank
    Before: @#/@/@, where @#/@/@ represents WS_NAME#JSNAME and JSNAME is in the root folder
    composer rename js @#/@/@ @#/F_@/J_@

    After: WS_NAME#/F_/J_JSNAME

    Move them from the root into a hierarchy of folders named using both the prefix and the suffix in the object name
    Before: WS_NAME#ABC_DEF_JSNAME_GHI
    composer rename js @#ABC_DEF_@_GHI @#/GHI/ABC/DEF/@

    After: WS_NAME#GHI/ABC/DEF/JSNAME

    Before: WS_NAME#ABC_DEF_JSNAME
    composer rename js @#ABC_DEF_@ @#/ABC/DEF/@
    After: WS_NAME#/ABC/DEF/JSNAME
    Before: WS_NAME#ABCDEF_JSNAME
    composer rename js @#ABCDEF_@ @#/AB/CD/EF/@

    After: WS_NAME#/AB/CD/EF/JSNAME

    Move them from an existing folder to sub-folders
    Before: WS_NAME#ABC/DEFG_JSNAME 
    composer rename js @#ABC/DEFG_@ @#/ABC/DE/FG/@

    After: WS_NAME#/ABC/DE/FG/JSNAME

    Move them from an existing folder to a different folder using the "?" wildcard character
    Before: WS_NAME#MK_1_T/JOB_MY_DEF1_NOW_A
    composer rename jd /MK_?_T/JOB_MY_DEF?_NOW_A /MY_TEST?/TEST_JOB1

    After: WS_NAME#/MY_TEST1/TEST_JOB1

    Move them from the root to a hierarchy of folders using both the "@" and "?" wildcard characters
    Before: WS_NAME#/F1_JSMT01 
    composer rename WS@#F?_JS@ WS@#/F?/JS/@

    After: WS_NAME#/F1/JS/MT01

    Move them from an existing folder to a different folder and rename both the workstation and job name
    Before: WS_NAME#/ROME/JOBNAME 
    composer rename jd @#/ROME/@ WKS_NAME#/PARIS/???_DA

    After: WKS_NAME#/PARIS/A_B_DA

    WKS_NAME#/PARIS/A_C_DA

    Move them from an existing folder to a different folder and rename both the workstation and job name
    Before: WS_NAME#/ROME/DPT 
    composer rename jd @#/ROME/@ S_MDM#/ROME/???_DA@

    After: S_MDM#/ROME/RE_DADPT, where the wildcard group "???" is matched to "RE" because there were no other matches with more than two characters.

    For more information about the composer rename command and syntax, see rename.
  3. Update the security file to assign the appropriate security access. If access was originally granted on a scheduling object based on matching criteria in the object name, then this access must be modified to include the folder. Use a security domain and add the folder name to the scheduling object, and the folder security object to the security file. You must also add the CPUFOLDER attribute to all objects that include the CPU object attribute, for example, jobs, job streams, userobj, resources, and parameters. See Security domain definition if you configure security using the composer command line or Managing security domains if you configure security from the Dynamic Workload Console.
    If you are updating or upgrading your fault-tolerant agents to version 9.5 Fix Pack 2 or later, these updates are especially important if you plan to use the command line on the fault-tolerant agents to perform operations on the objects in folders.

    . The topic refers to updating the security file on the master domain manager and backup master domain manager for the classic security model, but the same updates apply to a fault-tolerant agent. If you updated your 9.5 or 9.5.0.x agents to version 9.5 Fix Pack 2 or later, then see Completing the security configuration for information about how to manually update the security file to include access to folders. The topic refers to updating the security file on the master domain manager and backup master domain manager for the classic security model, but the same updates apply to a fault-tolerant agent.

    If you upgraded your agents from a previous product version, for example, 9.4.x, to 9.5 Fix Pack 2 or later, then see Completing the security configuration for information about how to manually update the security file to include access to folders. This section refers to updating the security file on the master domain manager and backup master domain manager for the classic security model, but the same updates apply to a fault-tolerant agent.

Results

The objects are now defined in the specified folder paths.