Skip navigation

Cloud Lifecycle Mgmt

3 Posts authored by: Nitin Patil
Share This:

Although CLM Callouts have been around for quite some time now, I do get questions on these all the time. In this blog post I will try to clarify the Callout concepts, some commonly asked questions and best practices. We will also walk through Callout registration and request processing. So, bear with me as we call out on this small journey!



1. Callouts Overview

As the name suggests, a Callout is essentially a piece of code that CLM can invoke (call out) during a usecase flow. The best way to look at a Callout is to think of influencing CLM's behavior. Yes, "influencing" is a loaded term. It could be as simple as register my VM into the DNS or could be as loaded as work with the Order Fulfillment system to process the order before commencing provisioning. Following are some other common usecases where customers use CLM Callouts

  • Have VM/server join a domain
  • Notify a 3rdparty application (such as, Backup or Monitoring) about existence of the newly provisioned server
  • Perform any prerequisite Security configurations that are required for provisioning
  • Update 3rdparty CMDB (non-BMC)
  • In releases prior to CLM 4.5, Change Management Integration often used a Callout-based approach.
    Note: From CLM 4.5+, please use the new Change Management Provider architecture to integrate with Change Management systems that are not supported out-of-the-box.


Callouts are typically written as BMC Atrium Orchestrator (BAO) workflows. That does not mean the entire code has to be written in BAO. Often customers have scripts they would like to integrate in a callout scenario and other forms of reusable code. So, think of the Callout BAO workflow as the launch pad/integration layer for such scenarios so that it can handle translation of data and response.


Although it is not as commonly known, but Callouts do have types. There are 3 types of Callouts that CLM supports.

  1. Regular/Standard Callout: Ok, this is not really a type. I just made it up. These Callouts are written in BAO and are the most commonly used Callouts. CLM invokes the Callout and waits for its completion. The Callout returns the result of the processing (typically, success or failure with a message). CLM handles the result and accordingly proceeds with the next steps. In this post I will be focusing on the Standard Callouts only.
  2. HTTP Callout: These are not  commonly used and are typically meant for complex scenarios where the Callout processing is going to take a long time. Now long is relative. But, think of something that will typically run in hours or days (such as, a Purchase Order Processing task that my involve manual steps as well). These Callouts are front-ended by a Java Servlet-style gateway, which receives the Callout invocation and simply informs CLM that the task processing has begun. CLM hibernates the calling task, so that no resources are consumed on the CLM side. Once the Callout has finished the Servlet (or an associated piece of code) can inform CLM about the result of the operation. CLM handles the result and accordingly proceeds with the next steps.
  3. Notification Callout: These Callouts are fire-and-forget style Callouts. That is, CLM invokes the Callout, but does not wait for its completion. As the name suggests, these are intended to simply notify 3rparty systems.



2. Think Object and not time when thinking about Callouts


In my discussions, this is the biggest challenge/shift that has to be understood to use Callouts effectively. Often when we think of a usecase flow, we think in terms of a sequence of operations and events. So, it is natural to ask how do I know where to "attach my Callout" in a CLM flow? Can someone provide me a list? These are fair questions. But, lets park these for a moment and see if at the end of this section you still have those.


A Callout is always attached to an operation on a CLM object. An object here means an entity like the Service instance, Virtual Machine, Application Software, etc. And operation means an action on that object. A typical example is creation of an object. A Callout can either run before the operation (a.k.a pre-callout) or after the operation (a.k.a. post-callout). For example, if you wanted to do DNS registration of your VM with static IP, a VM create pre-callout would be the most appropriate place.


Lets talk a bit about this "think object and not time" aspect. When thinking of associating Callouts, follow this simple guideline.

  • Identify the class for the object of interest. Use CLM's Object Model as reference. In most cases, you should be able to identify the object and its class you are interested in. For example, if you were interested in DNS registration, you are most likely interested in the VM (VirtualGuest) itself. But, if you were doing something at Firewall Rule level, the object of interest would be FirewallRule. Simple! right?
    Object model - BMC Cloud Lifecycle Management 4.5 - BMC Documentation
  • Determine whether your processing needs to happen before the object comes into existence or after it or before/after its operation. Again the above Object Model reference should help you determine the operation of interest.
  • Once you know the class and operation, you can register one or more pre/post Callouts against it and CLM will honor the registration regardless of when that happens in time sequence.


