Oracle WebLogic server ships with a set of tools for server administration and management. In the second chapter, we have learnt how to use the browser-based Administration console, which remains the first choice for WLS administrator. In this chapter we will learn about the WebLogic Scripting Tool (WLST) which is a command-line scripting environment that you can use to create, manage and monitor Oracle WebLogic Server domains.
Oracle WebLogicScripting Tool (WLST) is an advanced management tool, based on the Java scripting interpreter, Jython. In addition to supporting standard Jython features, such as local variables, conditional variables and flow control statements, WLST provides a set of scripting functions (commands) that are specific to WebLogic Server. You can even extend the WLST to suit your needs by following the Jython language syntax.
Jython is an implementation of the Python language in Java. It compiles Python code into Java bytecode and uses the JVM for this purpose. WLST uses Jython to access various objects within the WebLogic Server domain. These objects are called MBeans (Managed beans), that is, Java objects that represent resources to be managed.
WLST can be used in several modes; we can however group them in the following main three categories:
- Offline: Mostly used to create new domains like the configuration domain wizard
- Online: Used to perform online administration tasks just like the Administration console
- Embedded: Invoked directly from Java code
The WebLogic scripting tool can be located into the $MW_HOME/wlserver/common/bin folder of your distribution. It can be launched using the wlst command as shown here:
Oracle recommends using the offline mode to create domain templates, new domains based on existing templates, or extend an existing, inactive domain. It is discouraged to use this mode on a running domain of server since changes can be overwritten by other administration tools like the Web console or the WLST on line shell.
Running WLST in offline mode can be achieved with few little steps: at first set your environment by running the setWLSEnv script (the following example assumes you are running a Windows Machine):
Then you can launch your scripts in offline mode by passing them as argument to WLST:
Alternatively, you can just connect to the WLST by launching the wlst command (as shown in the former picture), and use the execfile command passing as parameter the script to execute:
Here is a sample WLST script which can be used to create a new WLS domain:
In this script, we are opening an existing domain template for domain creation, using the readTemplate command. Please note that, once you open a domain template, WLST is placed into the configuration bean hierarchy for that domain template, and the prompt is updated to reflect the current location in the configuration hierarchy.
You can traverse the hierarchical structure of configuration beans using commands such as cd, ls, and pwd in a similar way that you would navigate a file system in a UNIX or Windows command shell.
In this example, we are navigating first to the “Servers/AdminServer” location where we perform some administrative tasks (creation of Administration server); then we are heading for “Security/base_domain/User/WebLogic” bean hierarchy where we set some basic security settings.
If you specify a backslash character (\) in a string (e.g. Windows systems), for example when specifying a file pathname, you should precede the quoted string by “r” to instruct WLST to interpret the string in its raw form and ensure that the backslash is taken literally. This format represents standard Jython syntax.
Online WLST provides simplified access to Managed Beans (MBeans) which are Java objects that provide a management interface for an underlying resource that you can manage through JMX. Since WLST is a JMX client, all the tasks you can do using WLST online, can also be done programmatically using JMX. Start by connecting to your running Administration server:
You can also use WLST to connect to Managed Servers, but you cannot modify configuration data from Managed Servers; because this should only be done by the Administration Server which is solely responsible for maintaining, updating, and storing the configuration data.
Once you are connected to your WebLogic server instance, you can start navigating and querying MBeans. There are two main paths which can be traversed once you are connected to a WebLogic server instance: Configuration MBeans and RuntimeMBeans.
Configuration MBeans are used to explore the basic server configuration. You can navigate to configuration MBeans by using serverConfig or domainConfig (the latter one if you are connecting through the administration server):
With ls() you can have a look though this MBean structure:
Similar to the configuration information, WebLogic Server Runtime MBeans are arranged in a hierarchical data structure. When connected to an Administration Server, you can access the Runtime MBean hierarchy by entering the serverRuntime or the domainRuntime command.
The serverRuntime command places WLST at the root of the server runtime management objects - ServerRuntimeMBean;
The domainRuntime command places WLST at the root of the domain-wide runtime management objects - DomainRuntimeMBean. (The domain runtime MBean hierarchy exists on the Administration Server only).
Here’s for example how you can check health state information about one application deployed on WebLogic Server:
And now let’s issue a directory listing:
A special variable, named cmo, is set as a pointer to the bean instance you are navigate into. You can use this variable to perform any get, set, or invoke a method on the current bean instance.
Inspecting the values of MBeans is just half of your administrator activities. Within the Administration Server, there is a set of configuration MBeans in a single, editable hierarchy that contains an editable copy of all configuration MBeans in the domain and it is used only as part of the change management process.
The change management process is a controlled procedure for distributing configuration changes in a domain; a change process that loosely resembles a database transaction.
You start the editing process by obtaining a lock on the editable configuration hierarchy to prevent other people from making changes. When you finish making changes, you save and distribute them to all server instances in the domain. When you distribute changes, each server determines whether it can accept the change. If all servers are able to accept the change, they update their working hierarchy of configuration MBeans and the change is completed.
Here’s for example, how you can modify the ‘FileCount’ logging attribute
Activating all your changes may take a while; however the edit lock associated with this edit session is released once the activation is completed.
Notice the usage of thestartEdit command that initiates the editing process. Changes will not be committed to the repository until you enter the save command. The activate command initiates the distribution of the changes and releases the lock; finally notice that you can make additional changes, without re-entering the startEdit command, or undo changes you have made by entering the undo command.
In embedded mode, you instantiate the WLST interpreter in your Java code and use it to run WLST commands and scripts. All WLST commands and variables that you use in interactive and script mode can be also run in embedded mode.
The following example shows how to connect WLST to a running server, create two servers, assign them to a newly created cluster and exit.
As you can see, the embedded mode consists in passing WLST commands as String to the weblogic.management.scripting.utils.WLSTInterpreter class. This kind of mode can be useful for developers that want to spice their application with some administration tasks, although it is discouraged for system administrators as it will be harder to maintain.
WLST can be used as well to manage server life cycle and can be pretty useful, for example, if you have to start/stop a domain consisting in lots of servers. There are basically two modes to manage your servers:
- Using the Node Manager interface
- Without Node Manager (via the Admin Server).
Let’s shortly illustrate both approaches
WLST can connect to a Node Manager that is running on any machine and start one or more WebLogic Server instances on the machine.
A WebLogic domain's Administration Server does not need to be running in order to start servers using this technique.
Start by launching WLST at first:
In case the Node Manager process is not already running, you can log on to the host computer and use WLST to start it:
Next, connect WLST to a Node Manager by entering the nmConnect command:
You can now use the nmStart command to start a server:
Monitor the status of Managed server by entering the nmServerStatus command:
Finally, you can stop the server by entering the nmKill command:
In the latter option, we will use the WLST startServer command to start the Administration Server. Here’s an example:
After WLST starts a server instance, the server runs in a separate process from WLST; exiting WLST does not shut down the server. So, once you have started the administration server, you can simply connect to it and issue commands to control life cycle of servers:
This recipe will show you how to deploy/undeploy applications using WLST online mode.
As an example, we will deploy the sampleApp application located at c:\home\sample and create a default deployment plan for it:
The above command will return a WLSTProgress object. You can then use the progress variable to print the status of the deploy command. For example:
The next command, removes the sampleApp application from all target servers. WLST waits 60,000 ms for the process to complete:
We will complete the WLST section by providing a ready-to-cook recipe for creating a cluster made up of three Managed Servers (serverA, serverB, serverC). The script is self-descriptive and it uses the createCluster command on the root of the MBean hierarchy in order to create the Cluster which will be later assigned to the Managed Servers via the setCluster command: