Chapter 5: Application Services Jobs

Chapter 5: Application Services Jobs 

Application Services Jobs 

Application Services jobs let you manage entity beans, session beans, and MBeans, 

publish and consume JMS messages, invoke programs over HTTP, and run other types of 

Java-based workload. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

You can define the following Application Services jobs: 

Entity Bean 

Lets you create an entity bean, update the property values of an existing entity 

bean, or remove an entity bean from the database. 

HTTP 

Lets you invoke a program over HTTP or HTTPS in a similar way to a web browser. 

For example, you can use the HTTP job to invoke a CGI script, a Perl script, or a 

servlet. The HTTP job sends a URL over HTTP using the GET method or a form over 

HTTP using the POST method. 

JMS Publish 

Lets you send a message to a queue or publish a message to a topic on a JMS 

server. 

JMS Subscribe 

Lets you consume messages from a queue or topic on a JMS server. 

 Application Services Jobs 

138 User Guide 

JMX-MBean Attribute Get 

Lets you query a JMX server for the value of an MBean attribute. The returned 

value is stored on the computer where the Application Services agent plug-in 

resides. 

JMX-MBean Attribute Set 

Lets you change the value of an MBean attribute on a JMX server. 

JMX-MBean Create Instance 

Lets you create an MBean on a JMX server. 

JMX-MBean Operation 

Lets you invoke an operation on an MBean on a JMX server. 

JMX-MBean Remove Instance 

Lets you remove an MBean from a JMX server. 

JMX-MBean Subscribe 

Lets you monitor an MBean for a single notification or monitor continuously for 

notifications. 

POJO

Lets you instantiate a class to create a Java object and invoke a method on it. The 

job is restricted to classes that take constructors with no arguments (default 

constructors). You can use the POJO job to invoke custom Java code on a local 

computer. 

RMI 

Lets you set up interaction between Java objects on different computers in a 

distributed network. Using an RMI job, you can access a remote server and invoke a 

method on a Java object. 

Session Bean 

Lets you access a session bean on an application server. This job type can make a 

Remote Procedure Call (RPC) to the session bean, invoke a method that defines the 

business logic, pass parameters to the method, and have the results returned as 

serialized Java output. You can access stateless and stateful session beans using the 

Session Bean job. 

Payload Producing and Payload Consuming Jobs 

A payload producing job is a job that produces binary output that is persisted as a 

serialized Java object. 

The following job types are payload producing jobs: 

■ JMS Subscribe 

Note: The appservices.jms.subscribe.persist parameter must be set to true in the 

agent's agentparm.txt file for JMS Subscribe jobs to be payload producing jobs. 

■ JMX-MBean Attribute Get 

■ JMX-MBean Attribute Set 

■ JMX-MBean Operation 

■ POJO 

■ RMI 

■ Session Bean 

■ Web Service 

By default, the serialized Java object is stored on the agent computer in the spool 

directory, using the job name and a numeric suffix as the file name. You can redirect the 

output to a destination file. 

A payload consuming job is a job that uses the output from a payload producing job as a 

parameter's input value. 

The following job types are payload consuming jobs: 

■ Entity Bean 

■ JMS Publish 

■ JMX-MBean Attribute Set 

■ JMX-MBean Create Instance 

■ JMX-MBean Operation 

■ POJO 

■ RMI 

■ Session Bean 

■ Web Service 

We recommend the payload producing job be a predecessor job to the payload 

consuming job although it does not need to be an immediate predecessor. 

 Entity Bean Jobs 

140 User Guide 

The following diagram illustrates a job flow in which a payload consuming job named 

Job C uses the output produced by payload producing jobs named Job A and Job B. In 

this example, Job B is dependent on Job A and Job C is defined to take the output from 

Job A as the value for the input parameter named inputParm1 and the output from Job 

B as the value for the input parameter named inputParm2. 

Entity Bean Jobs 

An entity bean represents a data object, such as a customer, an order, or a product. 

Entity beans may be stored in a relational database, where each instance of the bean 

corresponds to a row in a database table. Each entity bean has a unique identifier 

known as a primary key, which is used to find a specific instance of the bean within the 

database. For example, a customer entity bean may use the customer number as its 

primary key. 

Unlike session beans, which are destroyed after use, entity beans are persistent. You 

can use an entity bean under the following conditions: 

■ The bean represents a business entity, not a procedure. For example, you use an 

entity bean to represent an order and use a session bean to represent the 

procedure to process the order. 

■ The state of the bean must be stored. For example, if the bean instance terminates 

or the application server shuts down, the bean's state will still exist in a database. 

 Entity Bean Jobs 

The following diagram shows the functional relationship between the scheduling 

manager, CA WA Agent for Application Services, and an entity bean residing on an 

application server: 

The Entity Bean job lets you create an entity bean, update the property values of an 

existing entity bean, or remove an entity bean from the database. To find the entity 

bean, the agent uses the bean's Java Naming and Directory Interface (JNDI) name along 

with its finder method. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

To define an Entity Bean job, you require the following information: 

■ Initial context factory supplied by the JNDI service provider 

■ Service provider URL for accessing the JNDI services 

■ Entity bean JNDI name 

■ Operation type (CREATE, UPDATE, or REMOVE) 

■ Finder method name (UPDATE and REMOVE operation types only) 

Define an Entity Bean Job 

You can define an Entity Bean (ENTYBEAN) job to create an entity bean, update the 

property values of an existing entity bean, or remove an entity bean from the database. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: ENTYBEAN 

Specifies that the job type is Entity Bean. 

machine 

Specifies the name of the machine on which the job runs. 

bean_name 

Specifies the JNDI name of the entity bean. 

 Entity Bean Jobs 

142 User Guide 

initial_context_factory 

Specifies the initial context factory to use when creating the initial context. The 

initial context is required within the Java Naming and Directory Interface (JNDI) 

framework. The initial context factory is supplied by a specific provider of the 

naming and directory service. The factory acquires an arbitrary initial context 

that the application can use to connect to the application server. 

operation_type 

Specifies the operation to perform on the entity bean: CREATE, UPDATE, 

REMOVE. 

provider_url 

Specifies the JNDI service provider URL. 

2. Specify the following attributes if the operation_type attribute is set to CREATE: 

create_name 

(Optional) Specifies the name of the create method. 

create_parameter 

(Optional) Specifies create parameters to create an entity bean in a relational 

database on your application server. 

3. Specify the following attributes if the operation_type attribute is set to UPDATE: 

finder_name 

Specifies the name of the finder method. 

finder_parameter 

Specifies the finder parameters. 

method_name 

Specifies the method to be invoked on the application server. 

modify_parameter 

(Optional) Specifies the modify parameters. 

4. Specify the following attributes if the operation_type attribute is set to REMOVE: 

finder_name 

Specifies the name of the finder method. 

finder_parameter 

(Optional) Specifies the finder parameters. 

5. (Optional) Specify optional Entity Bean attributes: 

■ j2ee_user 

■ job_class 

 Entity Bean Jobs 

6. (Optional) Specify common attributes that apply to all job types. 

The Entity Bean job is defined. When the job runs, it creates an entity bean, updates 

the property values of an existing entity bean, or removes an entity bean from the 

database. 

Notes: 

■ Attributes that have a default value automatically apply to the job definitions; 

therefore, they are optional. For example, jobs with no specified job type are 

defined as command jobs by default. Other optional attributes specify information 

that is not required but affects how or when a job runs, such as attributes that 

specify scheduling conditions. 

■ Some optional attributes are common to all job types but others apply to certain 

jobs types only. Optional attributes that apply to all job types are known as 

common optional attributes. For more information about common optional 

attributes and the values that you can specify for them (including their default 

values when applicable), see the Reference Guide. 

■ For information about required attributes and job type specific optional attributes, 

see the procedure topics that provide instructions for defining jobs. 

