Previous | Home | Next


Managing WebSphere using script libraries

We can use script libraries to perform a higher level of wsadmin functions than when using a single wsadmin command. Only a single line from a library function is needed to perform complex functions. Each script is written in Jython and is often referred to as the Jython script. The script libraries are categorized into six types, and the types are subdivided, as listed in Table 9-2. Python script files are supplied for each Jython class file. The Python files can be read as text files.


Invoking script libraries

The script libraries are located in...

These libraries are loaded when wsadmin starts and are readily available from wsadmin prompt or to be used from the customized scripts. We can invoke the scripts in interactive mode or script mode.

Interactive mode is suitable for simple tasks and testing. Using this mode allows you to get the results directly. To invoke a script interactively, start a wsadmin session, and enter the script name, procedure, and arguments at the wsadmin> prompt |

Using the Jython scripts in interactive mode 

$ wsadmin -lang jython 
WASX7209I: Connected to process "dmgr" on node DmgrNode02 using SOAP connector; The type of process is: DeploymentManager
WASX7031I: For help, enter: "print Help.help()"
wsadmin>AdminServerManagement.checkIfServerExists("Node01", "Member01") 
AdminServerManagement: Check if server exists
Node name: Node01
Server name: Member01
Usage: AdminServerManagement.checkIfServerExists("Node01", "Member01") 'true'
wsadmin>
Script file mode (-f)

Using a script file with wsadmin is useful when to have daily tasks performed automatically or if you need to manage multiple servers. To run in script mode, select the script libraries to use and merge them into our own script file. Save the custom script as a Python file, and run it from the command line.

Python file containing two script library commands.

The script for test.py 

# Writting by Jython
# Script file name : test.py

AdminServerManagement.checkIfServerExists("Node01", "Amember21")
AdminServerManagement.createApplicationServer("Node01", "Amember21")

Using the invoke test.py script 

C:\WebSphereV8.5\AppServer\bin$ 
C:\WebSphereV8.5\AppServer\bin$ wsadmin.bat -lang jython -f C:\temp\test.py


Customizing scripts

Customizing scripts is an advanced use of the script mode. We can add customized code written in Python or Jython to your script file (the one that calls the script libraries).

Do not modify the script libraries. If you need to customize the scripts, we can copy parts of the library code to other files and modify the copied code to improve it or to better suit your needs.

When customizing a script:

  1. Run each Jython script in interactive mode and then verify the syntax and the result.

  2. Create the script file that will call the script libraries by combining all Jython scripts. Verify the results are as you expect.

  3. Add your additional wsadmin commands, written in Python and then verify the customized script does the work that you intended.


Displaying help for script libraries

We can use the AdminLibHelp script to display each script within a script library. For example, the following command displays each script in the AdminApplication script library:

We can use the help script to display detailed descriptions, arguments, and usage information for a specific script. For example, the following command displays detailed script information for the listApplications script in the AdminApplication script library: 

print AdminApplication.help('listApplications')

Sample code for displaying help information for the createApplicationServer procedure in the AdminServerManagement script.

Help information for a procedure in createApplicationServer 

wsadmin>print AdminServerManagement.help('createApplicationServer')
WASL2004I: Procedure: createApplicationServer

 Arguments: nodeName, serverName, (Optional) templateName

 Description: Create a new application server

 Usage: AdminServerManagement.createApplicationServer( nodeName,
serverName, templateName)
wsadmin>


Application script library

The application scripts provide a set of procedures to manage and configure enterprise applications and business level applications. We can use these scripts individually, or we can combine them in a custom script file to automate application installation, configuration, and management tasks.

The library located in...

...contains the following scripts:


AdminApplication script

The AdminApplication script contains procedures that allow you to manage enterprise applications. The AdminApplication script uses the following syntax:

The AdminApplication script provides procedures to:

Open the AdminApplication script from INSTALL_ROOT/scriptlibraries/application/V70 to find the complete list of procedures for performing application management tasks.

Example: Installing an application

We can use multiple procedures to install applications. When preparing to install an application, determine the options that you need, and choose the procedure accordingly.

The most basic procedure is installAppwithNodeAndServerOptions. If the installation is successful, the installed application successfully message returns.

This procedure uses the following syntax: 