To strike this point home slightly differently, when you start thinking in objects you start taking care of additional usecases that you may not be thinking at the outset. For example, a DNS pre-callout for VM would be useful for provisioning. But, it will also be able to handle any servers added via CLM's auto-scale or additional VMs added via CLM's Add Server capability. So, you see, thinking in object saves you the time and effort to dig into time sequences. Instead, focus on the object of interest and CLM will invoke the Callout whenever that object and operation come into play. Hopefully, it has started to make more sense now.


Having said that, realistically there are a handful of objects and operations that are most commonly used by customers. I am summarizing these here for a quick reference.


ClassOperationCallout Usage Example

A pre-callout for Order Processing.

ServiceOfferingInstanceCONSTRUCTORA post-callout for updating 3rdparty CMDB.
ServiceOfferingInstanceapplyOptionChoiceA pre-callout for doing any processing prior to applying Option Choice(s).
ComputeContainerCONSTRUCTORA post-callout to register a server (virtual/physical) for monitoring.
ComputeContainerDESTRUCTOR and DECOMMISSIONA post-callout to do any clean up after a server (virtual/physical) has been decommissioned or rolled back.
ComputeContainerEXECUTE_SCRIPTA pre-callout to perform the logic for a Custom Operator Action (such as, create snapshot).
ComputeContainerSTARTA pre-callout to perform processing before starting a server.
ComputeContainerSTOPA pre-callout to perform processing before stopping a server.
VirtualGuestCONSTRUCTORA pre-callout to do DNS registration for a virtual server.
VirtualGuestDESTRUCTORA post-callout to do any clean up post decommission/roll back of a virtual server (such as, clean up DNS).
OperatingSystemCONSTRUCTORA pre-callout to do DNS registration for a physical server.
ApplicationSoftwareCONSTRUCTORA pre-callout to do any specific processing prior to initiating software install.
NetworkConnectorCONSTRUCTORA pre-callout to do any specific processing before CLM acquires NIC information (such as, IP address, network/portgroup/VLAN info, etc.)
NetworkConnectorDESTRUCTORA post-callout to do any specific processing after CLM has decommissioned/removed a NIC.



3. Commonly asked questions about Callouts


Q. How long can a Callout take?

A. The short answer is 'forever'. Yes, a Callout can ideally run forever and CLM will wait for its completion. A Callout invocation can even withstand CLM Platform Manager restarts. CLM handles Callout invocation intelligently by hibernating the parent task that invoked the Callout. This is to reduce undue load on the system. The Callout workflow that is invoked by CLM (keeping a Standard Callout in mind) is the one that CLM would wait on. This workflow can choose to call other BAO workflows and utilities/code.


Q. Can a Callout abort further processing? Or can a Callout return status? Can it written an error message that will be shown in CLM Activities results?

A. The short answer is 'Yes' to all of the above questions. A Callout response is well defined. It can return success or failure. In case of failure, it can also return an error message. I have attached some sample Callout response XMLs to this post for reference.


Q. Can I reuse my existing scripts with Callouts?

A. While it is our intent is to promote re-usability with Callouts, the answer to the question really depends on what type of script it is and how reusable it is? BAO provides various adapters for typical integration scenarios like the various command line adapters. It is possible to invoke a script using such an adapter. However, the script should support re-use. Or hopefully it requires minor tweaks. Keep the target platform idiosyncrasies in mind as well. For example, it is fairly well understood in a UNIX style scripting on how to interpret the exit status of a script and how to fetch the error message. However, that may not be true for all platforms. The point being ensure your script is capable of handling the usecase needs and the automation desired.


Q. Can a Callout change the object it is associated with?

A. No. For those familiar with Application Architecture, it is important to know that Callouts do not follow the Decorator pattern, which let you decorate (manipulate) the objects. Callouts are purely meant to influence behavior.


Q. I also see things like Blueprint Post Deployment Actions, Pre/Post Install Actions per Software, Custom Action via Option Choices. How are these different from Callouts and when should I use these over Callouts?

