Typically, a hosting platform contains the considered earlier OSS platform closely integrated with the BSS platform.
In this document:
BSS allows automating the whole provisioning scheme for companies of any size by means of a number of tightly integrated operations, including:
BSS gives comprehensive solutions for managing business by means of the following tools and mechanisms:
BSS leverages the hosting platform with the following functional parts:
There are many objects of the same kind in OSS and BSS that must by synced, for example, accounts, users, resource types (resources in BSS), service templates, and subscriptions.
Note
In the OSS/BSS pair, the BSS platform is the initiator of most operations, such as managing accounts, users, and subscriptions.
For example, if you need to manually create an account and a user with administration privileges in it, do it in the BSS provider control system. BSS will automatically request OSS to create the respective account and user.
There are many more BSS functions not mentioned here. Get more details in the Business Automation documentation.
You need to setup payment methods if you are going to test your application products with non-zero prices. For testing purposes, usually it is enough to use one or both of the following dummy payment methods.
In the BSS provider control panel, navigate to System > Settings and then in the Operations section click the Payment Processing link to start configuring payment methods.
To manage credit cards, the system requires you to generate encryption keys. For this, in the same Operations section, follow the Encryption Keys link to generate a pair of keys and load the private key to the system.
Note
Save and keep the private key on your local computer until you reinstall your test system.
BSS has the account hierarchy similar to the one used in OSS. However account properties in BSS are completely different since accounts are used to manage primarily business operations. In the BSS provider control panel, navigate to Operations > Customers to manage customer accounts.
Pay attention to the following account specifics in BSS important for testing applications:
This section is needed if you are going to test selling your application in the online store. Otherwise, you can skip it.
Online store is used to expose products, allow customers to order products, and initiate order processing in BSS. It is possible to set any number of online stores in BSS, but for testing purposes we consider using only one. In the BSS provider control panel, you can manage this store by navigating to Products > Online Store. Normally a provider initializes a store on a separate host.
The store initialization consists of two steps:
You will meet with the store configuration later in this document.
BSS extends the OSS resource model with one more entity - service plan.
A service plan is a commercial offer of hosting and cloud resources and services bundled and sold in packages. In a service plan, the provider defines prices and usage terms for the services. A service plan is always based on one service template, but there can be many service plans based on the same service template. For each service plan, you can also define the refund policy, subscription renewal settings, and billing algorithm to be used.
Published service plans become available in the online store and the customer control panel where customers are able to subscribe to a plan of their choice.
Service plans in BSS are products used to sell services to customers usually through an online store. The provider can also sell service plans using the BSS provider control panel.
Once the provider created or changed a service template in OSS, the latter automatically pushes the new service template or updates of an existing service template to the BSS system thus making the two service templates identical.
Note
If you have created a service template in OSS, you can update it later in OSS only. It is not possible to update such a service template using the BSS control panel.
A service plan is always based on a certain service template. It is possible to create several service plans based on the same service template. Service plans are pretty flexible, but we do not consider all details of them here. In the simplest case, when setting a service plan, the provider needs to configure at least one subscription period offered for a certain price, and this period should contain at least one billing period.
A subscription period specifies the period when a customer subscription based on this period is valid and the respective services are active (running). Once this period expires for a subscription, generally the subscriber has to pay for renewal of the subscription for the next period of the same length. A billing period specifies a period of generating invoices for consumed services or for services that the subscriber will consume during the next billing period. For example, a customer can buy a 3 month subscription that has 3 billing periods, 1 month each. In this case, the subscription is valid during 3 months, and the system will generate an invoice each month.
A service plan must be bound to a plan category the main purpose of which is to define the tax policy. To present a service plan in the online store for sale, the provider must include it into a sales category. When configuring the online store, the provider must add sales categories to respective screens where users can find them.
Using the online store, a user can find and order a service plan for an available subscription period. Once the order is placed, BSS starts its processing including payment and provisioning of services. During the service provisioning, BSS creates a subscription based on the selected service plan for the selected subscription period. It also requires OSS to create the subscription with the same ID as assigned to the new subscription on the BSS side. OSS creates the subscription based on the respective service template.
Note
BSS subscription and OSS subscription, although having the same ID, are completely different by nature. The former shows resources configured in the respective service template, and the latter is an actual contract between the customer and the provider. It shows the commercial parameters configured for the respective subscription period inside the respective service plan.
This section is needed if you are going to test selling your application in the online store. Otherwise, you can skip it.
In the previous basic product configuration, a service plan was able to sell resources with limits as specified in the respective service template. With this sales model, a service plan does not contain any resource configuration. Respectively, subscriptions on the BSS side do not contain any resources.
Often, providers use more flexible sales model that allows customers to define themselves the amount of resources they want to order. In other words, limits on resources must be defined not by a service template but by customers. To implement the add-on sales model, configure resource rates in the respective service plan.
With the above sample resource rate, the provider allows customers to select the limit on the number of virtual servers they are going to use in their subscription. The resource rate contains the following parameters:
The following diagram illustrated the sales and provisioning workflow.
Key differences are as follows.
This sales model, like the previous add-on sales model, uses resource rates to count some resources sold to each customer. Its key difference is that it does not set any limit on resource use.
Instead, it periodically meters the resource usage. To initiate this process, you need to make the resource measurable. For this purpose, open the resource rate in the edit mode and tick the Measurable property.
At the end of each billing period, the system generates an invoice charging the customer for the resources used during the passed period.
In the same product, it is possible to combine the sales models we considered in this document. For example, a cloud application provides virtual private servers (VPS). The sales model includes the following components in the service plan:
Resource Name | Resource Class | Limit | Sales Model |
---|---|---|---|
App instance | Application Service Reference | 1 | Zero price |
VPS management | Application Service | 1 | Fixed price |
VPS | Application Service | Metered, unlimited | Pay-as-you-go |
VPS silver configuration | Application Service Reference | Limited by resource rate | Add-on |
VPS gold configuration | Application Service Reference | Limited by resource rate | Add-on |
To this product, you would most probably add resource counters using the pay-as-you-go sales model.
The Business Support System platform ( allows creating a product containing a bunch of service plans. To achieved it, the provider declares at least one sales category as an up-sale category for the service plan that they configure. Since a sales category contains at least one service plan, the system will have a bunch of sales plans to offer to customers. When in the online store, a customer orders the service plan, the system prompts them to add the other service plans from the bunch to the order.
For proper functioning, many application services need to bind to domains. For example, a web site is usually available in the Internet through its domain name. Mail service cannot provide mail boxes without using a domain bound to this service. Selling bound services in a bunch helps the provider solve these requirements.
In the online store, a customer can select the parent service plan, for example, “Cloud Virtual Servers”, and then a child service plan, for example, “Registration in .test”.
To integrate BSS with an ERP system, the provider can assign Stock keeping units (SKU) to the billing items.
When configuring a service plan, the provider usually assigns fees to subscription periods, resource rates, and resource rate periods. For each of those three, the fees can be setup fee, recurring fee, and so on. Besides, a service plan may have fees for switching a subscription from another service plan to this service plan, plan switch fee, and for switching a resource rate, resource rate switch. Each of the above-mentioned fees may have a unique SKU or a SKU shared for several fees.
To set SKUs, follow these steps in the BSS control panel:
Allow SKU integration globally in the platform.
Click Add New SKU and create a unique SKU. Repeat this process until you have a list of unique SKUs.
Assign SKUs to the required billing items, either separately in a service plan profile or in the SKU settings using the proper tabs shown in the above screenshot.
A subscription denotes an amount of resources that are listed in the service plan and the respective service template, but that have already been provisioned to a customer (subscriber) and are managed by that customer.
The major operations with subscriptions are:
Some of these operations are manual, others are done automatically. Upgrade, downgrade, and cancellation are usually made by the subscription owner, that is by a customer, from the customer control panel. However, there are cases when the provider has to do it on behalf of the customer. The provider usually synchronizes the subscrisions with their service plan in a case the service plan is changed. Putting subscriptions on hold may be required due to administrative reasons and is done by the provider. Depending on the details of a particular integration, the provisioning of subscription resources can be automatic or require manual interference.