WebSphere Adminstration: Getting Started with WebSphere Application Server Scripting

If you’re a WebSphere administrator or if you’re trying to automate some tasks around the IBM WebSphere line of products, you’ll inevitably be using WAS scripting (a.k.a. “wsadmin”). For the record, it is also possible to use Java and JMX-based APIs for automation, but it’s is more complex and less documented. So “wsadmin” scripting tool is the primary tool of trade for any WebSphere administrator.

There are several things that you need to do in order to be successful with wsadmin:

* Learn Python. Wsadmin uses Python as a language (JACL was deprecated a long time ago and should not be used) and relies on jython. Jython provides full implementation of Python language “sans some libraries”:http://www.jython.org/docs/library/indexprogress.html. Needless to say that good knowledge of Python is essential for developing wsadmin scripts. Most WebSphere admins have Java background. In my opinion (and speaking from personal experience), knowing Java does more harm than good for a Python developer. Java people usually speak Python “with accent” and have a hard time properly utilizing all python capabilities such as closures, list comprehensions and even modules and packages. It’s no wonder, the two languages are very different. For example, in Java everything is a class and in most cases a class resides in its own file. In Python a module can encompass multiple classes and classes themselves are completely optional. Learning how to properly use modules and classes takes some mental shift.

* Invest in designing your scripts. I’m not even sure if “scripting” is the right word to use in this context. Scripts are usually relatively simple. Wsadmin scripts are anything but. A seemingly simple task of application deployment may require many lines of code if you want to do it right. Unless you’re really trying to do something unsophisticated (e.g., “setting heap size”:/setting-heap-size), you’ll be developing a full-blown python application. Therefore, you’ll need to think about its design. Python has excellent support for modules. You’ll have at least one module in your application. Do not put any logic into the “main” file that you’ll be calling from wsadmin. Instead, define appropriate functions and classes in your modules and call them from the main file.

* Invest in setting up your development environment. Notepad or vi are not going to cut it. Remember, Python lacks compiler, so the only way to find out if your code is even syntactically correct is to execute it. That is, unless you use an IDE, such as “PyDev”:http://pydev.org/. The latest version of PyDev is very good at detecting syntax errors and many other issues, such as uninitialized variables. It also has very decent (for a dynamic language) code completion.
You will also need to setup your wsadmin shell script to supply python path (using -javaoption "-Dpython.path=your_path"). Do not forget to put python libraries (the ones that come with jython) on the python path. I prefer using “thin administration client”:/wsadmin-thin-client as this is more flexible. I also “use 2.2.1 version of jython”:/using-jython-221-with-wsadmin-tool since jython 2.1 that “comes with wsadmin”:/was-70-is-still-on-jython-21 is just too old and misses a lot of important language features.
Another practical piece of advice is to never use “wsadmin -f” to test your scripts. Wsadmin takes eternity to come up, so running it every time you want to run your scripts is simply counterproductive. Instead, load it once and then run your script using Python “execfile” function. Don’t forget to call “reload”:http://docs.python.org/library/functions.html function for all modules that are part of your applications, otherwise you won’t see the changes until your re-start wsadmin.

* Help function is your best friend, so learn how to use it. I’m talking about the “help” function available for all key wsadmin modules (“AdminConfig, AdminControl, etc”:/admincontrol-vs-adminconfig). Wsadmin APIs, in my opinion, are poorly organized and difficult to learn. “Ten thousand options”:http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.soafep.multiplatform.doc/info/ae/ae/rxml_taskoptions.html available for AdminApp.install function is an example of that. Also, “lists of lists” data structures used by AdminTask and AdminApp are truly baffling. In any event, I usually run a separate wsadmin window that I use solely for consulting “help”. This is much faster than searching for the same information in InfoCenter.

* Finally, you will need a testing environment. You can do some development using a standalone WAS installation but eventually you’ll need to test your code against a Network Deployment environment with deployment manager and, ideally, multiple servers and multiple nodes. In other words, your test environment should resemble the target environments where you’re going to run your scripts. There are many things that are impossible to test with just a standalone profile, one such example is “node synchronization”:/how-to-force-node-synchronization.

This post is part of the series on WebSphere Application Server administration. Please subscribe to our blog if you’d like to receive updates.

Note: We offer professional services in the area of WebSphere architecture, implementation and operations. If you’re looking for help with any of these tasks, please let us know.