Wlshell is a tool designed specifically for WebLogic administrators. It combines the flexibility of a scripting language with the full control provided by the JMX interface. It is, therefore, a natural environment for the systems administrator. The units of work of the JMX specification - the Management Beans, or MBeans - are presented in wlshell in the familiar form of the file system and they look like files organized into directories and drive units. This user-friendly environment makes it easy to write scripts to automate daily administrative WebLogic tasks.

Administrative Tasks
Since the beginning of computing, automation has been one of the driving forces of innovation. A couple of examples are the adding machine developed by Blaise Pascal and the punch-card tabulator for the U.S. Census built by Herman Hollerith.

Today, and in a more modest scenario, BEA WebLogic administrators have to face repetitive tasks similar to those just described in the sense that they are candidates for automation. These administrative tasks can be classified in two categories: configuration and monitoring.

A typical configuration task is the deployment of a new application on production servers. In order to deploy the application, it might be necessary to create, configure, and target services this application could rely on, like JDBC connection pools, data sources, JMS messaging servers, and JMS message queues, to name some resources. If the production system contains several WebLogic servers and domains, then the process could be repeated several times, maybe with some differences in parameters like server name and address. Automating this task will produce clear benefits over performing the same task manually using the administration console: the WebLogic administrator will be more productive by doing more in less time, and the possibility of making configuration mistakes will be minimized. In some organizations there are specific and strict regulations about how to roll out applications. In these cases, to automate is more than a nice-to-have practice, it is enforced by law. This is, for example, the case of some companies in the financial and pharmaceutical sectors. In these cases, every application deployment must be performed through an automated process that's documented, repeatable, and auditable.

Another task frequently performed daily by an administrator is supervising the status of servers and services. An administrator might be interested in monitoring the servers in a domain to see if they are active and to check the utilization level. In the case of services, some interesting metrics are the current database connections and the status of the JMS servers.

Administration Using Scripts
Traditionally, scripting languages are the tool of choice to automate administrative tasks, like the UNIX shell. Some of the more radical system administrators say "real administrators don't click." This is a strong statement but it might be telling us that graphical-based tools have some limitations when it comes to task automation. Graphical tools might also lack the level of granularity a professional administrator demands for advanced custom control.

The JMX specification (Java Management eXtensions), on the other hand, provides the right level of detail and control over the systems, but it provides a programmatic interface, a Java API. Experience also tells us "real administrators don't compile code," paraphrasing the previous statement. In reality this means that the power and level of detail of JMX is not directly available to administrators, who aren't necessarily developers. The programming interface lacks the flexibility, dynamism, and conciseness of an interpreted environment like that provided by scripting languages. Is there any way to reconcile both terms? Yes, there are several alternatives. In the remainder of the article, I'll analyze one of them, wlshell, and I'll look at some examples of how to automate some typical administrative tasks.

Creating Services
In the first example I'll create, configure, and start three WebLogic servers. I'll also create three JMS messaging servers, with three message queues each, and deploy the JMS servers on the WebLogic servers.

The first three lines of Listing 1 define the variables that allow the shortening of commands in the rest of the script. The first for loop creates three WebLogic servers, using a combination of the name and the index to produce servers with the names "s1", "s2" and "s3". The listen port is also configured based on the index variable, creating the integer values "7101", "7201", and "7301". wlshell supports two syntaxes for variables, $var and ${var}. The first one is more succinct and is good for interactive typing. The second notation should be used to clearly mark the end of the variable name and avoid any possible mistakes. The last line in the loop starts the server, which assumes the Node Manager is already up and running.

The next loop creates three JMS servers and three message queues for each JMS server using a nested for loop. The "addTarget" MBean operation is used at the end of the loop to target the server to the corresponding WebLogic server.

Finally, the configuration is explicitly persisted on the config.xml file, the default configuration repository. This script can be saved on a file to be executed later in batch mode with wlshell with the "read" command or as a start parameter with the "-f" flag, as shown here.

wlsh -f listing1.wlsh

read listing1.wlsh

Every BEA WebLogic administrator will probably understand immediately the benefits of using a script like this, especially compared to making configuration changes manually with the Web-based console or writing a Java program that uses JMX. The script presented above is relatively easy to read and understand at a first glance, prevents unintended errors, and saves time that can be used to work on more creative tasks.

Offline Configuration
Another new feature of wlshell version 2 is its ability to configure a WebLogic domain when the administration server is not running. This new characteristic creates new and exciting possibilities. We can now configure a domain in offline mode, very much like in the online case, just by using the "connect" command with the name of the "config.xml" file. In this case, the protocol for the connection has the keyword "file" to indicate that it is an offline type connection. We also need to check that the server is not running, so there is only one process making changes to the file.

In offline mode configuration, wlshell reads the config.xml file and presents a directory and file structure very similar to the online mode. All the commands available in the online connection are also available offline, so it is possible to navigate, create, set up, and remove servers, services, and applications. Listing 2 is an example of server configuration to increase the output information displayed on the console.

Once the config.xml file is modified, the administration server can be started with the new configuration. Changes made through wlshell on the config.xml are consistent with the document structure; therefore, the file is always valid. Offline mode is also useful for prepackaging a domain configuration without an administration server, and then distributing the configured package to another environment (testing, production, etc.).

Security Configuration
An important part of systems administration is security, specifically the management of users and groups. BEA WebLogic Security is completely managed through JMX MBeans, and as a result, totally available through wlshell, where administrators can write security management scripts. Within the default settings, the security MBeans are registered under the "Security" domain, without specifying any particular type. wlshell is capable of handling these MBeans with no type and gathers them under a directory named "typeless". Figure 1 shows the wlshell Explorer displaying the Security MBeans. It displays the attributes and operations of the "myrealmDefaultAuthenticator" Security MBean on the right pane. The authenticator MBean is responsible for user authentication and provides operations to manage users and groups. Using these methods, administrators can write scripts to create users in batch mode, assign users to groups, and change the user password. The following code snippet shows how to use the "createUser"operation to create a new user.

 

Security:
cd /typeless/myrealmDefaultAuthenticator
invoke createUser pgomez password "WebLogic Account for Paco Gomez"

Monitoring
WebLogic Runtime MBeans provide a detailed view of the different subsystems of the application server. wlshell makes them easier to access. The "get -r <interval> attribute(s)" command iteratively displays the value of one or more MBean attributes. Sometimes it could be necessary to display information based on the value of a particular MBean attribute or a particular condition. In those cases it might be necessary to write a small script to customize the output. Listing 3 illustrates this point. The script is flexible enough to print the state of the servers configured in the domain without knowing in advance the name or number of them.

The script generates the following output for a particular domain configuration:

Mon Nov 10 21:59:47 GMT-06:00 2003
s1 7101 RUNNING 5899744
s2 7201 not running n/a
s3 7301 RUNNING 5682584

Summary
Some automation examples have been presented in this article. They illustrate how to write wlshell scripts to automate administrative tasks for configuration and monitoring. This approach provides clear advantages over other methods, improving productivity and legibility, and reducing the chances of committing configuration mistakes. You can find more administrative scripts at the wlshell home page.

References