Quick Post – UrbanCode Deploy REST API and the pesky SSL certificate

Just a quick post for those that are playing with the UrbanCode Deploy REST API.  If you are building a Java solution that utilizes the UrbanCode Deploy REST API, you no doubt have run into the SSL certificate issue.   The default installation for UrbanCode Deploy utilizes a secure socket layer protocol and therefore you have to deal with SSL and its certificate.  Most browsers deal with this and present a warning allowing you to pass at your own risk.


We are all used to this Chrome warning.  You would be surprised at how many internal RTC and UCD servers within IBM don’t bother installing a real certificate 🙂

However, when you are writing Java code that is accessing the REST API, the Java JVM is not as forgiving.  You have to deal with it.  Well, after going to the source of all worldly knowledge, Google, I found an easy solution.  I use Rational Software Architect as my Eclipse IDE, but obviously this will work with any Eclipse-based IDE (any JVM-based IDE for that matter).  Go and get this file.  Create a Java project and add this Java file to it.

In my version, I commented out the section that determines the keystore location (File file = new File…) with a single line that points to my jre that is part of RSA.

File file = new File(“C:/Program Files (x86)/IBM/SDP/jdk/jre/lib/security/cacerts”);

You then simply run the Java program passing the URL (https://<hostname&gt;:8443) of your UrbanCode Deploy server.  Apparently the code attempts to connect and fails, but as part of the SSL handshake process it grabs the server certificate and puts it into the keystore for your JRE.  Not sure exactly how it works but it worked for me so I didn’t dig deeper.

The next time you attempt to run some Java code that access an UrbanCode Deploy REST API from your IDE, you should not have anymore SSL certificate issues getting in your way.   Of course you still have to deal with the certificate “for real” when it comes to production time, but this should get you through the debugging stage.

Everything is a Resource – Resource Templates

UrbanCode Deploy 6.0 introduced the concept of a resource tree.  It takes some getting used to, but overall it gives a nice OPs-centric view of the landscape of things.   But buried in the resource topic is the little known yet powerful concept of resource templates.  Let’s walk through the process of creating and using one.

Note:  My examples below use UrbanCode Deploy 6.0.  I am hoping things look a bit better in 6.0.1 from a user interface standpoint.

First, let’s create a new template.  On the Resources main tab, click on the Resource Templates sub-tab.  Click the Create New Sample link.  You will also notice that you can create a new resource template by connecting to a Cloud provider.  This I believe was the original reason for this feature.  Cloud patterns essentially define resource templates.  So by connecting to a Cloud provider, UrbanCode Deploy creates a resource template from the Cloud pattern.  Luckily for us, they also generalized that feature and let us create resource templates from scratch.

resource template

In this case, we are going to create a new 3 tier topology resource template that can be used to deploy a 3 tiered application (ok its just made up but good for an example).  Once I click Save, I get to define my template.  Using the Action menu on the base resource that gets created, we can create a series of sub-resources to represent the tiers.


And finally, we can add Agent Prototypes to each sub-resource as placeholders for real agents.

Note:  You will notice that you can add a component to an agent prototype.  Why in the world would you want to do that?  In the rare case where you may have some generic component that should be applied to every instance of this template, you can define it here.


We now have our completed template.  This template is now available as a basis for an application environment.  But first we need to create an Application Blueprint, which inserts this application template into a location in an application’s resource tree.  Moving over to the Application Main tab, selecting our application (JPetStore) and finally the Blueprints sub-tab, we can create our new blueprint.  During the creation process, we select the resource template that we want to use, which is the one we just created.

Once the blueprint is created, we can again use the Action menu for each agent prototype and assign the component from our application to the agent prototype.  This process is now mapping our application to an existing resource template, as shown below.


Now that we have our application mapped to the resource template in the blueprint, we can create a new application environment from the blueprint.  Back to the JPetStore application environments page, we can create a new environment.


We give the environment a name, chose the blueprint we just created, and select the base resource where we want to insert this resource template.  This base resource is key and depends on how you have organized your resource tree.  If you organized things well, you can insert this new resource along side the other resource nodes that define other environments for this application.

When you click save, you get an error (that is horribly named) but it helps you to know that you have a step to perform yet.  We have to assign real agents to where we had agent prototypes.  Click on the newly created environment and we see its resource tree.  We can assign a real agent to each node in our tree using the Action menu.


We now have a new environment with real agents assigned to our components, ready for deploy.  Well, almost.  Can you think of what might yet have to be defined?  How about environment properties?  Those will need to be defined if needed.  But once you do that, deploy away.