IBM UrbanCode Deploy plugins are controlled by parameters in a series of XML files.
- info.xml – This file is primarily metadata about the plugin
- plugin.xml – This file is the brains of the operation. It is the interface specification that maps step actions and input parameters to the plugin code that does the work. In other words, this controls what the user sees when creating a process and then takes the provide information and tells the agent which script to fire and with which parameters.
- upgrade.xml – This file defines how the UrbanCode server deals with new versions of the plugin. While it is somewhat minimized in the documentation, it is more useful and more important for keeping plugin upgrades from breaking previously created artifacts in the system. Given some of my experiences, this is probably worth a post by itself.
For info.xml, here are the key elements.
The plugin.xml file is more involved. Inside the overall <plugin> element are a series of repeated <step-type> elements – each of these represents one ‘block’ that can be dropped onto the process designer and how that block will behave when used.
Finally, there is upgrade.xml. This file handles the behavior when new versions of the plugin are imported into an IBM UrbanCode Deploy server. As mentioned above, there is subtlety here that is worthy of its own discussion. As a practical matter, you do not need to use upgrade.xml as long as you do not change anything in the <step-type> blocks that existed in the older version. Adding new <step-types> is OK as well. However, any change to a pre-existing <step-type> element or sub-element requires use of upgrade.xml or it will cause breakage or other problems. Also, do not delete an older version and replace with a new plugin. That can invalidate your process definitions as they track the version of the plugin present and cause you to have to re-create your process definitions.
There is plenty of grist for the blog mill in these XML files. The documentation is pretty good and it is also helpful to look at examples in the plugins provided with the product. Once these are defined, it is time to move on to the Groovy script part of the plugin discussion.
PS – apologies on the PDF-based code snips. We are on the free wordpress and have not solved the code formatting display problem yet.
Avnet Services DevOps 
Leave a comment