UrbanCode Deploy metamorphosis: From process to plug-in

After creating generic UCD processes to first install WebSphere and then create standalone (Base) WebSphere profiles, I wanted to turn my attention to applying the second process to WebSphere ND. I’d already written about creating a clustered CLM setup using the command line in my old post Clusters of CLM applications without a GUI so this should have been pretty simple. It occurred to me that the steps in both the processes from the last two posts could actually be steps in a UCD plug-in, just like the Application Deployment for WebSphere plug-in. Of course I’ve never written an UCD plug-in before and my experiences with writing RTC extensions had left me with the distinct feeling that this kind of thing was not for mere mortals like me. This was the domain of gurus and gods like Ralph Schoon. However, the thought had been planted in my head and, like in Inception, I could not help but follow it through.

So here is my take on “UCD Plug-ins 101 by example”. My goal was to mimic the behaviour of the steps in the process described in Urbancode Deploy: A sample process to install Websphere, starting with the imclListPackages step which is a Shell step.

1. Create a plugin.xml file

According to the UCD Infocenter: “The plugin.xml file defines the steps that comprise the plug-in; a plug-in’s functionality is defined by its steps. Each step is an independently configurable entity in the IBM® UrbanCode Deploy editor.” The details of what goes in the plug-in.xml and the relationship to what is rendered in the UI is described quite well in Example plug-in topic.  So here is my plugin.xml.

Listing 1: plugin.xml

Lines 3-7: This is the header section where the plug-in is given an unique identifier, name,  description and tag which determines where in the process editor UI the steps will show up.

Lines 8-34: define a single step in the plugin , called “List Packages in IM Repository“.

Lines 10-14: Here I define a single, mandatory property called repoURL that is surfaced in the UI as a text box to collect and store the IBM IM repository location as specified via the -repositories option to the imcl command.

Lines 15-26: Recall in my previous post that I used a post-processing script to extract the product identifier string from the output of the imcl command execution and store it in a property called propertyID. This same script goes into the post-processing section in plugin.xml and is what will be called by default after the step’s command has been executed.

Lines 27-34: This is the definition of what command with arguments will be run when this step is executed. Following the lead of the example plug-in and many existing plug-ins I call a Groovy script called imclListPackages.groovy to do the actual work. Note that <arg file='${PLUGIN_INPUT_PROPS}' /> provides the script access to any input properties (repoURL in this case) and <arg file='${PLUGIN_OUTPUT_PROPS}' /> allows the script to set output properties (if any).

2. Create the  imclListPackages.groovy script

This is a simple script that runs the command

imcl listAvailablePackages -repositories ${p:repoURL}

Listing 2: imclListPackages.groovy

There is nothing exceptional about this script but here are a few points to note:

–  the script will be executed  in the Working Directory as specified by the process’ Configuration

– the value of the repoURL property defined in plugin.xml  is obtained from the file named in args[0] (lines 5-14).

– the use of com.urbancode.air.CommandHelper which makes it simple to setup and use ProcessBuilder (lines 18-21)

3. Create the upgrade.xml file

This file provides information needed to propagate upgrades of plug-ins to the UCD server. For the very first (working:-) version of the plug-in it contains nothing particularly useful.

Listing 3: upgrade.xml

4. Package and import the plugin to the UCD server

This process is simplicity itself with no need to stop the server or agents. I create a ZIP archive with the three files I’ve created – plugin.xml, upgrade.xml, imclListPackages.groovy – plus any supporting libraries and files. Then I import the ZIP from the UCD Server -> Settings-> Automation Plugins page.


Assuming everything is in order, my new plugin and step is ready for use in a process.


Assuming again that everything is in order, running the process executes the step which takes the value specified for the repoURL property and sets (if there are no other errors) the product ID property.


So it turns out I was pleasantly surprised by how relatively simple it is to create a plug-in to Urbancode Deploy. As can be seen from my experience, the complexity, if there is such a thing, lies in first figuring out what the plug-in and its steps should do and then writing the code to implement those steps.

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