AdminApplication.installAppWithNodeAndServerOptions(appname, app_location,
nodename, app_server_Name)

Installing the application script library 

wsadmin>AdminApplication.installAppWithNodeAndServerOptions("IBMUTC", "/IBMUTC.ear", "Node01", "Member01")

AdminApplication: Install application with -node and -server options
Application name: IBMUTC
Ear file to deploy: C:/IBMUTC.ear
Node name: Node01
Server name: Member01

Usage: AdminApplication.installAppWithNodeAndServerOptions("IBMUTC", "/IBMUTC.ear", "Node01", "Member01")

WASX7327I: Contents of was.policy file:grant codeBase "file:${application}" {permission java.security.AllPermission;};
ADMA5016I: Installation of IBMUTC started.
ADMA5058I: Application and module versions are validated with versions of deploy ment targets.  
CWSAD0040I: The application IBMUTC is configured in the Application Server repository.
ADMA5113I: Activation plan created successfully.
ADMA5011I: The cleanup of the temp directory for application IBMUTC is complete.
ADMA5013I: Application IBMUTC installed successfully.
OK: installAppWithNodeAndServerOptions('IBMUTC', '/IBMUTC.ear', 'Node01', 'Member01', 'false'):

Example: Starting an application

Multiple procedures are also available to start an application. To start the application, choose the most suitable script.

The startApplicationSingleServer procedure starts a single application on a single application server. This procedure uses the following syntax:


Starting an application script library

wsadmin>AdminApplication.startApplicationOnSingleServer("IBMUTC","Node01","Member01")
AdminApplication: Start an application on a single server
Application name: IBMUTC
Node name: Node01
Server name: Member01
Usage: AdminApplication.startApplicationOnSingleServer("IBMUTC", "Node01","Member01")
OK: startApplicationOnSingleServer('IBMUTC', 'Node01', 'Member01', 'false')
:1


Resource script library

The Resource script library provides a set of scripts to manage WebSphere resources. The library provides script functions for J2C resources, JDBC providers, and JMS resources at the server scope. If you need to configure resources at the cell, node, or cluster level, we can customize the scripts for this purpose.

The script library is located in...

It contains the following scripts:

AdminJ2C script Provides procedures to configure and query J2C resources.
AdminJDBC script Provides procedures to configure and query JDBC resources.
AdminJMS script Provides procedures to configure and query JMSresources.
AdminResources script Provides procedures to configure mail, resource environment settings, URL provider settings and additional JEE resources

Open the Resource scripts from INSTALL_ROOT/scriptlibraries/resources to find the complete list of procedures for managing WebSphere resources

Example: Listing JDBC resources

We can use the listDataSources and listJDBCProviders procedures of the AdminJDBC script to display a list of configuration IDs for the JDBC providers and data sources in the environment.

The syntax to use each procedure is:

List of JDBC resources 

wsadmin>AdminJDBC.listDataSources("PLANTSDB")

AdminJDBC: listDataSources
Optional parameter:
DataSource name: PLANTSDB

Usage: AdminJDBC.listDataSources("PLANTSDB")

['PLANTSDB(cells/Cell02/nodes/Node01/servers/server1|resources.xml#DataSource_ 1183122165968)']
wsadmin>
wsadmin>AdminJDBC.listJDBCProviders("Derby JDBC Provider")

AdminJDBC: listJDBCProviders
Optional parameter:
JDBC provider name: Derby JDBC Provider Usage: AdminJDBC.listJDBCProvider("Derby JDBC Provider")

['"Derby JDBC Provider(cells/Cell02/nodes/Node01/servers/server1|resources.xml#JDBCProvider_1183122153343)"']

Example: Creating a J2C connection factory

The createJ2CConnectionFactory procedure in the AdminJ2C script creates a new J2C connection factory in the environment. The result is the configuration ID of the new J2C connection factory.

The arguments are the resource adapter, connection factory name, the connection factory interface, and the JNDI name arguments. This procedure uses the following syntax:

The createJ2CConnectionFactory procedure

Security script library

The security script library provides a script to manage the security. This library is located in the INSTALL_ROOT/scriptlibraries/security/V70 directory.

The AdminAuthorizations script provides procedures to:

