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.
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"
No comments:
Post a Comment