■ This guide provides instructions for defining jobs interactively. You also create job 

definitions in script files and then import them using the jil command or use CA 

WCC to define them. For more information about the JIL command and JIL syntax, 

see the Reference Guide. For more information about using CA WCC to define the 

job, see the CA Workload Control Center Workload Scheduling Guide. 

Example: Create an Entity Bean 

Suppose that you want to create an entity bean that stores information about a 

customer such as the customer ID and phone number. The initial context factory 

supplied by the JNDI service provider is weblogic.jndi.WLInitialContextFactory. The 

service provider's URL is t3://localhost:7001, where localhost is the domain name of the 

WebLogic application server and 7001 is the ORB port. When the job runs, the entity 

bean instance is created. 

insert_job: create 

job_type: ENTYBEAN 

machine: appagent 

initial_context_factory: weblogic.jndi.WLInitialContextFactory 

provider_url: "t3://localhost:7001" 

bean_name: customer 

create_name: createcustomer 

operation_type: CREATE 

create_parameter: String="customerid", String="800-555-0100" Entity Bean Jobs 

144 User Guide 

Example: Update an Entity Bean 

Suppose that you want to update the phone number for the Acme company to 

800-555-0199. The customer entity bean stores the customer ID and phone number. 

The primary key for the customer is the customer ID. To find the entity bean, the job 

uses the Acme's customer ID. When the job runs, the Acme company's phone number is 

changed. 

insert_job: update 

job_type: ENTYBEAN 

machine: appagent 

initial_context_factory: weblogic.jndi.WLInitialContextFactory 

provider_url: "t3://localhost:7001" 

bean_name: customer 

operation_type: UPDATE 

method_name: changephone 

finder_name: findByPrimaryKey 

finder_parameter: String="customerid" 

modify_parameter: String="800-555-0199" 

Example: Remove an Entity Bean 

Suppose that you want to remove the customer record for the Acme customer. The 

record is stored in the database by the customer ID. When the job runs, the row in the 

customer table that corresponds to the Acme customer ID is removed. 

insert_job: remove 

job_type: ENTYBEAN 

machine: appagent 

initial_context_factory: weblogic.jndi.WLInitialContextFactory 

provider_url: "t3://localhost:7001" 

bean_name: customer 

operation_type: REMOVE 

finder_name: findByPrimaryKey 

finder_parameter: String="customerid" 

More information: 

Insert a Job Definition 

HTTP Jobs 

The HTTP job invokes a program over HTTP in a similar way to a web browser. For 

example, you can use the HTTP job to invoke a CGI script, a Perl script, or a servlet. The 

HTTP job sends a URL over HTTP using the GET method or a form over HTTP using the 

POST method. The output of the invocation is returned in the job's spool file. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

The GET method requests data and sends the data as part of the URL. The POST method 

submits data and is the preferred method for sending lengthy form data. 

To define an HTTP job, you require the following information: 

■ URL of the application server 

■ Program or servlet to invoke 

Note: If your company has a firewall and you must communicate through a proxy server 

to access a computer outside the firewall, agent configuration is required. For more 

information on configuring the agent for a proxy, see the CA Workload Automation 

Agent for Application Services Implementation Guide. 

Define an HTTP Job 

You can define an HTTP job to invoke a program over HTTP. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: HTTP 

Specifies that the job type is HTTP. 

machine 

Specifies the name of the machine on which the job runs. 

provider_url 

Specifies the host where the program or servlet you want to invoke resides. 

 HTTP Jobs 

146 User Guide 

2. (Optional) Specify optional HTTP attributes: 

■ filter 

■ invocation_type 

■ j2ee_authentication_order 

■ j2ee_conn_domain 

■ j2ee_conn_origin 

■ j2ee_conn_user 

■ j2ee_no_global_proxy_defaults 

■ j2ee_parameter 

■ j2ee_proxy_domain 

■ j2ee_proxy_host 

■ j2ee_proxy_origin_host 

■ j2ee_proxy_port 

■ j2ee_proxy_user 

■ job_class 

■ method_name 

3. (Optional) Specify common attributes that apply to all job types. 

The HTTP job is defined. When the job runs, it invokes a program over HTTP. 

Notes: 

■ Attributes that have a default value automatically apply to the job definitions; 

therefore, they are optional. For example, jobs with no specified job type are 

defined as command jobs by default. Other optional attributes specify information 

that is not required but affects how or when a job runs, such as attributes that 

specify scheduling conditions. 

■ Some optional attributes are common to all job types but others apply to certain 

jobs types only. Optional attributes that apply to all job types are known as 

common optional attributes. For more information about common optional 

attributes and the values that you can specify for them (including their default 

values when applicable), see the Reference Guide. 

■ For information about required attributes and job type specific optional attributes, 

see the procedure topics that provide instructions for defining jobs. 

■ This guide provides instructions for defining jobs interactively. You also create job 

definitions in script files and then import them using the jil command or use CA 

WCC to define them. For more information about the JIL command and JIL syntax, 

see the Reference Guide. For more information about using CA WCC to define the 

job, see the CA Workload Control Center Workload Scheduling Guide. 

 HTTP Jobs 

Example: Define an HTTP Job to Perform a Google Search 

Suppose that you want to define a job to perform a Google search and have the results 

returned to the job's spool file. In this example, the job uses the HTTP GET method to 

perform the Google search on "ca workload automation". When the job runs, the job's 

spool file includes all the results of the search. 

insert_job: google 

job_type: HTTP 

machine: appagent 

invocation_type: GET 

provider_url: "http://google.com/search" 

j2ee_authentication_order: BASIC,DIGEST,NTLM 

j2ee_parameter: q="ca workload automation" 

Example: Define an HTTP Job to Subscribe to a Mailing List 

Suppose that you want to define a job to subscribe to a mailing list located on a local 

server. You want to add the email address test@abc.com to the list. The servlet path is 

/examples/servlets/servlet/TheServlet. 

insert_job: subscribe 

job_type: HTTP 

machine: appagent 

invocation_type: POST 

provider_url: "http://localhost:8080" 

method_name: /examples/servlets/servlet/TheServlet 

j2ee_parameter: key1="subscribe", key2="test@abc.com" 

More information: 

Insert a Job Definition (see page 88) 

Attributes with Default Values 

Attributes that have a default value automatically apply to the job definition. Therefore, 

you do not have to specify those attributes in the definition. Your agent administrator 

can define some default values on the agent in the agentparm.txt file. 

If you specify the attribute in a job definition, it overrides the default. 

 HTTP Jobs 

148 User Guide 

The following HTTP job attributes have default values: 

invocation_type 

Specifies whether to send the URL over HTTP using the GET or POST method. 

Default: POST 

j2ee_conn_origin 

Specifies the domain for NTLM connection authentication. 

Default: The computer name where the agent is running 

j2ee_no_global_proxy_defaults 

Specifies whether to use the global proxy configuration specified by the proxy 

parameters in the agentparm.txt file. 

Default: Y (The job does not use the global proxy configuration specified by the 

proxy parameters in the agentparm.txt file.) 

j2ee_proxy_domain 

Specifies the domain for proxy authentication. 

Default: http.proxyDomain agent parameter, if specified 

j2ee_proxy_host 

Specifies the proxy host name to use for the request. 

Default: http.proxyHost agent parameter, if specified 

j2ee_proxy_origin_host 

Specifies the origin host name for proxy authentication. 

Default: The computer name where the agent is running 

j2ee_proxy_port 

Specifies the proxy port to use for the request. 

Default: 80 

j2ee_proxy_user 

Specifies the user name required for proxy authentication. 

Default: http.proxyUser agent parameter, if specified 

Note: For more information about JIL job types and other job definition attributes, the 

values that you can specify for those attributes, and JIL syntax, see the Reference Guide. 

 HTTP Jobs 

Example: Define an HTTP Job to Send a URL Over HTTP 

