About this plugin

This plugin allows to invoke the wsadmin command of IBM WebSphere Application Server (WAS) 6.0/6.1/7.0 as a build step. It can be used for example to deploy a freshly built application (self-promo: using the RAD Builder Plugin).

This plugin supports:

WAS 6.0 (versions 1.0 to 1.6 successfully tested with WAS 6.0.2.15 – should work with other 6.0.2.x versions)

WAS 6.1 (not yet tested)

WAS 7.0 (version 1.1 to 1.6 successfully tested with Administration Thin Client built from WAS 7.0.0.7 – should work with other 7.0.0.x versions)

User guide

Before adding a WAS build step to a job, the WAS Builder plugin must be configured as follow:

First, one or several WAS installations must be defined in Jenkins' main configuration panel (cf. upper part of the screenshot below). These WAS installations must not necessarily correspond to some running WAS servers: The plugin simply uses their wsadmin command (the one located in the bin folder of the installed product) to connect to remote servers.

Once at least one installation is defined, you need to save the changes and to go back to Jenkins' main configuration panel to be able to define the servers that the jobs will use (lower part of the screenshot above).

Once at least one server is defined, it's possible to add some "IBM WebSphere Application Server 6.x/7.x" build steps to your jobs (cf. screenshot below). Most of wsadmin options can be controlled through the GUI. Take a look at the inline help (the little question marks located on the right of each field) to know more about each feature.

The Run if field doesn't correspond to a wsadmin option. It can be used to dynamically enable/disable a build step for a particular run: If Run if is defined (let's say with the STOP_SERVER value) for a build step, then the build step will be run if and only if:

a build variable with the same name (in our case, STOP_SERVER) is defined and has a value,

or (exclusive) if no build variable with the same name is defined and an environment variable with the same name (still STOP_SERVER in our example) is defined, whether it has a value or nor.

When defining a build step for WAS 6.0, be sure to refer to the inline help to know if you can use it: Some options (job ID, trace file, etc.) are available only for WAS 6.1 or greater.

Check-out this post on IBM developerWorks to get an introduction on how this plugin can be used (thanks Ilko).

The plugin seems to work fine on Windows XP, I just need to do some testing on Linux to see if the "Run if" stuff works fine (which I have a doubt). Once done, I'll release the plugin, maybe at the end of this week.
Anyway, if you want to get it in advance, the source code is available in the SVN repository.

Unknown User (paul.cleary@oracle.com)

I would like to deploy to a remote websphere instance also running Websphere 6.1.0.21.

I setup a WAS installation and WAS server, but I don't see where I configure the step in my Hudson Job. It is a Maven 2 job, can I only add the step in a freestyle project?

Now, the tough question, I need to auto deploy to a remote server, any details on what should be in the Websphere step in my job to do that? I guess I need to Update the application, save everything, and restart the application server.

You're right, the plugin is currently restricted to freestyle projects as I don't have M2 projects to ensure it would work fine with it (I prefer restricting functionalities rather than providing buggy ones).
If you wish, I can pack & send an "unlimited" version of the plugin for you to test so that I can officialy expand the scope of the plugin.

For your last question, I use to do the following to deploy apps on a remote WAS server:

I remotly invoke WAS's EARExpander.sh/.bat command to backup the currently deployed app

The node is stopped if the user wants it (this is the purpose of the Run if field)

The application is undeployed

The updated app is then deployed

The node is started (if the user wants it)

The updated app is started

Stopping/starting the node makes sense only the first time JAAS auth data are created or when the value of the password changes.
Additional point: I always create two jobs to build apps: The first builds and unit-tests the app, the second one does the deployment on WAS.

The plugin uses wsadmin.bat/wsadmin.sh to administer WAS and, normally, version 1.0.1 of the plugin is no more restricted to free style jobs.
To use it directly from a Maven job, you need to install the M2 Extra Steps Plugin. But I would recommend splitting it to another downstream job since, IMO, build and deployment are clearly two different things.

The unix permissions of the WAS installation at our place are set such that I cannot run the wsadmin script without using sudo.
Is there anyway you could run it as:/usr/sudo/sudo /usr/IBM/WAS61/AppServer/bin/wsadmin.sh -conntype SOAP -host ...

Unknown User (jvorpahl)

Romain,

Thanks for building the plug-in. It works great but I'm having a small issue. When a deployment fails, it still says the build is successful. Is there something I can do to pass the value back to Hudson? When I run wsadmin outside of the plugin see that the %ERRORLEVEL% parameter is > 0 (105 to exact) when it exits on error. But the plugin must be preventing Hudson from recognizing the error code of the wsadmin.bat program. I could use the windows batch command build option but the plugin makes everything much easier to setup and read and also the plugin hides the password to the server. That is a huge plus.

