To learn more about Chargeback specific to BMC Cloud Lifecycle Management, refer to the following sections:
BMC Cloud Lifecycle Management stores information about Services that can be requested and provisioned in the Service Catalog. In order for a Service to be available for request, there needs to be a Service Offering (SO) for that Service, that specifies details about how the Service is presented to users for request and how it is priced. Setting a price in the Service Catalog implies that you select a specific Unit of Measure (UoM) corresponding to this price.
When a Service is requested, BMC Cloud Lifecycle Management creates a Contract Line associated with the proper Tenant that specifies the:
BMC Cloud Lifecycle Management also provisions a Service Offering Instance (SOI), and the related Contract Line contains information about the SOI provisioned for this request.
For each BMC Cloud Lifecycle Management Cloud Services Extractor ETL (connected to a BMC Cloud Lifecycle Management instance) a corresponding Cost Model Template is automatically created in BMC Capacity Optimization. A Cost Model Template contains the full list of cost objects - composite or basic - used by belonging Cost Models. In a Cost Model Template, users can manage the set of report templates automatically executed for all Cost Models and Aggregated reports for the whole integration.
It is important to note, that for each:
Provisioning or decommissioning dates in the SOI are imported in the Allocation, and influence the final charge.
The BMC Cloud Lifecycle Management Services Extractor also populates a domain in the BMC Capacity Optimization workspace section with the list of allocated resources (typically Virtual Machines) provisioned by the SOI. This domain is linked to the allocation and contained entities together with their configuration, and utilization metrics are used for the Cost Model calculation.
The following table shows mappings that are automatically created in BMC Capacity Optimization by the Cloud Services Extractor ETL. For more information, see Extracting cloud services data in BMC Capacity Optimization.
Mappings created by the Cloud Services Extractor ETL
BMC Cloud Lifecycle Management
BMC Capacity Optimization
Service Offering (SO)
Composite Cost Object (CCO)
Service Offering Instance (SOI)
Allocation of a CCO
Contract line start and stop dates
Compute Containers in an SOI
VMs in the domain in the workspace tree
Prices on SO, RO, or options
Cost rates in Cost Model
Single currency at entire Cost Model (tenant level)
Any OOTB Allocation UoM
Corresponding BMC Capacity Optimization metric extracted by Cloud Services Extractor
Any OOTB Utilization UoM
Corresponding BMC Capacity Optimization metric by platform
After the SOI has been provisioned, users in Cloud Lifecycle Management may modify the SOI, either by changing the compute resources assigned (e.g., adding memory to a virtual machine) or by adding or removing compute containers (e.g., virtual machines). The following table shows how these changes affect the Chargeback calculations.
Change made in CLM
Example of change
Effect on Chargeback
More resources added to existing compute container; no prices changed.
More CPUs added to one VM in the SOI
If a CPU allocation price was in effect, then the additional CPUs will be charged starting from when the CLM Cloud Services Extractor discovers the new VM configuration.
If a CPU utilization price was in effect, then the additional CPU utilization will be charged starting from when the vCenter Extractor Service discovers the new CPU utilization.
New compute container added; no prices changed.
|One more VM was added to the SOI|
If any allocation price was in effect, then the additional allocated resources will be charged starting from when the original SOI contract line was created.
If any utilization price was in effect, then the additional utilization will be charged starting from when the infrastructure connector (e.g., vCenter Extractor Service) discovers the new resource utilization.
New compute container added; new instance price assigned
One more VM was added to the SOI, and a per-instance price was set
The new instance price will be charged in addition to any existing instance price, starting from when the VM was added (because a new add-on contract line was started).
|New compute container added; new allocation or utilization price assigned||One more VM was added to the SOI, and an allocation or utilization price was set||The new allocation or utilization prices will be ignored, and an error message will be written to the logs as in the section below, "Limitations on supported prices for Option Choices". Chargeback will continue to use the same prices as before the change. Chargeback will increase, applying any prices already in effect.|
This section illustrates a series of steps representing a typical workflow of Chargeback for BMC Cloud Lifecycle Management.
Are stored in the BMC Capacity Optimization repository and saved as Time Series in the Data Warehouse by the Chargeback Store Task.
By default, Chargeback Models for BMC Cloud Lifecycle Management are marked as Golden. For all golden models, the Chargeback Store Task collects data of costs as a Time Series in the Data Warehouse (this is a requirement for OOTB Single Instance Reports).
The following figure illustrates the workflow with the help of a graphic.
Chargeback for BMC Cloud Lifecycle Management - Workflow
Prices defined in the BMC Cloud Lifecycle Management SO Catalog are copied into the provisioned SOI, the ETL extracts these prices and generates cost rates in the BMC Capacity Optimization Cost Model of the Tenant. Cost rates are strictly linked to the SOI and the specific Unit of Measurement (UoM). The Currency is imported only for labeling purposes and has a scope for the entire Tenant Cost Model.
As no currency conversion is supported, all SOs bought by a Tenant must be defined with the same currency. If different Tenants buy SOs with coherent currencies, their model results and especially the total charge will be computed correctly. Aggregated reports, summarizing different cost models can report a wrong summarized cost in case of multiple currencies.
BMC Capacity Optimization has a predefined mapping for OOTB BMC Cloud Lifecycle Management UoMs that defines how BMC Capacity Optimization accounts allocations and utilization costs, and which BMC Capacity Optimization metrics are used to compute the consumption of Basic Cost Objects. Consumption combined with the cost rate generates the final cost as it is described in BMC Cloud Lifecycle Management.
There are three kinds of BMC Cloud Lifecycle Management UoMs that are mapped to BMC Capacity Optimization Chargeback cost rates. Refer to the following table for a brief description.
BMC Cloud Lifecycle Management UoMs mapped to BMC Capacity Optimization Chargeback cost rates
This is the “Instance” UoM in BMC Cloud Lifecycle Management. It means that a single per-unit-time cost is to be charged for the entire Service Offering Instance.
One dollar per day.
This kind of UoM, for example, CPU Count, is a per-unit-time cost based on some allocated resource.
One dollar per CPU per day.
This kind of UoM is a per-unit-time cost, based on actual resource usage during that time.
One cent per CPU GHz used per hour.
For more information on mappings, see UoM mapping in BMC Cloud Lifecycle Management.
The Network GB Upload/Download UOMs refer to the amount of data, in GBs, that is received and sent in the network. The price period defined in BMC Cloud Lifecycle Management for those UoMs is irrelevant because in effect, the price defines cost per 1 GB sent/received.
In Chargeback specific to BMC Cloud Lifecycle Management, the Customer Price(s) supported for Option Choice and Post Deploy Actions are only per instance.
The reason for this limitation is explained with the help of the following example.
You can approach this limitation in the following ways:
When a Cloud Administrator configures a Customer Price in BMC Cloud Lifecycle Management for a Post Deploy Action or for an Option Choice which is not per instance, the BMC Cloud Lifecycle Management integration for Chargeback generates
In BMC Cloud Lifecycle Management, there is currently no restriction on the types of Customer Price that a Cloud Administrator can configure for an Option Choice or for a Post Deploy Action, and this can cause a bad configuration. When the ETL discovers this situation, it logs a
The default mapping between BMC Capacity Optimization objects and BMC Cloud Lifecycle Management units of measures comes OOTB with BMC Capacity Optimization. If needed, it is possible to redefine those rules in order to support a new custom UoM.
The BMC Cloud Lifecycle Management Cloud Services Extractor uses a .XML configuration file that describes how the BMC Cloud Lifecycle Management unit of measures must be mapped into chargeback costs. It defines the type of UoM, and the BMC Capacity Optimization metric that is associated with different technologies.
Each BMC Cloud Lifecycle Management UoM is described by the
uom tag that contains all the information needed by BMC Capacity Optimization to create the related chargeback elements.
This section discusses the following:
This section illustrates the elements used in the example XML configuration file that is used by the BMC Cloud Lifecycle Management Cloud Services Extractor.
The following tables per section describe each element the XML configuration file consists of, according to the relevant tags in the XML structure.
Internal name of the BMC Cloud Lifecycle Management unit of measure.
True if the UoM should not be imported for the chargeback purpose
Element used to describe utilization cost.
Element used to describe instance cost.
Element used to describe instance cost.
Label used for the consumption unit.
Label used for the cost unit.
Override the price period specified in BMC Cloud Lifecycle Management.
Semicolon separated values of the type of resource to be extracted.
BMC Capacity Optimization metric name.
A consumption scale factor. This value is multiplied by daily consumption
BMC Capacity Optimization subresource name.
If true, a last value algorithm is used in order to fill data gaps
Override the price period specified in BMC Cloud Lifecycle Management. Allowed values are:
You can override the configuration file of the Cloud Services Extractor by uploading your own custom XML file in the primary scheduler host, and manually add the
chargeback.client.file.path property to the run configuration of the extractor, along with the path of the configuration file. The following graphic illustrates the property.
The custom configuration file must contain all definitions of the UoM available in BMC Cloud Lifecycle Management. The easiest way to customize the UoM mapping is to make a copy of the OOTB configuration file, and then modify it as needed.
The following code snippet is an example illustrating a section of a .XML configuration file.
To download a sample copy of the OOTB XML configuration file for the BMC Cloud Lifecycle Management Cloud Services Extractor, click here.
Among all API calls documented for Chargeback in BMC Capacity Optimization, the only two kinds applicable to Chargeback for BMC Cloud Lifecycle Management are:
The other API calls are applicable only if you are building custom Chargeback models.