Tenant Services Data Model

Table of Contents

Data Diagram
Key Domain Classes
- Tenant
- Application
- Catalog
- Customer
BLC Common Features

Data Diagram

The following data shows the key tables and persisted JSON structures used by the Tenant Service.

Key Domain Classes

Tenant

Tenant encapsulates information related to an isolated business in the system. Think of a tenant as a company that has its own data, backoffice, and customer-facing experiences. A tenant is never able to see or interact with another tenant’s data. All domain that implements the Trackable interface will define association with a particular tenant, which is the vehicle for enforcing isolation during queries in tenant aware resource tier services.

Application

Application defines a partition on which a unique combination of catalogs, pricing, offers, and assets may be discriminated. An application generally exposes an API whose responses are tuned to these unique characteristics. Application detection is generally used to identify the current catalog scope for a request, which in turn is used to automatically refine queries against domain implementing the CatalogTrackable interface. Furthermore, Application detection is used to automatically refine queries against domain implementing the ApplicationTrackable interface. The query refinement occurs in request flows in tenant aware resource tier services.

Catalog

Catalog defines a partition on which a combination of category and product or digital content related information may be discriminated. It is primarily a merchandising concept and allows configuration of related concepts into an inheritance tree. Application detection is generally used to identify the current catalog scope for a request, which in turn is used to automatically refine queries against domain implementing the CatalogTrackable or ProfileTrackable interfaces. The query refinement occurs in request flows in the catalog and content services.

Customer

The Application’s CUSTOMER_CONTEXT_ID identifies the set of customer accounts that are relevant for the Application.

There are three common options for populating this value:

Use a unique id for each Application to ensure that customers are unique to each Application. The easiest way to achieve this is to use the Application’s ID.
Use the same id for each of the Tenant’s Applications, so that customers are shared throughout the Tenant. The easiest way to achieve this is to use the Tenant’s ID.
Use the same id for specific sets of Applications, so that customers are shared throughout a subset of Applications.

BLC Common Features

Tenant Services uses the following Common Data Features which create additional tables within the Tenant Services data schema.

Application Trackable - Tenant Services uses the full complement of application trackable tables appropriately discriminate catalog relationships for marketplace applications.

Tenant Trackable - Tenant Services uses the full complement of tenant trackable tables appropriately discriminate application and catalog entities.

Durable Messaging - Employs DefaultNotificationHandler for sending sandbox transition messages with durable retry. Leverages BLC_NOTIFICATION_STATE table for message send acknowledgement.

Resource Locking - Employs ResourceLockRepository for transition resource locking to prevent collision. Also utilizes locking for message idempotency checking. Leverages BLC_RESOURCE_LOCK table.