Open the AdminAuthorizations script from INSTALL_ROOT/scriptlibraries/security/V70 to find the complete list of procedures for managing WebSphere security.

Example: Listing the authorization groups

The listAuthorizationGroups procedure displays each authorization group in the security configuration. This script does not require arguments.

Listing authorization groups 

wsadmin>AdminAuthorizations.listAuthorizationGroups() 

AdminAuthorizations: List authorization groups 

Usage: AdminAuthorizations.listAuthorizationGroups() ['sec_group1']


Server script library

The server script library provides a set of scripts and their procedures to manage the server and the cluster component.

This library is located in...

The AdminServerManagement script provides procedures to:

The AdminClusterManagement script provides procedures to:

Open the Server scripts from INSTALL_ROOT/scriptlibraries/servers/V70 to find the complete list of procedures for managing server and cluster components in WebSphere.


Example: Creating an application server

The CreateApplicationServer procedure of the AdminServerManagement script creates a new application server. The script requires the node to be running. This procedure uses the following syntax:

For example...


Example: Starting an application server

The StartAllServers procedure of the AdminServerManagement script starts all application servers on a node. StartSingleServer starts one server. These procedures use the following syntax:


Starting the application server using a single script library

wsadmin>AdminServerManagement.startAllServers("Node01")

 AdminServerManagement: Start all servers
Node name: Node01
Usage: AdminServerManagement.startAllServers("Node01")


Start server: Member01
Start server: server1
OK: startAllServers('Node01', 'false'):1

wsadmin>AdminServerManagement.startSingleServer("Node01", "Member01")

 AdminServerManagement: Start single server
Node name: Node01
Server name: Member01
Usage: AdminServerManagement.startSingleServer("Node01", "Member01")

Start server: Member01
OK: startSingleServer('Node01', 'Member01', 'false'):1


Example: Stopping application servers

The StopAllServers procedure stops all application servers on a node. The StopSingleServer stops one server. These procedures use the following syntax:

Stopping the application server using a single script library 

wsadmin>AdminServerManagement.stopAllServers("Node01")
AdminServerManagement: Stop all servers

 Node name: Node01
Usage: AdminServerManagement.stopAllServers("Node01")

Stop server: Member01
WASX7337I: Invoked stop for server "Member01" Waiting for stop completion.
Stop server: server1
WASX7337I: Invoked stop for server "server1" Waiting for stop completion.
OK: stopAllServers('Node01', 'false'):1

wsadmin>AdminServerManagement.stopSingleServer("Node01", "Member01")

 AdminServerManagement: Stop single server
Node name: Node01
Server name: Member01
Usage: AdminServerManagement.stopSingleServer("Node01", "Member01")

Stop server: Member01
WASX7337I: Invoked stop for server "Member01" Waiting for stop completion.
OK: stopSingleServer('Node01', 'Member01', 'false'):1


System management script library

The system management script library provides a set of scripts that manage nodes and node groups. This library is located in...

It contains scripts to:

Open the Server scripts from INSTALL_ROOT/scriptlibraries/system/V70 to find the complete list of procedures for managing nodes and node groups in WebSphere.


Example: Querying node group members

The listNodeGroupMembers procedure lists the name of each node configured within a specific node group. This procedure uses the following syntax:

Listing node group members using the script library 

wsadmin>AdminNodeGroupManagement.listNodeGroupMembers("DefaultNodeGroup")

 AdminNodeGroupManagement: List nodes for a given node group
Optional parameter:
Node group name: DefaultNodeGroup
Usage: AdminNodeGroupManagement.listNodeGroupMembers("DefaultNodeGroup")

['DmgrNode02', 'Node01']


Example: Synchronizing a node

The synActiveNodes and syncNode procedures propagate a configuration change. These commands use the following syntax:

Synchronizing the node using the script library 

wsadmin>AdminNodeManagement.syncNode("Node01")

 AdminNodeManagement: syncNode
nodeName: Node01
Usage: AdminNodeManagement.syncNode("Node01")

true
1


Applying performance tuning

Pre-defined performance tuning templates can be applied to an application server or cluster using a python-based tuning script, applyPerfTuning.py.

The script is present in INSTALL_ROOT/scriptlibraries/perfTuning/V70 along with three predefined templates: default, peak, and development.