Jump to: navigation, search

Subscription Design

The Billing Data Server (BDS) for premise customers follows the subscription design or model. This refers to the daily billing report/file being sent back to the Genesys billing systems in an automated way. The premise subscription billing includes:

  • A process for dispatching data files when ready
  • A process for ensuring data/file quality
  • Data transfer using ports 80 and 443, which is a recommended approach

The subscription design or model:

  • Is achieved by using a docker image, which contains BDS, and which runs on premise customers' hardware.
  • Supports all tenants, whether they can open connections to Genesys (online) and those that send in their usage data to Genesys manually through other channels (offline).

BDS - P refers to the version of BDS running on premise. It only contains extract and transform stages. Interaction of platform and cloud goes by https protocol.

BDS - P generates billing data files on transform stage, saves them into local folder on Docker host and (in online mode only) uploads them to S3.

BDS - C refers to the version of BDS running on the Cloud. It contains only loader stage. Here generated files are validated and uploaded to IT department through Secure File Transfer Protocol (SFTP).

Provisioning workflow

This section describes how BDS is implemented.

For all deployments

  1. Docker image with BDS is created, based on approved official Alpine image.
  2. Configuration template for subscription customers is created (single tenant, single region, single location).

For each online tenant, on Genesys side

  1. Finance sends information about new subscription tenant.
  2. IAM username is provisioned for the tenant, initially by the BDS team (with OPS support) and later to be automated.
  3. S3 folder is created for tenant's usage data (by creating an empty .keep file). Tenant's IAM user is granted 'read/write' on that folder, initially by the BDS team (with OPS support) and later to be automated.

For each tenant, both online and offline, on tenant's premise

  1. Professional Services (PS) edit BDS configuration template, putting in proper GIM credentials, IAM keys, and so on.
  2. PS install Docker on host server.
  3. PS install docker image, provisioning it with configuration template, and local file directory for file storage.
  4. PS configure host server's scheduler (for example, cron) to run the container once per day.

Runtime workflow on premise (both online and offline)

BDS-P is distinct in the following ways:

  1. Zookeeper is not used for configuration, only for locks.
  2. Configuration is read from json file generated by PS from template.
  3. Extraction results are stored on local file system, not on S3.
  4. Transformation results are stored on local file system, not on S3. In online mode, BDS uploads billing data files on S3.

Specific to online tenants

Transform saves usage files to host file system (mapped to a directory in container) and, as additional step to S3, there is no loader step.

Specific to offline tenants

Once transform saves usage files to host file system, there are no further steps for BDS.

Runtime workflow on Genesys side (online only)

  1. BDS reads new usage files from every tenant's S3 folder and uploads the files through SFTP.
  2. Email alerts are generated when there is no new data for a tenant for over a day.


Each tenant should have IAM Amazon user name which will allow Genesys to give isolated URL to access for tenant config. Admins will setup user policy on Amazon s3 bucket cloudbilling-us-west-1 under /transform_premise/<tenant name> for each tenant. Each tenant will have access to their own folder to which the tenant will upload files. Each tenant has one folder for write purpose.


Comment on this article:

blog comments powered by Disqus
This page was last modified on 28 March 2018, at 13:00.