Consumption Analytics Documentation

Home > Documentation for older versions > Cloud Cruiser 4 > Collecting, transforming, and publishing > HP Cloud Service Automation

HP Cloud Service Automation

Cloud Cruiser’s HP Cloud Service Automation (CSA) collector is based on the REST API provided by CSA. The REST API for CSA is designed to support the end user portal and as a result the importers and collector iterate through the valid CSA users and collect data visible to each user while avoiding duplicate requests where they might occur (for example, Service Offerings). Cloud Cruiser supports CSA API version 4.1. Compatibility with later versions is unknown.

Specific batch processing components for CSA are provided that support collecting subscription data, importing organizations and importing service offering catalogs.

Service offerings are contained in one or more catalogs and organized by category. Each offering can have one or more options. These offerings must be imported to establish a resource model to support reporting. The default solution imports the offerings as a passthrough resource with its rates defined within the source system. Cloud Cruiser does not maintain the rate value.

Configuring Cloud Cruiser to collect, transform, and publish HP CSA data

To collect, transform, and publish set up HP CSA data

  1. Create an HP Cloud Service Automation Subscription data source as described in Data sources. You will need the following information:
    • Endpoint: The CSA portal endpoint URL, usually formatted as https://<serverName>:8444/csa/rest.
    • Username: A CSA user with access to the CSA API.
    • Password: The password for the user entered in the Username field.
    • SSL Negotiation: (version 4.3.8 and later) The version of Transport Layer Security (TLS) to use for connections to HP CSA. Choose one of the following based on the configuration of your CSA system:
      • TLSv1 Only: Uses TLS v1.0.
      • Full: Attempts to connect with TLS v1.3 and negotiates downward as far as 1.0.
  2. Create a new workbook, as described in Creating workbooks.
  3. Create an HP Cloud Service Automation Subscription collection, as described in Creating collections.
    • In the Name and Source tab, specify the Data Source you created in step 1.
    • In the HP Cloud Service Automation Subscription Properties section, select a template. Your selection enables you to either include or exclude pricing information.
    • Use the Include Subscription Detail field to specify whether you want to limit the detailed information collected.
    • Use the Include Instance Data field to specify whether you want to collect information about each service in the subscription.
  4. In the Advanced Configuration dialog box, specify the information you want to collect from CSA. See Mapping data to Cloud Cruiser.
  5. (Optional) If you want to collect CSA catalog information, create an HP Cloud Service Automation Catalog collection, as described in Creating collections.
  6. Create workflow to import and transform your data as needed.
    For example, each request contains all the current pricing and options selected along with a start time. It is Cloud Cruiser’s task to figure out the end time for each. Another request (modification) on the same subscription, or a cancelation request, will terminate a previous request. Otherwise, the request is assumed to still be in effect. Use Convert to Start Event and Convert to End Event transformation steps to fill in missing usage start or usage end dates, depending on configuration.
    For more information about transforming your data, see Working with flows.
  7. Configure the publishing of your data to a Cloud Cruiser schema, as described in Publishing data to a schema.
  8. Test your workbook, as described in Testing collection and deleting data loads. When you are done editing your workbook be sure to delete any test data loads before you proceed to the next step.
  9. Schedule regular collection for this workbook, starting when the next day's complete data is available, as described in Scheduling jobs to run.
  10. Collect and publish past data for this workbook to ensure that Cloud Cruiser has all available prior data, as described in Run a workbook for a range of dates.

Account structure

The account structure for a CSA solution typically includes the organization, person, and subscription. For example, CSA could have an account structure like the following:

Account ID





Customer record



End user requesting services



Services consumed by the customer

In this example, Subscription is the lowest account level. It provides an account to map in provider specific resource consumption, such as Matrix Operating Environment (MOE) or vCenter resources. You can configure the account as a default to meet your needs. For more information, see Working with account structures.


CSA Organizations contain persons, who are essentially the end users requesting services. Importing person records is optional and creates a customer record for accounts at the person level when activated.

Organizational data in CSA can be imported to establish a customer record per organization. Having a customer record simplifies scoping reports, and makes it easier to define budgets and set alerts. For more information, see Managing customers.