A. It is a loaded question. So, let me try to break these into simpler points.

  • Callouts are system-wide and global in nature. That is, anytime CLM invokes the operation on the object for which you have registered one or more Callouts, CLM will invoke the Callout(s). Of course, you can write logic inside a Callout to decide when to do processing and when not to do anything. But, CLM will invoke the Callout if its object and operation are in the path of that usecase flow. Period.
  • Blueprint Post Deployment Actions (PDAs) or the ones injected using Service Catalog Option Choices are typically meant for specific usecases only. For example, I may have a PDA to format and partition a newly added disk. But, this does not need to happen for every CLM provisioning flow. Only when the user requested that specific Blueprint or Option Choice. PDAs can also be of type NSH (Bladelogic Server Automation script). Callouts can only be written in BAO (at least the main Callout workflow).
  • The Pre/Post Install actions per Software are to invoke that action only for that specific software. On the contrary, if you were to invoke a BAO workflow for every software installed, you could instead consider using an ApplicationSoftware_CONSTRUCTOR pre/post Callout.
  • Custom Action via Option Choices are similar to PDAs but work in the context of a given Option Choice. For example, an Add Disk option choice could include a Custom Action to format and partition the disk. Again, Custom Actions can be of type BAO workflow or NSH.



4. How do I register and use Callouts?


We have talked a lot about Callout concepts and hopefully clarified some questions that might have bee on your mind. Lets see these in action now.


Callout registration is a very simple process. Following is a screenshot that demonstrates the process.

  • There is a Callout Workspace that is part of the CLM Admin Portal->Configuration.
  • You can simply create an entry for a new Callout registration. As you can see the data being asked is very minimal. Mainly, you need to know the Class and Operation and whether you want to invoke Callout before or after the operation. You obviously need to know the main Callout BAO workflow name. Notice that the BAO workflow name is specified in a fully qualified format (starting with a ':'). Don't worry about weight. If you have multiple Callouts for a given operation, you can assign weight to give priority to one Callout over others.
  • Once you save this entry, the Callout is active from that point.


Now that we know how a Callout is registered, lets see what data it receives. Remember that a Callout is associated with an object (more accurately, class) and operation. As such, the data it receives is the object representation at that point in time. For example, a pre Callout for the same object may receive less data than the post Callout for the same object because during the operation rest of the object got populated. This may also help you determine a more appropriate place for associating the Callout depending on what data you are looking for. So, it is difficult to generalize what data a Callout would receive. However, there is a standard pattern followed for sending data to Callouts. Lets talk about that.


Following is a sample Callout request data (often referred to as "CSMRequest" or "CSMRequest XML") for a ServiceOfferingInstance_BULKCREATE pre-callout.



  • The root is always "CsmRequest".
  • Most of the data related to the object would be found under the "operationParameters" section. For example, here you can see the data around the requested Service Offering, selected option choices, the hostname prefix specified by the user, any parameters and data associated with the request, etc.
  • The Callout can parse out this data along with any additional lookups and data it needs and use it for its processing.
  • Additional metadata about the request is available in other parts of the XML.


Once a Callout has finished processing it should return the status along with any error and associated message to CLM, as appropriate. Note that the Callout responses do not return the object the Callout was associated with because... You got it - because a Callout cannot manipulate the object. It can only influence behavior.


Following is an example of a successful Callout response.



Following is an example of a failure Callout response.



5. Conclusion


As you can see, Callouts do require a bit of an effort. But, it could be well worth depending on the usecase and what you are trying to accomplish. These are certainly nuggets that are available to you to integrate CLM better in rest of your ecosystem.


If there are other topics you would like me to blog about, please feel free to leave me a comment. I will try my best to respond to the requests.


Have a good day!

- Nitin

Cloud is a journey with milestones and not a destination!

Share This:



In this post, I will be covering the terms that many BMC Services and Partners personnel use when talking about CLM. But, not everyone may be familiar with these. I will try my best to keep this post up-to-date and may also point to it from my future posts for reference purpose.


Note: The primary focus of this post is to clarify the terminology in the context of CLM. Hence, we will not be discussing specific CLM capabilities here.


Lets get started.


The list is alphabetically sorted for ease of lookup.


Day 0Time in the life span of a cloud deployment that typically happens during cloud infrastructure setup. For many customers this would span process, people and technology.Setup vSphere infrastructure.
Day 1

Time when a Service is being requested/provisioned. It is typically in the context of a Service.

Note: Also see "Service Offering Instance" below.

