Share This:

In my previous post Stop services or servers in bulk using Cloud SDK, I shared my experience of using Python SDK.


With CLM v4.5, BMC Cloud Lifecycle Management AWS Client Software Development Kit is also released! Simply put, one can use this SDK as if they were interacting with Amazon Web Service (AWS) infrastructure but in reality it can talk to AWS and non-AWS infrastructure as well.


What's the catch?

The catch is ... using same SDK one can start interacting with non-AWS infrastructure as well. And to add to that, one can leverage other facilities delivered in BMC CLM like trusted cloud, compliance etc.


Case Study

As a case study, let's take AWS Toolkit for Eclipse and see how it can be changed with minimal efforts to manage all servers hosted through BMC CLM.


In a moment I will explain what we did. But before that one disclaimer is - you have to know basics of Amazon AWS SDK. If you don't know, read these articles before - Tutorial: Starting an EC2 Instance - AWS SDK for Java and Run an Amazon EC2 Instance - AWS SDK for Java to know how Amazon AWS SDK works.


So let's get back to what we did,

  1. Downloaded source code from GIT @ aws/aws-toolkit-eclipse · GitHub
  2. Introduced a dummy region, BMC CLM, that would use CLM AWS SDK instead of Amazon AWS SDK. For this we had to modify regions.xml to include following XML block -

        <displayname>BMC CLM</displayname>
          <service name="S3">...</service>
          <service name="CloudFront">...</service>
          <service name="IAM">...</service>
          <service name="SNS">...</service>
          <service name="SQS">...</service>
          <service name="SimpleDB">...</service>
          <service name="EC2">...</service>
          <service name="RDS">...</service>
          <service name="CloudFormation">...</service>
          <service name="ElasticBeanstalk">...</service>
          <service name="GitPush">...</service>
          <service name="ELB">...</service>
          <service name="AutoScaling">...</service>
          <service name="CloudWatch">...</service>
          <service name="DynamoDB">...</service>

  3. Extracted CLM AWS SDK ZIP in lib/clm folder under com.amazonaws.eclipse.core module.
  4. Modified Eclipse project build paths to include all the libraries under 'lib/clm' folder and it's sub-folders.
  5. Modified AWSClientFactory class as shown below -

    public AmazonEC2 getEC2ClientByEndpoint(String endpoint) {
        final String BMCCLM = "bmc-clm";
        if(endpoint == null || endpoint.contains(BMCCLM)) {
                Properties configProps = new Properties();
                configProps.put("PLATFORM_MANAGER_URL", "clmhost:port");
                configProps.put("CLM_USER_ID", "<<clmusername>>");
                configProps.put("CLM_USER_PASSWORD", "<<clmpassword>>");
            return new CLMEC2Client(configProps);
        } else {
            return getOrCreateClient(endpoint, AmazonEC2Client.class);

  6. Build the latest code base.


Well, that's it! We have AWS Toolkit that communicates with BMC CLM if 'BMC CLM' region is selected!


So let's step back a bit and understand what is done.


Let's say user invoked 'Launch' action to launch an EC2 instance. What happens beneath the scene is,


  1. The call hits flow in LaunchWizard class in com.amazonaws.eclipse.ec2 module.
  2. That intern calls launch(...) method in Ec2InstanceLauncher class in same module. That's where all communication logic gets triggered.
  3. All the actual communication happens through com.amazonaws.eclipse.core.
  4. All the other modules refer to regions.xml to show supported regions. That's where BMC CLM region comes in picture.
  5. The call reaches AWSClientFactory.getEC2ClientByEndpoint(...) and URLs are picked up from selected region. That's where we have patched code to route the call to CLMEC2Client instead of AmazonEC2Client. Since CLMEC2Client implements same interface AmazonEC2, no other changes are needed.
  6. Ec2InstanceLauncher later makes call to ec2.runInstances(request) which is nothing but CLMEC2Client.runInstances(...).
  7. CLMEC2Client.runInstances(...) implementation will all necessary steps mentioned @ runInstances - BMC Cloud Lifecycle Management 4.5 - BMC Documentation.


Similarly, if user invokes server list, start server, stop server actions, all the calls will route through BMC CLM.



  1. CLM AWS SDK is much simpler to use. In fact, if you have consumed Amazon AWS SDK for java, there is no/minimal learning curve at all.
  2. CLM AWS SDK implements same interfaces and method signatures, so no practically no code changes are required if you already have a custom portal or application talking to Amazon EC2 infrastructure.
  3. CLM AWS SDK takes care of translating a method call to what all it takes to perform equivalent operation through BMC CLM.
  4. CLM AWS SDK will work for all servers may it be on-premise, AWS, Microsoft Azure, OpenStack etc.
  5. And BTW, did you realize that if you had configured change approval in BMC CLM, all of a sudden the actions done by user will wait for approval before touching the infrastructure? Isn't that awesome? There are many more such features of BMC CLM... not just this one.


How easy can it get?!