Several attributes in the following job definition override the default values. 

This example performs an HTTP query using the HTTP GET method. The output of the 

invocation is returned in the job's spool file. In this example, the job specifies the 

connection domain and origin for NTLM authentication, overrides the global proxy 

defaults specified in the agentparm.txt file, and specifies the BASIC, DIGEST, and NTLM 

protocols for web server authentication. 

insert_job: HTTP.CON_USER 

job_type: HTTP 

machine: appagent 

invocation_type: GET 

provider_url: "http://host.example.com/protected" 

j2ee_conn_origin: host.example.com 

j2ee_conn_domain: windows_domain 

j2ee_conn_user: myuser@windows_domain 

j2ee_no_global_proxy_defaults: Y 

j2ee_authentication_order: BASIC,DIGEST,NTLM 

j2ee_proxy_domain: "http://host.domain.proxy" 

j2ee_proxy_host: proxy.example.com 

j2ee_proxy_origin_host: "http://host.origin.proxy" 

j2ee_proxy_port: 90 

j2ee_proxy_user: user01 JMS Publish and JMS Subscribe Jobs 

150 User Guide 

JMS Publish and JMS Subscribe Jobs 

Java Message Service (JMS) is the standard for enterprise messaging that lets a Java 

program or component (JMS client) produce and consume messages. Messages are the 

objects that communicate information between JMS clients. 

In a JMS system, a messaging server known as the JMS provider acts between two JMS 

clients (the publisher and the subscriber). Publishers send messages to the JMS provider 

while subscribers receive messages from the JMS provider. 

The following diagram shows the functional relationship between the scheduling 

manager, the CA WA Agent for Application Services, and a JMS provider: 

A queue is an object on the JMS server that holds messages sent by a client that are 

waiting to be consumed by another client. The queue retains a message until the 

message is consumed or the message expires. 

The following diagram shows Client 2 (the subscriber) consuming a message that Client 

1 (the publisher) sends to a queue: 

A topic is an object a client uses to specify the target of the messages it produces and 

the source of the messages it consumes. A client acquires a reference to a topic on a 

JMS server, and sends messages to that topic. When messages arrive for that topic, the 

JMS provider is responsible for notifying all clients. 

 JMS Publish and JMS Subscribe Jobs 

The following diagram shows two subscribers, Client 2 and Client 3, subscribed to a 

topic that the publisher, Client 1, publishes to: 

A JMS Publish job lets you send a message to a queue or publish a message to a topic. 

Using a JMS Publish job to publish to a topic, you can broadcast a message to any topic 

subscriber. A third-party client can consume this message, or a JMS Subscribe job can 

listen for a particular message (using a filter). 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

The following diagram shows a JMS Publish job scenario: 

A JMS Subscribe job lets you consume messages from a queue or topic. Using a filter 

that you define within the job definition, the agent monitors the topic or queue output 

for specific data. The scheduling manager then sends the message that meets the filter 

criteria to a destination file you specify. You can define the job to continuously monitor 

JMS messages. 

 JMS Publish and JMS Subscribe Jobs 

152 User Guide 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

The following diagram shows a JMS Subscribe job scenario: 

To define a JMS Publish or JMS Subscribe job, you require the following information: 

■ Initial context factory supplied by the Java Naming and Directory Interface (JNDI) 

service provider 

■ JMS provider URL for accessing the JNDI services 

■ Connection factory JNDI name that looks up the referenced topic or queue 

■ JNDI name of the topic or queue on the JMS server 

■ Java class of the JMS message to send or publish 

 JMS Publish and JMS Subscribe Jobs 

Define a JMS Publish Job 

You can define a JMS Publish job to send a message to a queue or publish a message to 

a topic. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: JMSPUB 

Specifies that the job type is JMS Publish. 

machine 

Specifies the name of the machine on which the job runs. 

connection_factory 

Specifies the connection factory JNDI name. The connection factory contains all 

the bindings needed to look up the referenced topic or queue. JMS jobs use the 

connection factory to create a connection with the JMS provider. 

destination_name 

Specifies the JNDI name of the topic or queue. The job uses the JNDI name to 

indicate the destination where messages are received. 

initial_context_factory 

Specifies the initial context factory to use when creating the initial context. The 

initial context is required within the Java Naming and Directory Interface (JNDI) 

framework. The initial context factory is supplied by a specific provider of the 

naming and directory service. The factory acquires an arbitrary initial context 

that the application can use to connect to the application server. 

j2ee_parameter 

Specifies the message to send to a queue or publish to a topic. 

message_class 

Specifies the Java class of the JMS message. 

provider_url 

Specifies the JNDI service provider URL. 

2. (Optional) Specify optional JMS Publish attributes: 

■ j2ee_user 

■ job_class 

■ use_topic 

 JMS Publish and JMS Subscribe Jobs 

154 User Guide 

3. (Optional) Specify common attributes that apply to all job types. 

The JMS Publish job is defined. When the job runs, it sends a message to a queue or 

publishes a message to a topic. 

Notes: 

■ Attributes that have a default value automatically apply to the job definitions; 

therefore, they are optional. For example, jobs with no specified job type are 

defined as command jobs by default. Other optional attributes specify information 

that is not required but affects how or when a job runs, such as attributes that 

specify scheduling conditions. 

■ Some optional attributes are common to all job types but others apply to certain 

jobs types only. Optional attributes that apply to all job types are known as 

common optional attributes. For more information about common optional 

attributes and the values that you can specify for them (including their default 

values when applicable), see the Reference Guide. 

■ For information about required attributes and job type specific optional attributes, 

see the procedure topics that provide instructions for defining jobs. 

■ This guide provides instructions for defining jobs interactively. You also create job 

definitions in script files and then import them using the jil command or use CA 

WCC to define them. For more information about the JIL command and JIL syntax, 

see the Reference Guide. For more information about using CA WCC to define the 

job, see the CA Workload Control Center Workload Scheduling Guide. 

 JMS Publish and JMS Subscribe Jobs 

Example: Publish a Message to the WebSphere Application Server 

This example publishes the message "this is my message" to the queue named Queue. 

The Java class of the message is String. The initial context factory supplied by the JNDI 

service provider is com.ibm.websphere.naming.WsnInitialContextFactory. The service 

provider's URL is iiop://172.24.0.0:2809, where 172.24.0.0 is the IP address of the 

WebSphere MQ server and 2809 is the ORB port. The job uses the cyberuser JNDI user 

name to gain access to the connection factory named ConnectionFactory. 

insert_job: publish 

job_type: JMSPUB 

machine: appagent 

initial_context_factory: com.ibm.websphere.naming.WsnInitialContextFactory 

provider_url: "iiop://172.24.0.0:2809" 

connection_factory: ConnectionFactory 

destination_name: Queue 

use_topic: FALSE 

message_class: String 

j2ee_user: cyberuser 

j2ee_parameter: java.lang.String="this is my message" 

Note: The agent does not support JMS messaging on IBM WebSphere. If you have IBM 

WebSphere MQ, your agent administrator can set up the agent plug-in to run JMS 

Publish and JMS Subscribe for JMS queues. JMS topics are not supported on IBM 

WebSphere MQ. 

More information: 

Insert a Job Definition (see page 88) 

Define a JMS Subscribe Job 

You can define a JMS Subscribe job to consume messages from a queue or topic. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: JMSSUB 

Specifies that the job type is JMS Subscribe. 

machine 

Specifies the name of the machine on which the job runs. 

 JMS Publish and JMS Subscribe Jobs 

156 User Guide 

connection_factory 

Specifies the connection factory JNDI name. The connection factory contains all 

the bindings needed to look up the referenced topic or queue. JMS jobs use the 

connection factory to create a connection with the JMS provider. 

destination_name 

Specifies the JNDI name of the topic or queue. The job uses the JNDI name to 

indicate the destination where messages are received. 

initial_context_factory 

