HCL Workload Automation, Version 9.4

Using JSDL job definition templates

Use job definition templates to be able to run multiple jobs based on a single JSDL document, or to turn a traditional job into a dynamic job without the need to create a specific JSDL definition for it.

You have two options for writing the JSDL job definitions for the workload you want to submit with HCL Workload Automation:

Writing a separate definition for each job
Writing a generalized definition that you can use as a template to run more jobs

Writing and using templates is an option that lets you reuse the same JSDL document on multiple jobs when they use the same resources and candidate hosts and share similar scheduling and optimization preferences. This requires that you also define an extended agent workstation for each template you implement, so that at runtime the JSDL template can be properly identified by selecting the extended agent on which the job you want to run is defined. In this way, you can make up classes of jobs where all the jobs that belong to the same class are defined to run on the same extended agent and therefore select, by means of the workload broker workstation, the same JSDL document to submit to the broker.

Traditional HCL Workload Automation jobs can be routed to HCL Workload Automation by simply changing their CPU to an appropriate extended agent, without changing the job definition and without requiring a different JSDL definition for each job. This is the recommended way for changing static workload into dynamic workload in HCL Workload Automation.

Writing a JSDL job definition template

Specific, prepackaged JSDL templates that you can fill in do not exist. Rather, you work a number of steps so that you can write in the Job Brokering Definition Console a JSDL file that can be referenced by more HCL Workload Automation job definitions.

To write a template you use the following:

The composer command line or the Dynamic Workload Console to define extended agents (with their access method) and to create or modify job definitions in HCL Workload Automation.
The Job Brokering Definition Console to write the JSDL file that you then use as a template.

The steps are:

In the Job Brokering Definition Console, you create a JSDL document, give it a name, and save it in the Job Repository of HCL Workload Automation. Like for regular job definitions, fill in the data throughout the pages of the Job Brokering Definition Console, specifying the required resources, and optimization and scheduling details. Unlike you do in regular job definitions, in the Application page, after setting the Type to Executable (or to Extended Job), specify the following variable name in the Script (or Task string) field:
```
${tws.job.taskstring}
```
With composer or the Dynamic Workload Console define a workstation of type extended agent hosted by the workload broker workstation.
If you need background information about extended agents, see the HCL Workload Automation: User's Guide and Reference, SC32-1274. For the purpose of creating the template, however, you only need to know the following facts about an extended agent:
- It is a logical definition that must be hosted by a physical workstation. In this case the physical workstation must always be the workload broker workstation. This workstation can host as many extended agents as you need.
- It requires an access method. An access method can be a complex program, but in this case it is only a statement that references the name of the JSDL file that will be your template. The access method statement is included in the definition of the extended agent and must have the following syntax:
```
ACCESS "/jsdl/filename_of_the_ JSDL_template -var name=value,name=value,..."
```
  where -var name=value is optional and represents one or more variables passed by the workload broker workstation to HCL Workload Automation at job submission time.
Add the extended agent to the plan as you do with any other workstation. The workload broker workstation has the task of managing the lifecycle of the extended agent, notifying the master domain manager that it is up and running.

When jobs are run on the extended agent, they are routed to the workload broker workstation, which handles them differently from other jobs. Instead of searching for the name of the JSDL definition in the task string of the job, the workload broker workstation:

Gets the name of the target JSDL from the access method, and passes the task string as a value for variable ${tws.job.taskstring}.
The task string value is replaced in the script element of the target JSDL, and is used as a command string to run on the target agent that is dynamically selected by the HCL Workload Automation.
Thus, the JSDL definition invoked by the workload broker workstation works as a sort of template that you can use to run different task strings defined in different HCL Workload Automation jobs: the same JSDL document is reused for multiple jobs.

Example

You want to exploit HCL Workload Automation to run a job named SUBMIT_JOBXA and you want to use a JSDL template. The following definitions accomplish this:

The definition of the workload broker workstation. It is named DGCENTER_DWB and it is of type BROKER. There can be only one workload broker workstation running at a time in a HCL Workload Automation network (this applies also to the HCL Workload Automation server).
```
CPUNAME DGCENTER_DWB
  OS OTHER
  NODE DGCENTER TCPADDR 41111
  ENGINEADDR 31111
  DOMAIN MASTERDM
  FOR MAESTRO
    TYPE BROKER
    AUTOLINK ON
    BEHINDFIREWALL OFF
    FULLSTATUS OFF
END
```
The definition of extended agent DGCENTER_DWBXA. The extended agent must:
- Be hosted by the workload broker workstation (DGCENTER_DWB in this example).
- Include the access method. While normally the ACCESS keyword is followed by the name of the program that implements the specific access method, in the case of JSDL templates it needs only to define the name of the JSDL document you use as template - that must be stored in the HCL Workload Automation Job Repository in the HCL Workload Automation database and available in a local folder in the workstation where you run the Job Brokering Definition Console- and whatever other parameters you want to use. These items must be enclosed between double quotes.
  This requires that you created the JSDL document you will be using as a template (named SJT in this example), defining the required resources, candidate hosts, and scheduling and optimization preferences, and specifying ${tws.job.taskstring} in the Script field of the executable.
```
CPUNAME DGCENTER_DWBXA
  OS OTHER
  NODE DGCENTER TCPADDR 41111
  FOR MAESTRO HOST DGCENTER_DWB ACCESS "/jsdl/SJT -var 
target=D:\vmware,RES=RES1"
    TYPE X-AGENT
    AUTOLINK OFF
    BEHINDFIREWALL OFF
    FULLSTATUS OFF
END
```
The definition of job SUBMIT_JOBXA in HCL Workload Automation:
```
DGCENTER_DWBXA#SUBMIT_JOBXA
 SCRIPTNAME "C:\TWS\Utils\Jobs\javacount_on.bat"
 STREAMLOGON Administrator
 DESCRIPTION "Added by composer."
 TASKTYPE WINDOWS
 RECOVERY STOP
```
The fact that the job is defined to run on extended agent DGCENTER_DWBXA, hosted by the workload broker workstation and matched with the SJT JSDL definition, drives the process that:
1. Submits the job via HCL Workload Automation
2. Uses the specifications of the SJT JSDL definition
3. Replaces variable ${tws.job.taskstring} in SJT with the task string of SUBMIT_JOBXA, that is:
```
C:\TWS\Utils\Jobs\javacount_on.bat
```