+

Search Tips   |   Advanced Search

 

Auditing invocations of the wsadmin tool

 

Run the following wsadmin scripts as part of the environment setup: create the cluster definition, create data sources and JMS object configuration, or install one or more EAR files that comprise the hosted software on the appserver. Each of the scripts, wsadmin and non- wsadmin, need to support the ability to capture a log of the activity performed when you run the script.

 

Overview

In order to set up your appserver environment, perform multiple tasks. For example, the following non-wsadmin scripts: create the persistent session database, install the JDBC driver for the database on the system, set up MQ and create MQ queues on the system, or place PDF files in specific locations that are required as part of the application structure. You must also run the following wsadmin scripts as part of the environment setup: create the cluster definition, create data sources and JMS object configuration, or install one or more EAR files that comprise the hosted software on WebSphere Application Server. Each of the scripts, wsadmin and non- wsadmin, need to support the ability to capture a log of the activity performed when you run the script. All of the logs from the scripts are written in a specific directory that archives each time you create an environment. Each time you set up an environment, the overall process is considered a job and each job has an associated identifier. The identifier is a string that includes the date, environment name, machine name, operator, and approval code as indicated by company policy. To examine the logs at a later time, after the environment provisioning is complete, and verify that all of the log files for the wsadmin and non-wsadmin scripts reflect the actual output of the script that you ran for a specific job, and that no other logs are mixed in with the ones from that job, perform the following steps:

 

Procedure

  1. Start the wsadmin tool using the –jobid string, –appendTrace string, or the -tracefile string option. For more information about these options, see the Wsadmin tool article. For more information about starting the wsadmin tool, see the Start the wsadmin scripting client article. Use the -tracefile option to name the logs based on the activity performed by the script that you want to run and to locate the log files in the specific directory for the job. Uses the -appendtrade true option to append to an existing log file, if one already exists. Use the -jobid option to embed an identifier within the log file so that you can validate that all of the logs were the result of the same specific provisioning activity and not some other job.

    You can change the name and location of a file. Modifying the contents of the log file can prove difficult. Also, different log files can have the same job ID and each log file needs a unique name. So the -jobid option provides an important audit and correlation function that the -tracefile option cannot provide.

  2. Examine the log file for the job ID specified. Use the log files to audit or correlate the wsadmin tool.

 

Example

The following example outputs to the log of the wsadmin tool when you use th -jobid string parameter:

[5/16/05 15:45:49:449 CDT] 0000000a AbstractShell A   JobID= scriptTest1



Use scripting (wsadmin)
Application client functions
Enabling trace on client and standalone applications
Start the wsadmin scripting client
Running the wsadmin tool remotely in a Java 2 Platform, Standard Edition environment