Specifies the initial context factory to use when creating the initial context. The 

initial context is required within the Java Naming and Directory Interface (JNDI) 

framework. The initial context factory is supplied by a specific provider of the 

naming and directory service. The factory acquires an arbitrary initial context 

that the application can use to connect to the application server. 

provider_url 

Specifies the JNDI service provider URL. 

2. (Optional) Specify optional JMS Subscribe attributes: 

■ continuous 

■ destination_file 

■ filter 

■ j2ee_user 

■ job_class 

■ job_terminator 

■ use_topic 

3. (Optional) Specify common attributes that apply to all job types. 

The JMS Subscribe job is defined. When the job runs, it consumes messages from a 

queue or topic. 

 JMS Publish and JMS Subscribe Jobs 

Notes: 

■ Attributes that have a default value automatically apply to the job definitions; 

therefore, they are optional. For example, jobs with no specified job type are 

defined as command jobs by default. Other optional attributes specify information 

that is not required but affects how or when a job runs, such as attributes that 

specify scheduling conditions. 

■ Some optional attributes are common to all job types but others apply to certain 

jobs types only. Optional attributes that apply to all job types are known as 

common optional attributes. For more information about common optional 

attributes and the values that you can specify for them (including their default 

values when applicable), see the Reference Guide. 

■ For information about required attributes and job type specific optional attributes, 

see the procedure topics that provide instructions for defining jobs. 

■ This guide provides instructions for defining jobs interactively. You also create job 

definitions in script files and then import them using the jil command or use CA 

WCC to define them. For more information about the JIL command and JIL syntax, 

see the Reference Guide. For more information about using CA WCC to define the 

job, see the CA Workload Control Center Workload Scheduling Guide. 

Example: Monitor a Queue on a WebLogic Application Server 

This example continuously monitors the queue named Queue (residing on WebLogic) 

for a message matching the filter criteria. The consumed messages from the queue are 

stored in the file /export/home/user1/outputfile1. The service provider's URL is 

t3://172.24.0.0:7001, where 172.24.0.0 is the IP address of the WebLogic Application 

server and 7001 is the ORB port. 

insert_job: monitor 

job_type: JMSSUB 

machine: appagent 

initial_context_factory: weblogic.jndi.WLInitialContextFactory 

provider_url: "t3://172.24.0.0:7001" 

connection_factory: ConnectionFactory 

destination_name: Queue 

continuous: Y 

filter: abc\s...\s[a-zA-Z]+\sFilter![\sa-z0-9]+ 

use_topic: FALSE 

destination_file: /export/home/user1/outputfile1 

j2ee_user: cyberuser JMS Publish and JMS Subscribe Jobs 

158 User Guide 

In this example, the regular expression used as the filter criteria can be defined as 

follows: 

abc\s...\s[a-zA-Z]+\sFilter![\sa-z0-9]+ 

abc\s 

Specifies the text abc, followed by white space. 

...\s 

Specifies any three characters, followed by white space. 

[a-zA-Z]+\s 

Specifies at least one letter, followed by white space. 

Filter![\sa-z0-9]+ 

Specifies the text Filter!, followed by at least one of the following: white space or 

digit or lower case letter. 

Example: abc vvv B Filter! 95 

More information: 

Insert a Job Definition (see page 88) 

Attributes with Default Values 

Attributes that have a default value automatically apply to the job definition. Therefore, 

you do not have to specify those attributes in the definition. Your agent administrator 

can define some default values on the agent in the agentparm.txt file. 

If you specify the attribute in a job definition, it overrides the default. 

The following JMS job attributes have default values: 

continuous (JMS Subscribe jobs only) 

Specifies whether the job monitors the topic or queue continuously for messages. 

Default: N (The job immediately checks for the condition and completes.) 

job_terminator (JMS Subscribe jobs only) 

Specifies whether to terminate the job if its containing box fails or terminates. 

Default: n (The job does not terminate if its containing box fails or terminates.) 

destination_file (JMS Subscribe jobs only) 

Specifies the output destination file for the consumed messages. 

Default: spooldir agent parameter, if specified 

 JMS Publish and JMS Subscribe Jobs 

  

use_topic 

Specifies whether to send or publish messages to a topic or queue. 

Default: FALSE (The job sends or publishes messages to a queue.) 

Note: For more information about JIL job types and other job definition attributes, the 

values that you can specify for those attributes, and JIL syntax, see the Reference Guide. 

Example: Specify Optional Attributes in a JMS Subscribe Job 

The continuous and destination_file attributes in the following job definition override 

the default values. 

This example continuously monitors the queue named Queue (residing on WebLogic) 

for a message matching the filter criteria. The consumed messages from the queue are 

stored in the file /export/home/user1/outputfile1. The service provider's URL is 

t3://172.24.0.0:7001, where 172.24.0.0 is the IP address of the WebLogic Application 

server and 7001 is the ORB port. 

insert_job: monitor 

job_type: JMSSUB 

machine: appagent 

initial_context_factory: weblogic.jndi.WLInitialContextFactory 

provider_url: "t3://172.24.0.0:7001" 

connection_factory: ConnectionFactory 

destination_name: Queue 

continuous: Y 

filter: abc\s...\s[a-zA-Z]+\sFilter![\sa-z0-9]+ 

use_topic: FALSE 

destination_file: /export/home/user1/outputfile1 

j2ee_user: cyberuser JMX Jobs 

160 User Guide 

In this example, the regular expression used as the filter criteria can be defined as 

follows: 

abc\s...\s[a-zA-Z]+\sFilter![\sa-z0-9]+ 

abc\s 

Specifies the text abc, followed by white space. 

...\s 

Specifies any three characters, followed by white space. 

[a-zA-Z]+\s 

Specifies at least one letter, followed by white space. 

Filter![\sa-z0-9]+ 

Specifies the text Filter!, followed by at least one of the following: white space or 

digit or lower case letter. 

Example: abc vvv B Filter! 95 

JMX Jobs 

Java Management Extension (JMX) technology is included in the Java Standard Edition 

(SE) platform, version 5 and higher. JMX lets you remotely access applications, using a 

Remote Method Invocation (RMI) connector, for monitoring and management 

purposes. 

JMX jobs let you access a remote JMX server that advertises MBeans. An MBean is a 

managed bean (Java object) that represents an application, a device, or any resource 

that you want to manage. An MBean contains a set of attributes and a set of operations 

that can be invoked. Some MBeans can send out notifications, for example, when an 

attribute changes. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

Consider an MBean named Config that represents an application's configuration. The 

configuration parameters within that application are represented in Config by a set of 

attributes. Getting the attribute named cachesize, for example, returns the current 

value of the cachesize. Setting the value updates the cachesize. The Config MBean can 

send out a notification every time the cachesize changes. An operation named update, 

for example, can save changes to the configuration parameters. 

 JMX Jobs 

The following diagram shows the functional relationship between the scheduling 

manager, CA WA Agent for Application Services, and the JMX server: 

The JMX jobs provide support for getting and setting JMX MBean attributes, invoking 

JMX MBean operations, subscribing to MBean notifications, and creating and removing 

instances of MBeans on a JMX server. 

You can define the following six types of JMX jobs: 

■ JMX-MBean Attribute Get 

■ JMX-MBean Attribute Set 

■ JMX-MBean Create Instance 

■ JMX-MBean Operation 

■ JMX-MBean Remove Instance 

■ JMX-MBean Subscribe 

The JMX-MBean Attribute Set, JMX-MBean Create Instance, and JMX-MBean Operation 

jobs support calls to MBeans that can involve passing parameters. Each parameter can 

be an actual value or a serialized Java object passed by another job. When the 

JMX-MBean Operation job invokes an operation on an MBean that passes parameters, 

the parameters are passed to the MBean and the returned serialized Java object is 

stored on the agent computer in the spool directory or in a destination file you specify. 

