"Xtender" Data Exchanger

The Xtender ("cross-tenant data exchanger" ) engine allows clients with many tenants, who each use single tenant data sources, to use a single semantic model and analytics catalog across all tenants, by auto-switching the underlying data source for each tenant.

This functionality means that clients deploying a multi-tenant version of Pyramid with single tenant data source, do not need to replicate the data model and catalog for each individual customer - making deployments more efficient and easier.

Xtender only operates well if the reports and semantic model are virtually identical between customers. Automatic column handling in the semantic model may be able to account for some variations.

Note: The Xtender engine is licensed separately.

Why Xtender?

The following diagrams explain how Xtender may be used to simplify multi-tenant deployments with single data source tenancy.

Modern multi-tenant data architecture

The modern approach to multi-tenant analytics is to use a single data source that can be accessed by multiple tenants. Each tenant accesses the same analytic content and same semantic models, all pointing at the same database. Data security is delivered via row-level security. This is the ideal state.

Legacy multi-tenant data architecture

In the real world, data is not always sitting in a singular database. For reasons of performance, cost, and legacy, the data sources may be split up per customer, with each tenant accessing their own data through their own copy of the reports and semantic model. This approach usually requires the vendor to build a standard template of reports and models and replicate them out to each tenant. In Pyramid this can be done manually or automated using APIs (including the re-wiring of content to each database).

The "legacy" approach is still relevant if each customer has a bespoke data set or bespoke requirements.

Xtender Solutions

Xtender is designed to greatly simplify the preceding problem by offering an automated data source switch based on tenant. In this scenario, customers only need to deploy one set of reports and semantic models, and then auto-switch which database they operate against.

Xtender for "Data Sources"

The first Xtender type switches the data source instance based on each tenant. In this case, it is assumed that the database in each instance has the same name. This tends to be most useful in more modern, cloud-based sources. For example, multiple Snowflake instances - one per customer. Within each instance, there is a standard database "Sales_Transations".

 

Xtender for "Databases"

The second Xtender type switches the database used in a single instance based on each tenant. In this case it is assumed that the databases are identical, but each has a different name. This tends to be most useful in older, on-premises sources. For example, a single MS SQL Server instance with a different database per customer.

Xtender Combinations

Of course, there are scenarios where there is a need to switch on Xtender for both instances and databases.

Setup Flow

  • This guide describes the process of setting up Xtender in Pyramid visually.

Examples

For worked examples of Server and Database Xtender see Server Xtender and Database Xtender respectively.