Network Deployment (Distributed operating systems), v8.0 > Scripting the application serving environment (wsadmin) > Use the Administration Thin Client
Auditing invocations of wsadmin.sh using wsadmin.sh
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 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.
To set up the application server environment, perform multiple tasks. For example, run 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. We 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 the product. 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
- Start wsadmin.sh using the –jobid string, –appendTrace string, or -tracefile string option.
Use the -tracefile option to name the logs based on the activity performed by the script to run and to locate the log files in the specific directory for the job.
Use 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.
We 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.
For more information about these options, see wsadmin.sh topic. For more information about starting wsadmin.sh, see the Starting the wsadmin scripting client topic.
- Examine the log file for the job ID specified. Use the log files to audit or correlate wsadmin.sh.
Example
The following example outputs to the log of the wsadmin tool when you use the -jobid string parameter:
[5/16/05 15:45:49:449 CDT] 0000000a AbstractShell A JobID= scriptTest1
Use wsadmin scripting
Enable trace on client and stand-alone applications
Run wsadmin.sh remotely in a Java 2 Platform, Standard Edition environment
Related
wsadmin scripting tool