To define JMX jobs, you require a URL to connect to the JMX server using an RMI 

connector. 

Define a JMX-MBean Attribute Get Job 

You can define a JMX-MBean Attribute Get job to query a JMX server for the value of an 

MBean attribute. The returned value is stored on the computer where the agent 

resides. You can specify a success pattern to determine the job's success or failure. If the 

returned attribute value matches the success pattern, the job completes successfully; 

otherwise, it fails. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

 JMX Jobs 

162 User Guide 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: JMXMAG 

Specifies that the job type is JMX-MBean Attribute Get. 

machine 

Specifies the name of the machine on which the job runs. 

mbean_attr 

Specifies the name of the MBean attribute that you want to query. 

mbean_name 

Specifies the full object name of an MBean. 

URL 

Specifies the URL to connect to the JMX server using an RMI connector. 

2. (Optional) Specify optional JMX-MBean Attribute Get attributes: 

■ job_class 

■ jmx_user 

■ success_pattern 

3. (Optional) Specify common attributes that apply to all job types. 

The JMX-MBean Attribute Get job is defined. When the job runs, it queries a JMX 

server for the value of an MBean attribute. 

 JMX Jobs 

Notes: 

■ Attributes that have a default value automatically apply to the job definitions; 

therefore, they are optional. For example, jobs with no specified job type are 

defined as command jobs by default. Other optional attributes specify information 

that is not required but affects how or when a job runs, such as attributes that 

specify scheduling conditions. 

■ Some optional attributes are common to all job types but others apply to certain 

jobs types only. Optional attributes that apply to all job types are known as 

common optional attributes. For more information about common optional 

attributes and the values that you can specify for them (including their default 

values when applicable), see the Reference Guide. 

■ For information about required attributes and job type specific optional attributes, 

see the procedure topics that provide instructions for defining jobs. 

■ This guide provides instructions for defining jobs interactively. You also create job 

definitions in script files and then import them using the jil command or use CA 

WCC to define them. For more information about the JIL command and JIL syntax, 

see the Reference Guide. For more information about using CA WCC to define the 

job, see the CA Workload Control Center Workload Scheduling Guide. 

Example: Query a JMX Server for the Value of an MBean Attribute 

Suppose that you want to know the value of the cachesize attribute for the Config 

MBean. The URL for the JMX server is 

service:jmx:rmi:///jndi/rmi://localhost:9999/server, where localhost is the host name 

and 9999 is the port number. 

insert_job: query 

job_type: JMXMAG 

machine: appagent 

URL: "service:jmx:rmi:///jndi/rmi://localhost:9999/server" 

mbean_name: "DefaultDomain:index=1,type=Config" 

mbean_attr: cachesize 

More information: 

Insert a Job Definition (see page 88) 

 JMX Jobs 

164 User Guide 

Define a JMX-MBean Attribute Set Job 

You can define a JMX-MBean Attribute Set job to change the value of an MBean 

attribute on a JMX server. You can specify a set value for the attribute or use the 

serialized Java object passed by another job. When the attribute is set, the job returns 

the original attribute value as output. You can specify a success pattern to determine 

the job's success or failure. If the job's output matches the success pattern, the job 

completes successfully; otherwise, it fails. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: JMXMAS 

Specifies that the job type is JMX-MBean Attribute Set. 

machine 

Specifies the name of the machine on which the job runs. 

mbean_attr 

Specifies the name of the MBean attribute that you want to set. 

mbean_name 

Specifies the full object name of an MBean. 

URL 

Specifies the URL to connect to the JMX server using an RMI connector. 

2. (Optional) Specify optional JMX-MBean Attribute Set attributes: 

■ jmx_parameter 

■ jmx_user 

■ job_class 

■ success_pattern 

3. (Optional) Specify common attributes that apply to all job types. 

The JMX-MBean Attribute Set job is defined. When the job runs, it changes the 

value of an MBean attribute on a JMX server. 

 JMX Jobs 

Notes: 

■ Attributes that have a default value automatically apply to the job definitions; 

therefore, they are optional. For example, jobs with no specified job type are 

defined as command jobs by default. Other optional attributes specify information 

that is not required but affects how or when a job runs, such as attributes that 

specify scheduling conditions. 

■ Some optional attributes are common to all job types but others apply to certain 

jobs types only. Optional attributes that apply to all job types are known as 

common optional attributes. For more information about common optional 

attributes and the values that you can specify for them (including their default 

values when applicable), see the Reference Guide. 

■ For information about required attributes and job type specific optional attributes, 

see the procedure topics that provide instructions for defining jobs. 

■ This guide provides instructions for defining jobs interactively. You also create job 

definitions in script files and then import them using the jil command or use CA 

WCC to define them. For more information about the JIL command and JIL syntax, 

see the Reference Guide. For more information about using CA WCC to define the 

job, see the CA Workload Control Center Workload Scheduling Guide. 

Example: Change the Value of an MBean Attribute 

Suppose that you want to set the value of the State attribute of the 

cdc.jmx.SimpleDynamic MBean to the serialized Java object returned by a JMX-MBean 

Attribute Set job named size. 

insert_job: change 

job_type: JMXMAS 

machine: appagent 

URL: "service:jmx:rmi:///jndi/rmi://agenttest:5099/jmxserver" 

mbean_name: "DefaultDomain:index=1,type=cdc.jmx.SimpleDynamic" 

mbean_attr: State 

jmx_parameter: payload_job=size 

condition: success(size) 

More information: 

Insert a Job Definition (see page 88) 

 JMX Jobs 

166 User Guide 

Define a JMX-MBean Create Instance Job 

You can define a JMX-MBean Create Instance job to create an MBean on a JMX server. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: JMXMC 

Specifies that the job type is JMX-MBean Create Instance. 

machine 

Specifies the name of the machine on which the job runs. 

class_name 

Specifies the fully qualified Java class of the MBean object. 

mbean_name 

Specifies the full object name of an MBean. 

URL 

Specifies the URL to connect to the JMX server using an RMI connector. 

2. (Optional) Specify optional JMX-MBean Create Instance attributes: 

■ jmx_parameter 

■ jmx_user 

■ job_class 

3. (Optional) Specify common attributes that apply to all job types. 

The JMX-MBean Create Instance job is defined. When the job runs, it creates an 

MBean on a JMX server. 

 JMX Jobs 

Notes: 

■ Attributes that have a default value automatically apply to the job definitions; 

therefore, they are optional. For example, jobs with no specified job type are 

defined as command jobs by default. Other optional attributes specify information 

that is not required but affects how or when a job runs, such as attributes that 

specify scheduling conditions. 

■ Some optional attributes are common to all job types but others apply to certain 

jobs types only. Optional attributes that apply to all job types are known as 

common optional attributes. For more information about common optional 

attributes and the values that you can specify for them (including their default 

values when applicable), see the Reference Guide. 

■ For information about required attributes and job type specific optional attributes, 

see the procedure topics that provide instructions for defining jobs. 

■ This guide provides instructions for defining jobs interactively. You also create job 

definitions in script files and then import them using the jil command or use CA 

WCC to define them. For more information about the JIL command and JIL syntax, 

see the Reference Guide. For more information about using CA WCC to define the 

job, see the CA Workload Control Center Workload Scheduling Guide. 

Example: Create an MBean Instance on a JMX Server 

Suppose that you want to create an MBean instance on a JMX server. The job uses the 

cdc.jmx.SimpleDynamic class. The constructor of the class takes a single string 

parameter with the value "Hello". 

insert_job: create 

job_type: JMXMC 

machine: appagent 

URL: "service:jmx:rmi:///jndi/rmi://agenttest:5099/jmxserver" 

mbean_name: "DefaultDomain:index=CreateIns1,type=cdc.jmx.SimpleDynamic" 

class_name: cdc.jmx.SimpleDynamic 

jmx_parameter: java.lang.String="Hello" 

