Managing job definitions

The purpose of the following scenario is to show how to create a job definition in the context of an example.

Jobs can either be an embedded job, or they can reference a job definition. For information about how to define an embedded job from the UI, see Creating embedded jobs.

David is an IBM® Workload Scheduler user who needs to upgrade the Java version on the existing backup server named BK_server. To automate the process, David decides to create a job stream that references a job definition. David prefers to reference a job definition instead of creating an embedded job because he needs to use the same job definition in other job streams and he wants to avoid to duplicate the definition. In this way, if David needs to modify any parameter, he can modify just one job definition and every job stream that references that job definition will be affected by the change.

To create a job definition named UPGRADE_JAVA_TEMPLATE and then reference the job definition inside the existing UPGRADE_JAVA job stream, perform the following steps:

  1. Create a job definition named UPGRADE_JAVA_TEMPLATE and enter the command that performs the Java upgrade procedure.
    1. From the Graphical Designer page, select the Assets tab and click the add icon +.
    2. From the drop-down menu, select Job definition.
    3. In the search bar, type Executable, then select the executable job type and click Next.
    4. In General information, in Workstation, select the existing workstation BK_server.
    5. In Folder, select IT_operations.
    6. In Name, type UPGRADE_JAVA_TEMPLATE.
    7. In Task, from the drop-down menu, select Inline script.
    8. In Command text or script name, enter apt install --only-upgrade openjdk-11-jre-headless -y.
    9. Click Add to add the job definition to the database.
  2. Reference the UPGRADE_JAVA_TEMPLATE job definition into the existing UPGRADE_JAVA job stream.
    1. From the Assets, use the search bar to find the UPGRADE_JAVA_TEMPLATE job definition.
    2. Drag the UPGRADE_JAVA_TEMPLATE job definition into the UPGRADE_JAVA job stream.
    3. Click Deploy to deploy the workspace.
    You created a job definition to upgrade the Java version on the backup server named BK_server and you referenced the UPGRADE_JAVA_TEMPLATE job definition into a job stream.

Variable resolution during test connections and job definition

Automatically evaluate and resolve variables when you perform a test connection or start other user-initiated actions from the Dynamic Workload Console.

When you define a job using either the Workload Designer or the Graphical Designer, you can use variables to add flexibility to your job definitions. The value of each variable must be specified in a variable table. IBM Workload Scheduler then evaluates and resolves the variables automatically when you perform a test connection or submit the job.

You can define variables in your job definitions using either of the following standard formatting conventions:

  • ^variable_name^
  • ${variable_name}

To accommodate complex scenarios, you can also use nested variables: you can embed variables within other variables, dynamically building and resolving complex values. For more information about nested variables, see Nested variables for increased flexibility

During a test connection or at submission time, IBM Workload Scheduler retrieves the value for each variable in a set of variable tables. The resolution process follows this order:

  1. Workstation variable table: IBM Workload Scheduler first searches for the variable in the variable table associated with the workstation where the job is defined.
  2. Default variable table: If the variable cannot be resolved at the workstation level, IBM Workload Scheduler searches the default variable table, named MAIN_TABLE.
  3. System environment variables: If the variable is still unresolved after checking the variable tables, IBM Workload Scheduler searches the system environment variables.

For example, if you need to run a high number of jobs that all connect to a remote application, specifying the connection details in each job would be time-consuming and error-prone. If the application password or IP address ever changes, you would be forced to manually update hundreds of individual job definitions.

Instead of specifying connection details into every job, you can use IBM Workload Scheduler features to centralize the configuration, by performing the following steps:

  1. Define a logical workstation of type pool, which groups together specific dynamic agents that have the necessary network access to the remote application. You can name this pool APP_CONNECTION_POOL.
  2. Create a variable table (for example, APP_VARS) and populate it with the application connection variables, such as the IP address and the port number. They then assign this variable table directly to the APP_CONNECTION_POOL workstation.
  3. In the variable table, define all the variables related to the connection properties.
  4. When creating the job definitions, schedule them to run on the APP_CONNECTION_POOL workstation. Inside the job definitions, instead of typing the actual IP, port, and password, they use variable references (like ^IP_ADDRESS^ and ^PORT^) and credential references (like ${agent:password.app_user} or ${password:app_user}).

When the jobs run, IBM Workload Scheduler automatically replaces the variables and credentials at runtime using the variable table and user definitions linked to the pool. If the application password or IP address ever changes, you only need to update the single variable table or user definition, and all hundreds of jobs automatically inherit the new connection details.