In Exivity Services can be anything that corresponds to a SKU or sellable item from your Service Catalogue. It should relate to a consumption record (or multiple records) from your extracted data sources.
For example: with most public cloud providers, the provider defines the chargeable items that are shown on the end of month invoice. However, when working through a Managed Services Provider, a Cloud Services Provider or a System Integrator, additional services can be sold on top of those. Potentially, you may want to apply an uplift to the rate or charge a fixed amount of money every month for a certain service. Different scenario's are possible here, it all depends on your business logic.
A service is a named item with associated rates and/or costs used to calculate a charge that appears on a report, where rates represent revenue and costs represent overheads.
When discussing services and their related charges a number of terms are required. Exivity uses the following terminology in this regard:
When created during the ETL process, service definitions are created via the service and services statements in Transcript. During the execution of a Transcript task, service definitions created by these statements are cached in memory. Once the task has completed successfully, the cached services are written to the global database where they remain indefinitely (or until such time as they are manually deleted).
If the task does not complete successfully then the service definitions cached in memory are discarded, the expectation being that the task will be re-run after the error condition that caused it to fail has been rectified and the services will be written to the global database at that time.
There are different types of charge that can be associated with a service. Collectively these influence the total charge(s) shown on the report and Exivity supports the following charge types as described in the Terminology table above:
unit rate
fixed price
COGS rate
fixed COGS
At least one of these charge types must be associated with a service definition. Multiple combinations of the charge types may also be used.
Once the resulting charge has been calculated based on the charge types, it may be further modified through the application of adjustments, proration and minimum commit (all of which are detailed later in this article).
In order to calculate the charge(s) associated with usage of a service Exivity needs to know the period of time for which each payment is valid. For example a Virtual Machine may have a daily cost associated with it, in which case using it multiple times in a single day counts as a single unit of consumption whereas Network Bandwidth may be chargeable per Gigabyte and each gigabyte transferred is charged as it occurs.
The charge interval (also termed simply interval) for a service can be one of the following:
individually - the charge for a service is applied every time a unit of the service is consumed, with no regard for a charging interval
daily - the charge is applied once per day
monthly - the charge is applied once per calendar month
Although hourly charge intervals are not currently supported directly, it is possible to charge per hour by aggregating hourly records and using the EXIVITY_AGGR_COUNT column created during the process to determine the units of hourly consumption as a result.
Monthly services may be charged in one of two ways:
For each day of the month, a 'candidate' charge is calculated using Quantity * Unit Rate . The monthly charge will reflect the day of the month which resulted in the highest charge.
In the event that multiple days share the same highest charge then that charge will be associated with the first of those days seen, unless a subsequent day in that set has a higher quantity, in which case the charge will be associated with that subsequent day.
The average unit rate for those days where usage was seen in the month is calculated, and multiplied by the average quantity for each day in the month. When calculating the average quantity, any days for which there was no consumption are factored in as having a quantity of 0.
If Average Charging is applied in combination with proration, then the resulting average unit price as shown on reports may be less than you expect to see. This is because the average unit price as shown on the reports is calculated using charge / average_quantity and proration will reduce the charge if there was no consumption on one or more days of the month, resulting in a lower average unit price.
The minimum commit is the minimum number of units of consumption that are charged every interval, or (in the case of services with an interval of individually) every time the service is used. If fewer units than the minimum commit are actually consumed then the service will be charged as if the minimum commit number of units had been used.
After the charge for usage of a monthly service has been determined, it may be prorated by modifying that charge based on the frequency of the usage.
This process will reduce the charge based on the number of days within the month that the service was used. For example if consumption of a service with a monthly charge interval was only seen for 15 days within a 30 day calendar month then the final charge will be 1/2 of the monthly charge.
A service definition comprises two categories of information:
The service - Metadata describing fixed attributes of the service such as its name, description, group, interval, proration and charge type(s)
The rate revision - Information detailing the charge type(s) associated with the service (the rate, fixed price, COGS rate and fixed COGS values) and additional information detailing the date(s) for which those values should be applied
A service definition is associated with a specific a DSET as the units of consumption are retrieved from a column (named in the service definition itself) in usage data.
The following tables summarize the data members that comprise each of these categories:
The rate_col, fixed_price_col, cogs_col and fixed_cogs_col fields are used when the specific value to use is derived at report-time from the usage data, as opposed to explicitly being included in the rate revision itself.
A service may have any number of associated rate revisions so long as they have different effective_date or minimum commit values. This means that a service can have different charges applied depending on the date that the report is to be generated for, or depending on the specific values in the columns used by a report.
A service may use neither, either or both of rate and fixed_price, and neither or one of cogs and fixed_cogs. At least one of rate, fixed_price, cogs or fixed_cogs is required, but cogs and fixed_cogs may not both be used.
Any or all of rate, fixed_price, cogs and fixed_cogs may have a value of 0.0, in which case no charges will be leveraged against the service but the units of consumption will still be shown on reports.
Term
Synonym/Abbreviation
Meaning
service definition
service
A template defining the manner in which service instances should be charged
service instance
instance
Consumption of a service, associated with a unique value such as a VM ID, a VM hostname, a resource ID or any other distinguishing field in the usage data
unit of consumption
unit
The consumption of 1 quantity of a service instance
charge interval
interval
The period of time that a unit of consumption is charged over (additional units of the same service instance consumed within the charge interval do not increase the resulting charge)
unit rate
rate
The charge associated with 1 unit of consumption of a service instance in the charge interval
COGS rate
cogs
(Short for Cost Of Goods Sold) The cost (overhead) to the provider of a service for providing 1 unit of consumption of that service per charge interval
fixed price
fixed rate or interval-based rate
A specific amount charged per service instance per interval for one or more units of consumption
fixed COGS
interval-based COGS
A specific amount representing the overheads associated with providing one service instance of a service per charge interval
charge
A generic term to indicate some money payable by the consumer of service instances to the provider of those instances
Attribute
Purpose
key
A unique key (as a textual string) used to identify the service
description
A user-defined description or label for the service
group or category
An arbitrary label used to group services together
unit label
A label for the units of measure, such as 'GB' for storage
RDF or DSET
The DSET ID of the usage data against which the service is reported
usage_col
The name of the column in the usage data from which the number of units consumed can be derived
interval
The charging interval for the service, such as 'daily', 'monthly' etc.
proration or model
Whether the service is prorated or unprorated
charge model
(Monthly services only) Whether to use Peak or Average charging for the service
rate type
Which (if any) of rate and fixed rate to apply
cogs type
Which (if any) of cogs and fixed cogs to apply
Field
Description
rate
The cost per unit of consumption
rate_col
The name of a column containing the cost per unit of consumption
fixed_price
A fixed charge associated with use of the service per charging interval, regardless of the amount of usage
fixed_price_col
The name of a column containing the fixed charges as described above
cogs
(Short for Cost Of Goods Sold) The cost per unit associated with delivery of the service
cogs_col
The name of a column containing the COGS cost per unit
fixed_cogs
As for fixed_price but for the cost of delivering the service
fixed_cogs_col
The name of a column containing the fixed_cogs prices
effective_date
A date in yyyyMMdd format (stored internally as an integer) from which the rate is valid
minimum commit
The minimum commit value for the service (if this is 0 then no minimum commit is applied)
The graphical user interface of Exivity is a pure client-side application, which means it runs inside your web browser. It communicates with the Exivity REST-API to obtain data records, report data and general configuration. This means all functionality available in the GUI can also be accessed programmatically.
The interface allows you to do the following:
Develop extractors
Create transformer (ETL) tasks
Configure report definitions
Run graphical usage & costs reports
Run textual usage & costs reports
Manage users & roles
General configuration
White labeling
More features are added on a regular basis.