More information: 

Insert a Job Definition (see page 88) 

 JMX Jobs 

168 User Guide 

Define a JMX-MBean Operation Job 

You can define a JMX-MBean Operation job to invoke an operation on an MBean. You 

can specify one or more parameter values to pass to the operation. You can specify a 

success pattern to determine the job's success or failure. If the operation's output 

matches the success pattern, the job completes successfully; otherwise, it fails. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: JMXMOP 

Specifies that the job type is JMX-MBean Operation. 

machine 

Specifies the name of the machine on which the job runs. 

mbean_name 

Specifies the full object name of an MBean. 

mbean_operation 

Specifies the operation to be invoked. 

URL 

Specifies the URL to connect to the JMX server using an RMI connector. 

2. (Optional) Specify optional JMX-MBean Operation attributes: 

■ jmx_parameter 

■ jmx_user 

■ job_class 

■ success_pattern 

3. (Optional) Specify common attributes that apply to all job types. 

The JMX-MBean Operation job is defined. When the job runs, it invokes an 

operation on an MBean. 

 JMX Jobs 

Notes: 

■ Attributes that have a default value automatically apply to the job definitions; 

therefore, they are optional. For example, jobs with no specified job type are 

defined as command jobs by default. Other optional attributes specify information 

that is not required but affects how or when a job runs, such as attributes that 

specify scheduling conditions. 

■ Some optional attributes are common to all job types but others apply to certain 

jobs types only. Optional attributes that apply to all job types are known as 

common optional attributes. For more information about common optional 

attributes and the values that you can specify for them (including their default 

values when applicable), see the Reference Guide. 

■ For information about required attributes and job type specific optional attributes, 

see the procedure topics that provide instructions for defining jobs. 

■ This guide provides instructions for defining jobs interactively. You also create job 

definitions in script files and then import them using the jil command or use CA 

WCC to define them. For more information about the JIL command and JIL syntax, 

see the Reference Guide. For more information about using CA WCC to define the 

job, see the CA Workload Control Center Workload Scheduling Guide. 

Example: Invoke an Operation on an MBean 

Suppose that you want to invoke the resetmem operation on the config MBean to reset 

the value of the memory parameter to 50. 

insert_job: reset 

job_type: JMXMOP 

machine: agent 

URL: "service:jmx:rmi:///jndi/rmi://localhost:9999/server" 

mbean_name: "DefaultDomain:index=1,type=Config" 

mbean_operation: resetmem 

jmx_parameter: Integer=50 JMX Jobs 

170 User Guide 

Example: Pass Payload Producing Output as Input to Payload Consuming Job 

Suppose that you want to use a JMX-MBean Operation job to invoke a method on an 

MBean and pass the output of the method as input to another JMX-MBean Operation 

job. 

In this example, the first job, test_JMXMOP2a, is a payload producing job. It takes a 

single input parameter and invokes the reset method on the MBean. The output of this 

job is stored as a serialized Java object on the computer where the agent resides. 

The second job, test_JMXMOP2b, is a payload consuming job. It takes two input 

parameters: the string "Hello" and the serialized Java object produced by the first job. 

The two input parameters are passed to the reset method, which is invoked on the 

MBean. 

insert_job: test_JMXMOP2a 

machine: localhost 

job_type: JMXMOP 

url: "service:jmx:rmi:///jndi/rmi://localhost:9999/server" 

mbean_name: "DefaultDomain:type=SimpleStandard,index=1" 

mbean_operation: reset 

jmx_parameter: String="Hello" 

insert_job: test_JMXMOP2b 

machine: localhost 

job_type: JMXMOP 

url: "service:jmx:rmi:///jndi/rmi://localhost:9999/server" 

mbean_name: "DefaultDomain:type=SimpleStandard,index=1" 

mbean_operation: reset 

jmx_parameter: String="Hello", payload_job=test_JMXMOP2a 

condition: S(test_JMXMOP2a) 

More information: 

Insert a Job Definition 

 JMX Jobs 

Define a JMX-MBean Remove Instance Job 

You can define a JMX-MBean Remove Instance job to remove an MBean from a JMX 

server. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: JMXMREM 

Specifies that the job type is JMX-MBean Remove Instance. 

machine 

Specifies the name of the machine on which the job runs. 

mbean_name 

Specifies the full object name of an MBean. 

URL 

Specifies the URL to connect to the JMX server using an RMI connector. 

2. (Optional) Specify optional JMX-MBean Remove Instance attributes: 

■ jmx_user 

■ job_class 

3. (Optional) Specify common attributes that apply to all job types. 

The JMX-MBean Remove Instance job is defined. When the job runs, it removes an 

MBean from a JMX server. 

 JMX Jobs 

172 User Guide 

Notes: 

■ Attributes that have a default value automatically apply to the job definitions; 

therefore, they are optional. For example, jobs with no specified job type are 

defined as command jobs by default. Other optional attributes specify information 

that is not required but affects how or when a job runs, such as attributes that 

specify scheduling conditions. 

■ Some optional attributes are common to all job types but others apply to certain 

jobs types only. Optional attributes that apply to all job types are known as 

common optional attributes. For more information about common optional 

attributes and the values that you can specify for them (including their default 

values when applicable), see the Reference Guide. 

■ For information about required attributes and job type specific optional attributes, 

see the procedure topics that provide instructions for defining jobs. 

■ This guide provides instructions for defining jobs interactively. You also create job 

definitions in script files and then import them using the jil command or use CA 

WCC to define them. For more information about the JIL command and JIL syntax, 

see the Reference Guide. For more information about using CA WCC to define the 

job, see the CA Workload Control Center Workload Scheduling Guide. 

Example: Remove an MBean Instance from a JMX Server 

Suppose that you want to remove an MBean instance. 

insert_job: remove 

job_type: JMXMREM 

machine: appagent 

URL: "service:jmx:rmi:///jndi/rmi://agenttest:5099/jmxserver" 

mbean_name: "DefaultDomain:index=CreateIns1,type=cdc.jmx.SimpleDynamic" 

More information: 

Insert a Job Definition (see page 88) 

Define a JMX-MBean Subscribe Job 

You can define a JMX-MBean Subscribe job to monitor an MBean for a single 

notification or monitor continuously for notifications. You can filter the notifications the 

job monitors by attributes or by type of notifications. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

 JMX Jobs 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: JMXSUB 

Specifies that the job type is JMX-MBean Subscribe. 

machine 

Specifies the name of the machine on which the job runs. 

mbean_name 

Specifies the full object name of an MBean. 

URL 

Specifies the URL to connect to the JMX server using an RMI connector. 

2. (Optional) Specify optional JMX-MBean Subscribe attributes: 

■ continuous 

■ filter 

■ filter_type 

■ jmx_user 

■ job_class 

■ job_terminator 

3. (Optional) Specify common attributes that apply to all job types. 

The JMX-MBean Subscribe job is defined. When the job runs, it monitors an MBean 

for a single notification or continuously for notifications. 

 JMX Jobs 

174 User Guide 

Notes: 

■ Attributes that have a default value automatically apply to the job definitions; 

therefore, they are optional. For example, jobs with no specified job type are 

defined as command jobs by default. Other optional attributes specify information 

that is not required but affects how or when a job runs, such as attributes that 

specify scheduling conditions. 

■ Some optional attributes are common to all job types but others apply to certain 

jobs types only. Optional attributes that apply to all job types are known as 

common optional attributes. For more information about common optional 

attributes and the values that you can specify for them (including their default 

values when applicable), see the Reference Guide. 

■ For information about required attributes and job type specific optional attributes, 

see the procedure topics that provide instructions for defining jobs. 

■ This guide provides instructions for defining jobs interactively. You also create job 

definitions in script files and then import them using the jil command or use CA 

WCC to define them. For more information about the JIL command and JIL syntax, 

see the Reference Guide. For more information about using CA WCC to define the 