We have a doubt as WAS Think Client integration with WAS Server. Our system have a machine with jenkins (with WAS builder plugin) and a lot of remote WAS. The WAS Think client versión is 7.0.0.12 (instaled in Jenkins machine) and we want deploy aplications in WAS servers with other versions like 7.0.0.13, 7.0.0.14. ¿Is this a problem? ¿Have one experience about it?

And the second, in all the WAS we have a security enabled, ¿Could be a problem?

I have a situation where I need the username and password defined at the server level available to use inside of a wsadmin script. This will be used to configure LDAP security. Is there a way that these can be externalized so they are available inside of a admin script and hopefully keep them secure?

In fact this feature has already been implemented in the next version of the plugin. There's a $SERVER entry in the list, which picks the value from the SERVER variable. I'll tell about your comment to the new maintainer of the plugin, Daniel.

I tried putting quotation marks, either single or double, around the path in the main Jenkins configuration. Doesn't work, the configuration complains it's not a folder and the build step won't even start. Is there any other way to make it work despite the spaces?

In our environment, Jenkins and WebSphere are running on the same machine and wsadmin through SOAP etc. isn't set up. Running from the command line, I can simply not specify the -conntype, -host and -port options or use -conntype NONE. The plugin apparently doesn't allow that, I have to specify a connection type and can only choose SOAP, RMI, or JSR160RMI. Can I get NONE in there somehow?

I changed the build to invoke wsadmin via the command line instead. Works, I just need to remember to update it separately if something about the WAS configuration changes later. I haven't worked on any Jenkins plugins before, so I'd rather not spend the time I need to configure my IDE etc. to make the change, even if in the code it's just a small issue.

My WAS is located on my remote windows server and Jenkins is on Linux. I don't understand the part were it says the "Installation directory" the wsadmin file would be located on my remote WAS under the /bin directory... so what exactly would i put in "Installation directory" field ?? I just want to run a jacl script that needs to execute the "wsadmin" command that is located on the windows server that will replace my .ear file after my build deployment is complete. Thank you for your help.

I have a similar problem where Jenkins is on one Red Hat box while WebSphere 8 is on another Red Hat box. How should I config this thing? Or I have to install another WebSphere 8 instance on the first Red Hat?

Can you put in some lines about how to make it work with administration thin client?

We are trying to achieve the following:

We need to automatically deploy one ear from jenkins to a remote WAS installation but we cannot afford ( well, people won`t let us) install a full instance of WAS.

After we have installed the plugin, we need to create a WAS instance on jenkins in order to use WAS builder plugin, but we do not have one.

I can see that you have support for administration thin clients but I am not sure how the path should look like so it can be recognised as a WAS instance.

Can you help me with that?

Also, the user name and password which needs to be provided on the plugin configuration panel should it have a deployer role on the remote WAS instance? Or should it be an user that connects locally to the administration thin client?

I have attached a sample script to this wiki page that I have used to launch the thin client. The IBM doc is fairly detailed on the requirements for this. You need to establish the trust.p12 and configure the soap.client.properties to make the connections.

I can see that you attached the thin client bat file. It`s very much appreciated. I did manage to setup the plugin and query some stuff remotely on the WAS instance. What I wasn`t able to do though was to actually deploy an ear, which was in fact my target.The thin client is on a Windows machine while WAS is installed on Aix and I get this error while using AdminApp.install:

ADMA0043E:C:\Temp\app23320.ear does not exist for installation.

I assume that it tries to transfer the ear file to the remote machine and it is looking for the ear in a temporary folder on a windows machine, but the remote machine is an AIX. I`ve googled around, the only information I could find is that this might happen if I have WAS 5.1, that does not support the transfer,which is not the case or the 2 machines,the one with the thin client and the remote one run on different OS, which is my case but seems ridiculous to have that constraint.

Do you happen to know anything about it? I would really appreciate it. I know there are other ways of doing it, but some other methods require wasadmin password or having a root user on the remote machine, which we`re not allowed to have.

I can see that you attached the thin client bat file. It`s very much appreciated. I did manage to setup the plugin and query some stuff remotely on the WAS instance. What I wasn`t able to do though was to actually deploy an ear, which was in fact my target.The thin client is on a Windows machine while WAS is installed on Aix and I get this error while using AdminApp.install:

ADMA0043E:C:\Temp\app23320.ear does not exist for installation.

I assume that it tries to transfer the ear file to the remote machine and it is looking for the ear in a temporary folder on a windows machine, but the remote machine is an AIX. I`ve googled around, the only information I could find is that this might happen if I have WAS 5.1, that does not support the transfer,which is not the case or the 2 machines,the one with the thin client and the remote one run on different OS, which is my case but seems ridiculous to have that constraint.

Do you happen to know anything about it? I would really appreciate it. I know there are other ways of doing it, but some other methods require wasadmin password or having a root user on the remote machine, which we`re not allowed to have.

It does specify the path to the EAR locally. But when it tries to make the transfer, the ear is saved in C:/temp and it gets immediately deleted. And then I get the ear does not exist in C:/temp for installation error.