UrbanCode Deploy: A sample process to install Websphere

I seem to gravitate to WebSphere like a moth to a flame. I just finished co-authoring a couple of CLM Deployment Wiki topics (Configuring enterprise CLM reverse proxies: WebSphere 8.5 ND Proxy & CLM deployment automation for WAS – departmental topology) both with my co-conspirator Indradri Basu. Incidentally Indradri was also my sounding board for Clusters of CLM applications without a GUI.

So I guess it was natural that while figuring out some of UCD’s features, I looked at automating the WebSphere Install process.

Now there are three WebSphere related plugins for UCD:

1) container topicMiddleware Configuration for WebSphere plug-in

2) container topicApplication Deployment for WebSphere plug-in

3) container topicWebSphere Application Server Liberty Profile plug-in

All of the above assume that the WebSphere product is already installed and one or more profiles created.  My goal was to create a simple process that could be used to make the installation of WebSphere repeatable while exploring some of UCD’s features.

So here is the process I came up with. Note that this isn’t complete, doesn’t cover all possible error conditions and isn’t fully parametrized. I do think that it is a decent start and can be easily extended and improved.


Assuming that IBM Installation Manager has already been installed on the target system, an explanation of the steps follows.

a) Check Available Disk Space: This is a step from the System Utility -> System Information plugin that fails if the specified drive/mount point does not have the minimum specified space. If this check does fail the process finishes.

b) imclListPackages: This is a Scripting -> Shell -> Shell step that runs the following command:

imcl listAvailablePackages -repositories ${p:repodir}

The details of “imcl” are in the IBM IM Infocentre. The output of this command is a string identifying the installation packages in an IBMIM repository as specified via the -repositories option. In my case the string happens to be “com.ibm.websphere.BASETRIAL.v85_8.5.0.20120501_1108” . What I didn’t know was how to extract this string and store it for use in a later step as an option to the “imcl -install” command”. Enter guru of gurus Tim Pouyer. I pinged him and he pointed me to an example of how to do this using the concepts in the topic on Post-processing in process steps. I shamelessly modified Tim’s example script and used it to create and populate a new property called “productId” with the product identifier string.

imclListPackagesPropertiesimclListPackagesPostProcc) Move Directory : This is a step from the Utilities -> FileUtils plugin. All it does is grab the existing directory to which Websphere has been installed and move it to a directory with the suffix “.orig”. Now this step can and should be different. It may be that the process should fail if the directory already exists. Or it may be that a manual step is used at this point to force some manual intervention. In my case I put it in there to as a quick fix  because where I had already uninstalled WebSphere but forgotten to remove the directory I had installed to. Remember that this is also an exploratory process design:-)

d) imclInstallWAS: This is where the actual install takes place. Again it is a a Scripting -> Shell -> Shell step that runs the following command:

imcl install ${p:imclListPackages/productId} -repositories ${p:repodir}  -installationDirectory ${p:installdir} -acceptLicense -showVerboseProgress

This simply runs the imcl -install command with the appropriate options. Notice that the productId property that was set in the imclListPackages step is used here.

There are a couple of other properties in the above commands that I set as part of the process configuration so that they can be easily changed:


repodir this is used (as ${p:repodir}) in both the imcl commands to specify the the Installation Manager repository URL

installdir is used (as ${p:installdir}) in the imcl install command as the value for the -installationDirectory option

Finally I set the Default Working Directory  to be the directory where the ibmcl command is to be found, in the Basic Settings of the process configuration.


And that’s it. Once I have a resource created for the target deployment server, I can submit a request for the process specifying the target resource and modifying the  “WAS Installation Manager Repository” and  “WAS installation directory” properties along the way if required:

requestprocessOnce the request has been submitted, I can monitor its progress and dig into detailed logs in case  of failures.


That does the WebSphere install part for me. The next step is to add a simple process that allows creation of WebSphere profiles.

3 thoughts on “UrbanCode Deploy: A sample process to install Websphere”

  1. Hi Freddy,

    This is a great start at getting a WAS environment setup using UrbanCode Deploy. This seems to cover installing WAS for a Base installation. Have you considered what might need to be done to get an ND installation going? Possibly making this process a Component Template process so that it can be shared/re-used by other components to install WAS on multiple systems?

    ND is definitely a different topic as aside from profile creation there would also need to be process steps for federation as well after the profiles are created and started.

    Definitely some good info in here. Keep up the great work!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s