job, see the CA Workload Control Center Workload Scheduling Guide. 

Example: Monitor for a Change to a Specific MBean Attribute 

Suppose that you want to monitor for a change to the cachesize attribute of the MBean 

named Config. The job filters the notifications the MBean sends by attribute. When the 

cachesize attribute changes, the job completes. 

insert_job: change 

job_type: JMXSUB 

machine: agent 

URL: "service:jmx:rmi:///jndi/rmi://localhost:9999/server" 

mbean_name: "DefaultDomain:index=1,type=Config" 

filter_type: Attributes 

filter: cachesize 

More information: 

Insert a Job Definition (see page 88) 

Attributes with Default Values 

Attributes that have a default value automatically apply to the job definition. Therefore, 

you do not have to specify those attributes in the definition. Your agent administrator 

can define some default values on the agent in the agentparm.txt file. 

If you specify the attribute in a job definition, it overrides the default. 

 JMX Jobs 

The following JMX Subscribe job attributes have default values: 

continuous 

Specifies whether the job monitors the MBean continuously for notifications. 

Default: N (The job immediately checks for the condition and completes.) 

filter_type 

Specifies whether to filter notifications by attribute or by notification type. 

Default: Attributes (The job filters notifications by attribute.) 

job_terminator 

Specifies whether to terminate the job if its containing box fails or terminates. 

Default: n (The job does not terminate if its containing box fails or terminates.) 

destination_file 

Specifies the output destination file for the Java serialized object produced by the 

job. 

Default: spooldir agent parameter, if specified 

Note: For more information about JIL job types and other job definition attributes, the 

values that you can specify for those attributes, and JIL syntax, see the Reference Guide. 

Example: Monitor for Changes to Any MBean Attribute 

The continuous attribute in the following job definition overrides the default value. 

Suppose that you want to set up continuous monitoring for changes to any attribute of 

the MBean named Config. Each time an attribute changes, an alert is written to the 

scheduler log file. 

insert_job: change 

job_type: JMXSUB 

machine: appagent 

URL: "service:jmx:rmi:///jndi/rmi://localhost:9999/server" 

mbean_name: "DefaultDomain:index=1,type=Config" 

continuous: Y 

filter_type: Types 

filter: jmx.attribute.change POJO Jobs 

176 User Guide 

POJO Jobs 

A Plain Old Java Object (POJO) is a Java object that follows the Java Language 

Specification only. All Java objects are POJOs. 

The POJO job lets you instantiate a class to create a Java object and invoke a method on 

it. The job is restricted to classes that take constructors with no arguments (default 

constructors). 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and either CA WA Agent for Application Services or CA WA Agent for Web Services. 

You can use the POJO job to invoke custom Java code on a local computer. POJO jobs 

support method calls that can involve passing parameters. The parameters can be actual 

values or a serialized Java object passed by another job. When the POJO job invokes a 

method on an object, the parameters, if any, are passed to the object and the returned 

values are stored in a Java serialized object file. 

To define a POJO job, you require the class name and method you want to call on the 

instantiated object. 

Note: If you use custom Java code, contact your agent administrator to verify the 

required JAR file is available in the jars subdirectory of the agent installation directory. 

Define a POJO Job 

You can define a POJO job to create a Java object instance with no arguments, invoke a 

method on the object instance, and store the method's output. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and either CA WA Agent for Application Services or CA WA Agent for Web Services. 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: POJO 

Specifies that the job type is POJO. 

machine 

Specifies the name of the machine on which the job runs. 

class_name 

Specifies the Java class to instantiate. 

method_name 

Specifies the Java method to call on the instance of the Java object. 

 POJO Jobs 

  

2. (Optional) Specify optional POJO attributes: 

■ destination_file 

■ j2ee_parameter 

■ job_class 

3. (Optional) Specify common attributes that apply to all job types. 

The POJO job is defined. When the job runs, it creates a Java object instance with 

no arguments, invokes a method on the object instance, and stores the method's 

output. 

Notes: 

■ Attributes that have a default value automatically apply to the job definitions; 

therefore, they are optional. For example, jobs with no specified job type are 

defined as command jobs by default. Other optional attributes specify information 

that is not required but affects how or when a job runs, such as attributes that 

specify scheduling conditions. 

■ Some optional attributes are common to all job types but others apply to certain 

jobs types only. Optional attributes that apply to all job types are known as 

common optional attributes. For more information about common optional 

attributes and the values that you can specify for them (including their default 

values when applicable), see the Reference Guide. 

■ For information about required attributes and job type specific optional attributes, 

see the procedure topics that provide instructions for defining jobs. 

■ This guide provides instructions for defining jobs interactively. You also create job 

definitions in script files and then import them using the jil command or use CA 

WCC to define them. For more information about the JIL command and JIL syntax, 

see the Reference Guide. For more information about using CA WCC to define the 

job, see the CA Workload Control Center Workload Scheduling Guide. 

Example: Invoke a Method on a Java Object Instance 

Suppose that you want to define a POJO job that creates a Java String with value "5" and 

calls the parseInt method with the created Java String object as an argument. The 

parseInt method returns a Java Integer object. 

insert_job: ignore 

job_type: POJO 

machine: appagent 

class_name: java.lang.Integer 

method_name: parseInt 

j2ee_parameter: java.lang.String=5 RMI Jobs 

178 User Guide 

More information: 

Insert a Job Definition (see page 88) 

RMI Jobs 

Remote Method Invocation (RMI) is the Java version of a Remote Procedure Call (RPC), 

which is a technology that lets a program request a service from another program 

located in another address space. That address space could be on the same computer or 

on a different one. 

RMI jobs let you set up interaction between Java objects on different computers in a 

distributed network. Using an RMI job, you can access a remote server and invoke a 

method on a Java object. A method is a programmed procedure that is defined as a part 

of a Java class. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

RMI jobs support method calls to remote objects that can involve passing parameters. 

The parameters can be actual values or a serialized Java object passed by another job. 

When the RMI job invokes a method on an object that passes parameters, the 

parameters are passed to the remote object and the returned serialized Java object is 

stored on the agent computer in the spool directory or in a destination file you specify. 

RMI uses a naming or directory service to locate the remote object on the remote 

server. To define an RMI job, you require the naming class of the Java object you want 

to invoke a method on. That naming class takes a name that is a java.lang.String in URL 

format. 

The following diagram shows the functional relationship between the scheduling 

manager, CA WA Agent for Application Services, and an RMI Server: 

 RMI Jobs 

Define an RMI Job 

You can define an RMI job to call a method on a remote server and store the method's 

output. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: JAVARMI 

Specifies that the job type is RMI. 

machine 

Specifies the name of the machine on which the job runs. 

method_name 

Specifies the method of the remote Java class to invoke. 

remote_name 

Specifies the reference location of the object you want to invoke a method on. 

2. (Optional) Specify optional RMI attributes: 

■ destination_file 

■ j2ee_parameter 

■ job_class 

3. (Optional) Specify common attributes that apply to all job types. 

The RMI job is defined. When the job runs, it calls a method on a remote server and 

stores the method's output. 

 RMI Jobs 

180 User Guide 

Notes: 

■ Attributes that have a default value automatically apply to the job definitions; 

therefore, they are optional. For example, jobs with no specified job type are 

defined as command jobs by default. Other optional attributes specify information 

that is not required but affects how or when a job runs, such as attributes that 

specify scheduling conditions. 

■ Some optional attributes are common to all job types but others apply to certain 

jobs types only. Optional attributes that apply to all job types are known as 

common optional attributes. For more information about common optional 

attributes and the values that you can specify for them (including their default 

values when applicable), see the Reference Guide. 

■ For information about required attributes and job type specific optional attributes, 

see the procedure topics that provide instructions for defining jobs. 

■ This guide provides instructions for defining jobs interactively. You also create job 

definitions in script files and then import them using the jil command or use CA 

