Usage

Updated: May 11, 2021
Contents

Introduction

Usage Management Module implements the direct flow of the consumption/metering/pay-as-you-go data communication from Vendors to Distributors. Usage flow is schematically illustrated with red color in the following diagram:

Usage flow is initiated by Vendors and is then used by Distributors for billing/reporting to their customers. Usage flow is common in various following business scenarios like Telecommunications, Infrastructure as a Service (IaaS), Platform as a Service (Paas), Internet of Things (IoT), Managed Services and many others:

Where the following technical steps need to be supported:

  1. Vendors report data representing how items are being consumed. This scenario is applicable to the Items of the Reservation type.
  2. Vendors report data specifically for billing purposes. This scenario is only applicable for items with the Pay-as-you-go items type and could be used at different layers
    • For billing between Vendors and Distributors
    • For billing between Distributors and their direct Customers
    • For billing between Distributors and their Resellers
    • For billing between Resellers and their Customers

Different aspects of the Usage Management are discussed in the following chapters of this article.

Video Tutorial

Product Capabilities

Not all Products support Usage-related scenarios, thus these capabilities need to be explicitly enabled in the Product Editor:

The following 3 capabilities define key aspects of the usage-related product scenarios:

  • Pay-as-you-go Support: This defines that Product has pay-as-you-go component, i.e. periodically submits Usage Files to the Distributor.
  • Usage Schema: An implemented schema that is explicitly declared in the product definition. Note that one product implements only one schema.
  • Dynamic Items: This defines that Product reports dynamic items in the Usage File, i.e. the ones that were not pre-declared in the Product Definition.

Subscription Relative Addressing

Usage data often needs to relate to different tiers in the distribution hierarchy. There are 2 possible ways of addressing in the hierarchy as schematically illustrated below:

  • Levels = addressing relative to the Top-level account in the system (blue in the diagram above)
    • Example: “Level 2” means 2 accounts below the “root” account of a given Hub.
  • Tiers = addressing relative to the Subscription (red in the diagram above)
    • Example: “Tier 1” means 1 account above the account that owns the subscription

While both technically make sense, only subscription-relative (tiers) allows vendors to not be dependent on the actual number of tiers and other specifics of the distribution channel of a given Distributor. Thus only subscription-relative (tiers) addressing is used by the CloudBlue Connect.

Usage Schemas

Any product definition in our ecosystem falls into 1 of the following usage reporting schemas supported by the CloudBlue Connect

  • Quantity – Distributors bill (rate) their customers based on the item-level quantity information that they receive from their Vendors
  • Price Rated – Distributors bill (rate) their customers based on the item-level Tier-0 (End-customer) Price Information that they receive from their Vendors
  • Cost Rated – Distributors bill (rate) their customers based on the item-level Level-0 (Distributor Cost) Price Information that they receive from their Vendors
  • Tiers Rated – Distributors bill (rate) their customers based on the item-level Price Information that they receive from their Vendors for multiple Tiers

Workflow

Usage management module implements the following workflow of interaction between Vendors and Distributors:

Where:

  1. Vendor systems are the source of Usage data in the format of the Vendor that can’t be processed by Connect yet
  2. Normalization to Connect schema(s)
  3. Normalized Usage File that implements Connect template and is uploaded by Vendor for processing
  4. The processed file generated by Connect that includes additional columns as a result of processing
  5. Distributor reviews and accepts or rejects usage file
  6. Export of records for billing either using record-level API calls or using bulk file export
  7. Data is used by Distributor to bill Customers or Resellers of their own
  8. Storing of reconciliation data either on a record-level or using the bulk file upload

With the following state-machine of the key objects:

Preconditions

Usage data can only be reported by Vendors when the following conditions are in place for a given Distributor:

  1. Active Program Contract
  2. Active Distribution Contract
  3. Active Listing for a given product in a required Marketplace

If these conditions are not met, usage reporting will not be allowed since reporting is always done in the scope of a particular distribution contract. Additionally, please note that reporting is only possible for:

  1. Assets that are part of a given distribution contract
  2. Asset must have items for which usage is reported

This process can be done either using the User Interface or using API, please refer to the separate article for an overview of APIs that can be used for usage reporting. In this article, we will focus on manual usage data reporting using the User Interface of the Vendor Portal.

More Information

Is this page helpful?
Translate with Google
Copied to clipboard