Day 2Time from the point a Service has been provisioned. Again, it is in the context of a Service. Often, you may hear a statement like "Day 2 activity", which essentially means an action on a Service that has been provisioned by CLM.
Delivery Requestable Offering (DRO)It refers to a Service Catalog item that user can request. It is a special form of Requestable Offering (RO) that is specifically meant for Day 1 only.Service Catalog item to request "Windows IaaS".
Network ContainerIt provides a consistent set of networking services per the Network Blueprint definition. That is, two containers from the same Network Blueprint will offer identical set of services, such as, network routing, load balancing and firewall services.
POD (or Pod)A unit of capacity that encompasses Compute, Network and Storage and offers repeatability and consistency from capacity planning perspective. Example, a POD could host 'X' VMs of a given size. Often POD would involve several physical equipment and may also have additional components like a Converged Infrastructure (UCS, Flexpod, etc).
Requestable OfferingA Service Catalog item that user can request. In CLM context, it is tied to a Service Offering.
Service Offering Instance (SOI)It refers to a Service instance that is managed by CLM.
Transactional Requestable Offering (TRO)In the context of CLM it typically refers to  Day 2 Options.Modify CPU and Memory.
Virtual Network Disk (VND)A disk that is hosted on a network'ed storage infrastructure (such as, NAS or SAN).NFS mount, LUN.
Virtual System Disk (VSD)A disk that's directly attached to a server.Physical disk, VMware VMDK.


Have a good day!

- Nitin


Cloud is a journey with milestones and not a destination

Share This:

** Welcome! to Nitin's CLM Blog **




I am a senior R&D  Architect working on CLM (Cloud Lifecycle Management). In the past 5 years, I have worked closely with several CLM deployments in all sorts of domains. This blog is an attempt to share some of the learnings. Hopefully, you find it useful.


To get the blog rolling, what else could be a better topic than understanding CLM at a very high level? That does mean some of the stuff I mention below may sound familiar. Nevertheless, it's good to know, in general, what CLM is capable of as that will build foundation for future posts.