WCC to define them. For more information about the JIL command and JIL syntax, 

see the Reference Guide. For more information about using CA WCC to define the 

job, see the CA Workload Control Center Workload Scheduling Guide. 

Example: Define a Job to Start a Remote Server Immediately 

Suppose that you want to invoke a method that starts a remote server using remote 

object activation. You want the server to start immediately. 

insert_job: start 

job_type: JAVARMI 

machine: appagent 

remote_name: "rmi://remotehost/Test" 

method_name: startserver 

j2ee_parameter: String="now" 

More information: 

Insert a Job Definition  

Session Bean Jobs 

A session bean represents business logic or action to be taken (for example, charging a 

credit card or adding items to an online shopping cart). 

Unlike entity beans, which are stored in a database, session beans may be destroyed 

after each use. For example, when a session bean is invoked to perform credit card 

validation, the application server creates an instance of that session bean, performs the 

business logic to validate the credit card transaction, and then destroys the session bean 

instance after the credit card transaction has been validated. 

You can use a session bean under the following conditions: 

■ The bean represents a procedure and not a business entity. For example, you use a 

session bean to encrypt data or add items to an online shopping cart. 

■ The state of the bean does not have to be kept in permanent storage. For example, 

when the bean instance terminates or the application server shuts down, the bean's 

state is no longer required. 

The following diagram shows the functional relationship between the scheduling 

manager, CA WA Agent for Application Services, and a session bean residing on an 

application server: 

The Session Bean job lets you access a session bean on an application server. This job 

type can make a Remote Procedure Call (RPC) to the session bean, invoke a method that 

defines the business logic, pass parameters to the method, and have the results 

returned as serialized Java output. The output can be stored on the agent computer as 

text in the spool file or as a serialized Java object in the spool directory or a destination 

file you specify. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

You can access stateless and stateful session beans using the Session Bean job. The job 

acts in a similar way for both types of beans. For both stateful and stateless beans, you 

can specify parameters to pass to the method. When you define a stateful session bean, 

however, you must specify parameters to define the bean. After the method is invoked, 

the agent destroys the stateful bean. 

 Session Bean Jobs 

182 User Guide 

Use a stateless Session Bean job to invoke a single instance of a method on the bean, 

such as encrypting data or sending an email to confirm an order. Use a stateful Session 

Bean job to invoke the same method on the bean multiple times, such as adding 

multiple items to an online shopping cart. 

A Session Bean job requires a dedicated connection between the agent and the 

application server. To define a Session Bean job, you require the following information: 

■ Initial context factory supplied by the Java Naming and Directory Interface (JNDI) 

service provider 

■ Service provider URL for accessing the JNDI services 

■ Session bean JNDI name 

■ Method to be invoked 

Define a Session Bean Job 

You can define a Session Bean (SESSBEAN) job to access a stateless or stateful session 

bean, invoke a method on the bean, and return the results. 

Note: To run these jobs, your system requires CA WA Agent for UNIX, Linux, or Windows 

and CA WA Agent for Application Services. 

Follow these steps: 

1. Insert a job and specify the following attributes in the definition: 

job_type: SESSBEAN 

Specifies that the job type is Session Bean. 

machine 

Specifies the name of the machine on which the job runs. 

bean_name 

Specifies the JNDI name of the session bean. 

initial_context_factory 

Specifies the initial context factory to use when creating the initial context. The 

initial context is required within the Java Naming and Directory Interface (JNDI) 

framework. The initial context factory is supplied by a specific provider of the 

naming and directory service. The factory acquires an arbitrary initial context 

that the application can use to connect to the application server. 

method_name 

Specifies the method to be invoked on the application server. 

 Session Bean Jobs 

provider_url 

Specifies the JNDI service provider URL. 

2. Specify the following attributes to access a stateful session bean: 

create_method 

Specifies the name of the create method. 

create_parameter 

 Specifies the create parameters. 

3. (Optional) Specify optional Session Bean attributes: 

■ destination_file 

■ j2ee_parameter 

■ j2ee_user 

■ job_class 

4. (Optional) Specify common attributes that apply to all job types. 

The Session Bean job is defined. When the job runs, it accesses a stateless or 

stateful session bean, invokes a method on the bean, and returns the results. 

Notes: 

■ Attributes that have a default value automatically apply to the job definitions; 

therefore, they are optional. For example, jobs with no specified job type are 

defined as command jobs by default. Other optional attributes specify information 

that is not required but affects how or when a job runs, such as attributes that 

specify scheduling conditions. 

■ Some optional attributes are common to all job types but others apply to certain 

jobs types only. Optional attributes that apply to all job types are known as 

common optional attributes. For more information about common optional 

attributes and the values that you can specify for them (including their default 

values when applicable), see the Reference Guide. 

■ For information about required attributes and job type specific optional attributes, 

see the procedure topics that provide instructions for defining jobs. 

■ This guide provides instructions for defining jobs interactively. You also create job 

definitions in script files and then import them using the jil command or use CA 

WCC to define them. For more information about the JIL command and JIL syntax, 

see the Reference Guide. For more information about using CA WCC to define the 

job, see the CA Workload Control Center Workload Scheduling Guide. 

 Session Bean Jobs 

184 User Guide 

Example: Invoke a Method on a Stateless Session Bean 

Suppose that you want to invoke the reverse method on the CybEJBTestBean stateless 

session bean. The reverse method has one parameter, with type java.lang.String and 

value a23. The output from the reverse method is saved in the C:\Makapt15 file. The 

initial context factory supplied by the JNDI service provider is 

com.ibm.websphere.naming.WsnInitialContextFactory. The service provider's URL is 

corbaloc:iiop://172.24.0.0:2809, where 172.24.0.0 is the IP address of the WebSphere 

application server and 2809 is the ORB port. When the job runs, the output of the 

reverse method is stored in the output destination file. 

insert_job: reverse 

job_type: SESSBEAN 

machine: appagent 

initial_context_factory: com.ibm.websphere.naming.WsnInitialContextFactory 

provider_url: "corbaloc:iiop://172.24.0.0:2809" 

bean_name: CybEJBTestBean 

method_name: reverse 

destination_file: "C:\Makapt15" 

j2ee_user: cyberuser 

j2ee_parameter: java.lang.String="a23" 

More information: 

Insert a Job Definition 

Attributes with Default Values 

Attributes that have a default value automatically apply to the job definition. Therefore, 

you do not have to specify those attributes in the definition. Your agent administrator 

can define some default values on the agent in the agentparm.txt file. 

If you specify the attribute in a job definition, it overrides the default. 

The following Session Bean job attributes have default values: 

create_method 

Specifies the name of the create method. 

Default: create 

 Session Bean Jobs 

destination_file 

Specifies the output destination file for the Java serialized object produced by the 

job. 

Default: spooldir agent parameter, if specified 

Note: For more information about JIL job types and other job definition attributes, the 

values that you can specify for those attributes, and JIL syntax, see the Reference Guide. 

Example: Invoke a Method on a Stateful Session Bean 

The create_method attribute in the following job definition overrides the default value. 

Suppose that you want to access a stateful session bean for an online shopping cart. The 

createaddbook method creates the Shoppingcart stateful bean for the duration of the 

job. The addbook method adds books to the shopping cart using the book's ISBN 

number. In this example, the Session Bean job adds two books to the shopping cart with 

ISBN numbers 1551929120 and 1582701709. When the job runs, two books are added 

to the shopping cart. 

insert_job: addbook 

job_type: SESSBEAN 

machine: appagent 

initial_context_factory: com.ibm.websphere.naming.WsnInitialContextFactory 

provider_url: "iiop://172.24.0.0:2809" 

bean_name: Shoppingcart 

create_method: createaddbook 

method_name: addbook 

create_parameter: String="ISBN" 

j2ee_parameter: Integer[2]="1551929120,1582701709"