Automating the application deployment is something to consider if it is done more than one time. Successful automation will provide an error free and consistent application deployment approach. Most of the application deployment not only involves installing the application itself, but it also needs to create other WebSphere objects, configure the Web servers, file systems and others. These tasks can be automated using shell scripting depending on the operating systems, Java Common Language (JACL) and Jythons.
Getting started with wsadmin scripting
The WebSphere Application Server
wsadmin.sh tool provides the ability to run scripts. The
wsadmin tool supports a full range of product administrative activities.
The following figure illustrates the major components involved in a wsadmin scripting solution:
The wsadmin tool supports two scripting languages: Jacl and Jython. Five objects are available when you use scripts:
AdminControl: Use to run operational commands.
AdminConfig: Use to run configurational commands to create or modify WebSphere Application Server configurational elements.
AdminApp: Use to administer applications.
AdminTask: Use to run administrative commands.
Help: Use to obtain general help.
The scripts use these objects to communicate with MBeans that run in WebSphere Application Server processes. MBeans are Java objects that represent Java Management Extensions (JMX) resources. JMX is an optional package addition to Java 2 Platform Standard Edition (J2SE). JMX is a technology that provides a simple and standard way to manage Java objects.
Important: Some wsadmin scripts, including the AdminApp install, AdminApp update, and some AdminTask commands, require that
the user ID under which the server is running must have read permission to the files that are created by the user that is
running wsadmin scripting. For example, if the application server is running under
user1, but you are running
wsadmin scripting under
user2, you might encounter exceptions involving a temporary directory. When
user2 runs wsadmin scripting to deploy an application, a temporary directory for the enterprise application
archive (EAR) file is created. However, when the application server attempts to read and unzip the EAR file as
user1, the process fails. It is not recommended that you set the umask value of the user that is running
wsadmin scripting to 022 or 023 to work around this issue. This approach makes all of the files that are created by the
user readable by other users. To resolve this issue, consider the following approaches based on your administrative policies:
Run wsadmin scripting with the same user ID as the user that runs the deployment manager or application server. A root user can switch the user ID to complete these actions.
Set the group ID of the user that is running the deployment manager or application server to be the same group ID as the user that is running wsadmin scripting. Also, set the umask value of the user that is running the wsadmin scripting to be at least a umask 027 value so that files that are created by the wsadmin scripting can be read by members of the group.
Run wsadmin scripting from a different machine. This approach forces files to be transferred and bypasses the file copy permission issue.
wsadmin.sh command file resides in the
bin directory of every profile. Start
wsadmin from a command prompt with the command:
Note that the wsadmin command also exists in the bin directory of the
directory. If you start wsadmin from this location, you must be careful to specify
the profile to work with in the command. If you do not specify the profile (or forget
to specify it), the default profile will be chosen.
Example below illustrates how to start wsadmin. In this example, the wsadmin command is used to
connect to the job manager. It is issued from the
bin directory of the job manager
profile, so the profile does not need to be specified. The
-lang argument indicates Jython will be
used (Jacl is the default):
/opt/IBM/WebSphere/AppServer/profiles/jmgr40/bin>wsadmin.sh -lang jython WASX7209I: Connected to process "jobmgr" on node jmgr40node using SOAP connector ; The type of process is: JobManager WASX7031I: For help, enter: "print Help.help()" wsadmin>
wsadmin.sh [ -h(elp) ] [ -? ] [ -c <command> ] [ -p <properties_file_name>] [ -profile <profile_script_name>] [ -f <script_file_name>] [ -javaoption java_option] [ -lang language] [ -wsadmin_classpath class path] [ -profileName profile] [ -conntype SOAP [-host host_name] [-port port_number] [-user userid] [-password password] | RMI [-host host_name] [-port port_number] [-user userid] [-password password] | JSR160RMI [-host host_name] [-port port_number] [-user userid] [-password password] | IPC [-ipchost host_name] [-port port_number] [-user userid] [-password password] | NONE ] [ -jobid <jobid_string>] [ -tracefile <trace_file>] [ -appendtrace <true/false>] [ script parameters ]
Command and script invocation
wsadmin.sh commands can be invoked in three different ways
Note: For simplicity, the examples assume that:
wsadmin.sh is executed from the
directory, so it is not necessary to specify the profile name, host, and port.
Administrative security is disabled. In reality, you will need to specify the username and password when you invoke wsadmin.
Invoking a single command (-c)
-c option is used to execute a single command using
wsadmin. In the example below, we use the
AdminControl object to
query the node name of the WebSphere server process:
/opt/IBM/WebSphere/AppServer/profiles/jmgr40/bin>wsadmin.sh -lang jython -c AdminControl.getNode() WASX7209I: Connected to process "jobmgr" on node jmgr40node using SOAP connector ; The type of process is: JobManager 'jmgr40node'
Running script files (-f)
-f option is used to execute a script file. Example below shows a
two-line Jython script named
myScript.py. The script has a
extension to reflect the Jython language syntax of the script. The extension plays
no significance in wsadmin; the
-lang parameter is used to determine the language used. If
the property setting is not correct, use the
-lang option to identify the
scripting language, because the default is Jacl.
print "This is an example Jython script" print ""+ AdminControl.getNode()+""
Running a Jython script in wsadmin:
/opt/IBM/WebSphere/AppServer/profiles/jmgr40/bin>wsadmin.sh -f myScript.py -lang jython WASX7209I: Connected to process "dmgr" on node dmgr40node using SOAP connector; The type of process is: DeploymentManager This is an example Jython script dmgr40node
Invoking commands interactively
The command execution environment can be run in interactive mode, so you can
invoke multiple commands without having the overhead of starting and stopping
the wsadmin environment for every single command. Run the
command without the command (
-c) or script file (
options to start the interactive command execution environment, as shown in the
/opt/IBM/WebSphere/AppServer/profiles/jmgr40/bin>wsadmin.sh -lang jython WASX7209I: Connected to process "dmgr" on node dmgr40node using SOAP connector; The type of process is: DeploymentManager WASX7031I: For help, enter: "print Help.help()" wsadmin>
wsadmin> prompt, the WebSphere administrative objects and
built-in language objects can be invoked, as shown in example below. Simply type the
commands at the
wsadmin>AdminControl.getNode() 'dmgr40node' wsadmin>
End the interactive execution environment by typing
quit and pressing the