You must configure the organization importer to construct an account identifier for the organization that will match the account codes created when loading subscription data. Both organization import and data loading should align with the account structure defined for your solution.


Subscriptions represent the consumption of services and service infrastructure by the user, and are the source of data for all charges and historical reporting. In CSA, a subscription can be flexed, meaning that the underlying service or service options can change. To accurately track subscription state and load the proper data, subscription data must be polled at regular intervals or the history of service requests that affect subscription state can be mined for data. The sample solution does the latter and does not require polling. This means that collection can be performed for previous dates and will remain accurate.


CSA pricing allows for both an initial fixed price and a recurring price. To support this, separate resources are created: one for the initial price and another for the recurring rate.

  • Initial Price is a one-time charge that is applied to a customer’s invoice. The charge is applied each time a user starts that service. Therefore, the resource is charged in full each time the service is launched.
  • Recurring Rate is allocation-based pricing. It is prorated for the duration of the service subscription with a rate that can represent an hourly, daily, weekly, monthly, or yearly price. There can also be options for the service that contain their own pricing information. Each option is imported as a pair of resources in the same manner as the base offering. The importer includes the base offering name in the option resource description so they are properly qualified when they appear in the UI and reports.

To accommodate options pricing, Cloud Cruiser creates distinct resources for each configured option and treats them as separate resources. Options can have both initial and recurring costs.

Each item having a price and quantity is considered a consumable resource and requires a unique identifier and description. An Offering represents a resource by itself. Each option of an Offering is considered a separate passthrough resource.

In both CSA and Cloud Cruiser, services/resources are managed using a 32-digit hex UUID. The UUID is imported by Cloud Cruiser and used as the resource name. The resource’s description is the title of the service, as defined in CSA. For example, a 32-digit hex UUID of 8a83d19e3803d463013805a8ab4816fe can be defined as a resource called Physical Server Request in Cloud Cruiser.



An identifier is anything in the file you can associate with the resource. Everything in the subscription name value pair are identifiers.

The following are the fixed identifier names that are used in the CC Record files created when running CSA jobs:




User ID of the organization


Name of the organization


Organization display name. If the display name is not specified, orgName is also used for the display.


Person user ID


Person name


Person display name. If the display name is not specified, personName is also used for the display.

Mapping data to Cloud Cruiser

A sequence of calls gathers pertinent information into a single document for data mapping. For each subscription, the subscription detail document provided by CSA is used as the base input document for collection. Each Service Offering is mapped into multiple resources for the initial and recurring prices of the base offering, as well as each option. This provides resource costs as part of the resulting CC Record data by using standard data mapping capabilities controlled by the feed configuration for a CSA collection.

Subscription data is collected by making a series of REST calls to gather data on the subscription itself, as well as all related requests and service instances. 

You can map collected dtaa to Cloud Cruiser using XPath expressions and standard output field mapping. This works the same as does mapping output from the XML Collector. For more information, see Advanced configuration for the XML collector.


  • ServiceSubscription: Comes from the CSA API as the response to a subscription detail request. Detail for each corresponding service request is then requested from CSA and added to the end of the ServiceSubscription content as a child node. The same is done for service instance data related to the subscription.
  • ServiceRequest: Contains a snapshot of the service offering pricing at the time of the request. This provides passthrough resource costs as part of the resulting CC Record data by using standard data mapping capabilities.
  • ServiceInstance: Contains component-level data of the actual service instance that was requested of the service provider. Collection of service instance data is optional because it considerably increases the volume of data coming from CSA and might not be needed in all cases. Service instance data could contain key values that can be used for generating lookup tables to support correlating provider data to CSA subscriptions. This is how MOE and vCenter data can be collected directly from the provider API and mapped to the appropriate account where corresponding subscription costs are contained.

Time and date

Each request contains all the current pricing and options selected along with a start time. It is Cloud Cruiser’s task to figure out the end time for each. Another request (modification) on the same subscription, or a cancelation request, will terminate a previous request. Otherwise, the request is assumed to still be in effect.

Use Convert to Start Event and Convert to End Event transformation steps to fill in missing usage start or usage end dates, depending on configuration.

Last modified



This page has no classifications.

 (c) Copyright 2017-2020 Hewlett Packard Enterprise Development LP