Scripted WAS Installations 101
So, to get started with your first script, let’s start with a common one. That is installing an application, and removing an application. I recommend that you start writing your script as verbose as you can. Don’t worry about ‘hard coded’ values, you can take care of those later. Let’s say you want to install an application (any Java app, not just HATS). This will require two script files. One is the Jython script, the other is a Windows batch file to kick it off (or shell script if your’re on Unix/Linux). Here are the contents of the Jython script (named Install.py):
AdminApp.install(‘HATS61.ear’, [‘-verbose’, ‘-appname’, ‘CustomerServiceApp’, ‘-createMBeansForResources’, ‘-usedefaultbindings’, ‘-noprocessEmbeddedConfig’, ‘-preCompileJSPs’, ‘-server’, ‘server1’, ‘-MapModulesToServers’,[[‘CustomerServiceApp’, “myHatsApp.war,WEB-INF/web.xml”,
“WebSphere:cell=MyCell,node=MyNode,server=server1”
]]])
This is as simple as it gets. Notice the values in green? All of those we will eventually replace with variables so that we can generalize the script and reuse it for other applications. The options that I have included are:
-verbose: This shows all the steps in the console (the SystemOut.log file) as the application is installed. Once your script is verified as working, this option is not really needed.
–preCompileJSPs : this precompiles all HATS transformations so that the application performs as fast for the first person as it does for the last person.
–createMBeansForResources: this is by default true and does not need to be added, but I add it for clarity. An MBean is a Management bean. It is what allows WAS to communicate with the application to discover its status (started, stopped), and its configuration. Without it, you cannot even tell if the application is running or installed, and it will not show up in the Web console.
–noprocessEmbeddedConfig:This option forces the installer to ignore everthing in the extended deployment configuration (seen as the ‘Deployment’ tab in the EAR file configuration within RAD or the WAS Server Tooklit). This configuration is typically written by developers. In a live environment, the SysAdmin should control the entire deployment configuration which includes mapping security roles to users. This is NOT somthing that a developer should explicity control, even if they are the same.
-usedefaultbindings:This will map the server to the default virtual hosts and ports. Again a standard default that has been explicitly set.
–MapModulesToServers: Here we map the application specifically to a WebSphere App Server. This could map to multiple servers or to clusters if need be. The server name that you see listed is the explicit id of the server. Also, this is an array of servers, even though it is listed as just one. There are other ways of getting the server id’s and creating a list of the servers to deploy to. I am not mapping to Web servers in this step. I can do that later.
Now, let’s look at the contents of the batch file:
echo Deploying application to Windows environment
CD C:UserskennyDocumentsProjectsLab
call C:IBMSDP70runtimesbase_v61profilesAppSrv01binwsadmin -conntype SOAP -host localhost -f C:UserskennyworkspacesLabsscriptsInstall.py
pause
The only real thing we are doing in the batch file is changing the working directory to where the python (jython) script is and executing the wsadmin.bat file from our profiles. Your actual directory structure will be very different. Just remember that I am working out of my RAD 7.0 environment, and navigating to a folder in my documents directory on Vista. Once you have this, if you know the values will never change, then you have your deployment scripts! However, in the real world, you will probably want to have deployment scripts for various applications, or at least, a script for test, development and production environments.
The next thing we could do is to extrapolate the variables and call those from the command line (or batch file as appropriate). This will let us reuse our Jython script for other applications.
def install():
AdminApp.install(hatsapp, [‘-verbose’, ‘-appname’, applicationName, ‘-createMBeansForResources’, ‘-usedefaultbindings’, ‘-noprocessEmbeddedConfig’, ‘-preCompileJSPs’, ‘-server’, server, ‘-MapModulesToServers’,[[applicationName, “myHatsApp.war,WEB-INF/web.xml”,
serverlist
]]])
hatsapp=sys.argv[0]
applicationName=sys.argv[1]
server=sys.argv[2]
serverlist=sys.argv[3]
print “Installing My Application.”
install
Now, your batch file will look something like this:
echo Deploying application to Windows environment
CD C:UserskennyDocumentsProjectsLab
call C:IBMSDP70runtimesbase_v61profilesAppSrv01binwsadmin -conntype SOAP -host localhost -f C:UserskennyworkspacesLabsscriptsInstall.py C:UserskennyworkspacesLabsmyApp.ear MyApplication server1 [“WebSphere:cell=MyCell,node=MyNode,server=server1”]
pause
I’ve put the options in bold above. This should show you how you can call it but with different options, servernames, etc. If you copy and paste the above jython script, please keep in mind, that I have not indented anyting. Python (and subsequently Jython) is very whitespace sensitive. Every indention has a meaning, and it is used rather than the typical curly braces (like Java) to denote the beginning and end of function calls. Another function (‘def’ as above) that we should consider is the removal of an application. Here is a simple one:
def doRemove(appname):
AdminApp.uninstall(appname)
AdminConfig.save()
print appname + ” successfully removed. “
Now, you could add another argument to the script so that you can specify ‘install’ or ‘remove’ as one of the now 5 arguments to the script. That way you can still use the same install.py script, but now it will install and remove an application. As you can see from above, removal is much easier than installation.
As you can tell, the power of scripting is substantial. If you are using a GUI, you are chained to it, and have many options that can introduce user error. The scripts above are exact. They require a trigger to exectute, but nothing more. That trigger could be a user double clicking on a batch file, or a Windows timed task, or even something more advanced like a Rational BuildForge agent kicking off the install after a developer has checked in their source code to version control. The latter requires more work to setup, but is powerful in the sense that this is now all automated. Automation of error-prone tasks improves productivity and quality.
That is all for this segment. I will probably post more on this topic later. If this has been helpful to you, then please post a comment so that I know to write more (I hope it is helpful).