CLM @40000 ft.

  • Manager of Managers
    • This principle is very near and dear to CLM's core design. In general, what this means is CLM is not meant to replace the last mile Element Managers (such as, hypervisor management layers). Instead, its intended to work with these layers and add value on top. For example, CLM's Blueprint capability provides a unified way of working with different underlying platforms. This also means in many cases that customer's can leverage their existing investment in infrastructure management layer and best practices with CLM.
  • Heterogeneity is a reality
    • Be it public cloud, private/on-premise cloud, physical servers or some form of mix-n-match, CLM provides a rich set of platform support that continues to grow.
  • CLM Roles
    CLM supports the following roles to meet the needs of a typical cloud
    • Cloud Admin: The super user(s) in the CLM world. They can do everything in CLM from administration to end user centric activities and have visibility and control over all services being managed by CLM.
    • Tenant Admin: The Tenant Admin(s) can manage one or more tenants (a tenant being a Company). They have limited administration capabilities and have visibility and control over all services of the tenants they manage.
    • End User: Last but not the the least, the end user themselves. An End User can request and manage his/her own services only. In addition, over CLM releases we continue to enhance the capabilities from an End User perspective with the focus of making them more self-service enabled.
  • Service Blueprints for Service Design and Deployment
    • CLM's Service Blueprints let you define 2 aspects a) Service Definition (what is the composition of a given service?) b) in what possible ways can this service be deployed? Add to that Service Blueprint authoring experience is consistent across different platforms thus making it easier for Cloud Admins to work in a mixed platform environment.
    • Service Blueprints also let you specify 'toppings'. Yes, you read it right. We call it Options and Option Choices. And, just like toppings in a  food menu are addons typically with additional price tags, CLM Option Choices are similarly part of CLM's Service Catalog and are fully configurable by the Cloud Admin.
  • Cloud Administrator in control
    Several companies who invest in cloud solution have realized benefits of not just being able to stand up cloud services quickly, but to be also able to reclaim services and the underlying resources when not needed. The dynamics of a cloud make it important to have consistency, repeatability and governance that Cloud Administrators can rely upon. With that in mind, CLM offers several core capabilities
    • Service Governance: Ability to place service workloads per the desired infrastructure best practices and support modifications that honor the same. CLM provides foundational elements, such as, tags and policies that can be leveraged for these.
    • Entitlements: Ability to only show users what they can request and not the entire cloud Service Catalog is an important capability.
    • Multi-tenancy: Ability to allocate infrastructure resources to multiple tenants per the desired cloud business model. For example, CLM supports allowing dedicated infrastructure per tenant to having shared infrastructure across tenants and a mix of these approaches as well!
    • Security: Whether you are looking for layer 2 segregation or fully firewall'ed and locked down service, CLM provides a rich set of capabilities to meet from simple to very complex needs.
    • Quotas: An ability to hierarchically slice your infrastructure resources that are inline with your business objectives. For example, a Cloud Admin can allocate quota 'X' to a tenant, which means the tenant cannot exceed that quota. Further, the Tenant Admin (or Cloud Admin) for that tenant could split the quota amongst that tenant's users to ensure an optimal split. It's not necessary to allocate quotas. But, if allocated, CLM honors those.
    • Dashboards: Convenient dashboards for Cloud Admins to get a cockpit view of the deployment. Things like, which are the most requested Service Offerings. So they can focus on value realization and where to spend efforts.
    • Multi-site: Several of our customers have more than one location being managed by CLM. This is an important capability to know that same CLM management stack can help you manage multiple datacenters that could be spread across the globe thus providing you the benefits of a centralized management.
  • Full Service Lifecycle Management
    As many of us who have worked closely with infrastructure and cloud management solutions know that provisioning is typically not the long pole in a cloud management solution typically. It is generally the combination of process, people and technology. And, that's just the provisioning aspect. What about post provisioning (i.e., after the service has been stood up)? It is challenges like these that make cloud solutions more daunting. For CLM, this is one of our core focus area and we continue to get better. Some of the key capabilities to note are mentioned below.
    • Simple single-tier IaaS services: If you are feeling bit shy of launching simple IaaS service via cloud, do not be. The majority of customers I have worked with have all pretty much started with IaaS offerings. What's important to know is you don't have to stop there. It's a milestone in the cloud journey that's worth considering.
    • Complex multi-tier robust application services: For those who are looking to deploy multi-tier applications that are fully load balanced along with firewall configuration, CLM has a rich set of capabilities to accomplish these.
    • Multi-step complex server build: A typical server build is rarely just provisioning. There may be additional process checkpoints (like securing some sort of application identification code before commencing provisioning), infrastructure updates (like DNS registration), ensuring host names are consistent with the deployment standards, notifying other systems (such as, monitoring and backup systems), the list goes on and on. The good news is CLM offers several capabilities to be able to adapt to your server build process to make the transition to cloud more friendly.
    • Application Parameterization: Talk to any developer or application expert and they will differentiate between "application installed" vs "application installed and configured". And, they are right. Just because I installed Apache Webserver does not mean it's properly configured and ready to use. CLM provides several capabilities in this regard. An important one being an ability to pass either Cloud Admin specified configuration/application data that can be adjusted by End User (only if a Cloud Admin has allowed them to do so). Continuing with our Apache Webserver example, the Cloud Admin may let the End User choose the web server port, but may choose to keep the Document Root directory internal to ensure its path is consistent on filesystem.
    • Auto-scaling: An ability to scale up or down as the application demand varies.
    • Provisioning and Post Provisioning Actions: As provisioning happens you may have additional steps to execute, such as, format the added hard disk. Likewise, for any such activity that happens after the service has been stood up.
  • CLM as an Extensible Platform
    While CLM has a rich set of out-of-the-box capabilities, it is true that every customer environment is different. Their usecases may be same or similar, but the means to get there is typically not. Hence, we do not try to boil the ocean in our design. We have intentionally designed CLM with extensibility in mind. So, the way to look at CLM is not just as a solution, but also as an Extensible Platform that can be enhanced to handle the customer deployment specific needs that are not out-of-the-box. For example, CLM offers a rich REST API as well as an SDK for such needs. Here are some typical extensibility usecases (not an exhaustive list, but to give you a picture)
    • 3rdparty Integration Scenarios like DNS updates, monitoring and backup solution updates for CLM managed services.
    • Integrating CLM with platforms that are not available out-of-the-box (example, Solaris Zones).
    • Making CLM use hostnames that follow the deployment standards.
    • Ensuring CLM managed services are placed using very specific and custom workload placement logic.
    • Building custom portal on top of CLM.
    • Building northbound integrations on top of CLM for automation and other integration purpose.


I know that I didn't get to cover every single CLM feature. But, hopefully, this gave you a fairly decent picture of what CLM is capable of. I will be glad to hear any comments and feedback.


Have a good day!

- Nitin


Cloud is a journey with milestones and not a destination!

Filter Blog

By date:
By tag: