J2EE jobs

A J2EE job allows Java applications in the same network to send and receive messages from and to a JMS destination.

A description of the job properties and valid values are detailed in the context-sensitive help in the Dynamic Workload Console by clicking the question mark (?) icon in the top-right corner of the properties pane.
This section describes the required and optional attributes for J2EE jobs. Each job definition has the following format and arguments:
Table 1. Required and optional attributes for the definition of a J2EE job.
Attribute Description/value Required
application name j2ee ✓
jms operation The operation to be performed. Supported values are:
  • send. This is the default value.
  • receive. If you specify receive, you can optionally define a value for the timeout attribute.
timeout The timeout, expressed in seconds, within which the task must complete. If you do not specify a timeout or set it to 0, the task continues indefinitely.
connectionURL The URL of the WebSphere Application Server.
connFactory An administered object that a client uses to create a connection to the JMS provider. To specify the connection factory, you can use a variable expression that can contain one or more variable references, such as ${var}, any character, and any string. ✓
destination An administered object that encapsulates the identity of a message destination, which is where messages are delivered and consumed. To specify the destination, you can use a variable expression that can contain one or more variable references, such as ${var}, any character, and any string. ✓
message The message to be sent. ✓
Note: This attribute is required only for the send task.
Credentials Specify the user name and the password to be used when running the J2EE application. Use this field if global security is enabled on WebSphere Application Server. The user must be defined on WebSphere Application Server. To specify these credentials, you can use variable expressions that can contain one or more variable references such as ${var}, optionally in association with any character or with a simple string. In addition, you can parametrize in one of the following ways:
  • Enter a username specified in the database with the username user definition (it is applicable to all operating systems on this job type) and key the statement:
    <jsdl:password>${password:username}</jsdl:password>
    The password is retrieved from the username user definition in the database and resolved at runtime. See Using user definitions on job types with advanced options for further details.
    You can also specify the user of a different workstation and use the following syntax for the password:
    <jsdl:password>${password:workstation#username}</jsdl:password>
  • Enter a user and password defined with the param utility command locally on the dynamic agent that will run the job (if the job is to be submitted to a pool or to a dynamic pool, the definition must be present on all the agents of the pool). Provided you defined the user name with the variable user and a password, the corresponding credential statements would be:
    <jsdl:userName>${agent:user}</jsdl:userName>
  <jsdl:password>${agent:password.user}</jsdl:password>
    The user and password variables are resolved on the agent at runtime. See Defining variables and passwords for local resolution on dynamic agents for further details.
The following example shows a send task that sends a message to the queue MyQueue:
$JOBS
AGENT#JOB_NAME_JMS_SEND
TASK
<?xml version="1.0" encoding="UTF-8"?>
<jsdl:jobDefinition xmlns:jsdl="http://www.ibm.com/xmlns/prod/scheduling/1.0/jsdl"
 xmlns:jsdlj="http://www.ibm.com/xmlns/prod/scheduling/1.0/jsdlj" name="JMS_JOB_SEND">
 <jsdl:application name="j2ee">
 <jsdlj:j2ee>
 <jsdlj:jms operation="send">
 <jsdlj:connectionURL>corbaloc:iiop:washost.mydomain.com:2809</jsdlj:connectionURL>
 <jsdlj:connFactory>jms/MyCF</jsdlj:connFactory>
 <jsdlj:destination>jms/MyQueue</jsdlj:destination>
 <jsdlj:message>Submission of jms job: SEND MESSAGE</jsdlj:message>
 </jsdlj:jms>
 <jsdlj:credentials>
 <jsdlj:userName>jtwoeeuser</jsdlj:userName>
 <jsdlj:password>${password:jtwoeeuser}</jsdlj:password>1
 </jsdlj:credentials>
 </jsdlj:j2ee>
 </jsdl:application>
 </jsdl:jobDefinition>
Note: (1) User jtwoeeuser was defined on the HCL Workload Automation database using the username user definition command. The associated password, specified by the ${password:jtwoeeuser} string in the task, will be retrieved from the database at runtime.
The following example shows a task that reads messages from the queue MyQueue:
$JOBS
AGENT#JOB_NAME_JMS_RECEIVE
TASK
<?xml version="1.0" encoding="UTF-8"?>
<jsdl:jobDefinition xmlns:jsdl="http://www.ibm.com/xmlns/prod/scheduling/1.0/jsdl"
 xmlns:jsdlj="http://www.ibm.com/xmlns/prod/scheduling/1.0/jsdlj" name="JMS_JOB_RECEIVE">
 <jsdl:application name="j2ee">
 <jsdlj:j2ee>
 <jsdlj:jms operation="receive" timeout="180">
 <jsdlj:connFactory>jms/MyCF</jsdlj:connFactory>
 <jsdlj:destination>jms/MyQueue</jsdlj:destination>
 </jsdlj:jms>
 <jsdlj:credentials>
 <jsdlj:userName>userName</jsdlj:userName>
 <jsdlj:password>password</jsdlj:password>
 </jsdlj:credentials>
 </jsdlj:j2ee>
 </jsdl:application>
 </jsdl:jobDefinition>

Scheduling and stopping the job in HCL Workload Automation

You schedule HCL Workload Automation J2EE jobs by defining them in job streams. Add the job to a job stream with all the necessary scheduling arguments and submit it.

You can submit jobs using the Dynamic Workload Console, Application Lab, or the conman command line.

After submission, when the job is running and is reported in EXEC status in HCL Workload Automation, you can stop it if necessary, by using the kill command from the Dynamic Workload Console. This action is not effective on the send operation, but it is supported on the receive operation, causing the Java application to stop waiting for messages.

Restarting the job

If the HCL Workload Automation agent stops when you submit the J2EE job or while the job is running, the job restarts automatically as soon as the agent restarts.

See also

From the Dynamic Workload Console you can perform the same task as described in

Creating job definitions.

For more information about how to create and edit scheduling objects, see

Designing your Workload.