Fundamentals of Multitenancy in SAP BTP

[Raja]

Introduction

Multitenancy is one of the important architectural concept in cloud. In SAP BTP, we can develop and run multitenant applications, and share them with multiple customers simultaneously.

 

This blog is targeted mainly for SAP developers, architects and consultants who wants to become expert in multitenancy concepts and build a full-stack multitenant business application.

After finishing this blog, you will have a crystal-clear understanding of multitenancy in SAP BTP. Further, you will also find resources to help you build, deploy, and run multitenant apps in SAP BTP.

 

Note: If you are new to SAP BTP and looking for a simple explanation of what it is and what problem it solves, see Explaining SAP Business Technology Platform (SAP BTP) to a Beginner

 

let's get started!

What is Multitenancy?

Multi-tenancy is an architecture in which:

• A single instance of an application serves multiple customers


• Each customer is called a tenant


• Multiple customers (tenants) use the same computing resources – physically integrated but logically separated


• Even though customers share resources, customers aren't aware of each other, and their data is kept totally separate

An Analogy of Multitenancy from Real-life

To understand multitenancy, let’s take a real-life analogy. Think how a bank works.

• Multiple people can store their money in one bank


• Their assets are separate even though they're stored in the same place


• Customers of the bank don't interact with each other, don't have access to other customers' money, and aren't even aware of each other

 

Similarly, in multitenancy, customers use the same application instance, share resources – while keeping their data separate and secure.

Benefits of Multitenancy

Following are the major benefits of multitenancy.

Save Money

Multitenant architecture enables sharing of services, databases, resources, and applications. Hence a cloud vendor can offer their solution to many customers at a much lower cost than if each customer required their own dedicated infrastructure.

More flexibility

If a customer invests in its own infrastructure, it might reach capacity during times of high demand or sit idle during times of slow demand. In multitenancy, resources are shared among customers. Hence as a customer, you can access extra capacity when you need it, and not pay for it when you don’t.

Easy/Efficient Maintenance

Multitenancy reduces the need for individual customers to handle updates and maintenance. The vendor takes care of maintaining and updating the multitenant application, managing infrastructure, thus removing additional overhead from customers.

 

When You may Prefer Single-tenant Architecture

In some scenarios, you may have to go with single-tenant architecture despite all the benefits from multitenancy.

Some organizations may not be able to store data within shared infrastructure, no matter how secure it is, due to regulatory requirements.

Additionally, security problems or corrupted data from one tenant could spread to other tenants on the same infrastructure. Although in practice these risks are extremely rare and shouldn't occur if the cloud vendor has configured their infrastructure correctly.

 

Multitenancy in SAP BTP

SAP Business Technology Platform provides out-of-the-box support for multitenancy. There are services and frameworks which helps us build a multitenant application with minimal effort.

Let’s first see how a single-tenant application differs from multitenant application in BTP.

 

Use case

An SAP Partner has built an application on SAP BTP. The partner needs to sell this solution to their customers. In this case, SAP Partner is Application Provider. The customer who buys application from the partner is referred as Application Consumer.

 

Scenario 1: Single-tenant App in BTP

The Application Provider

• Develops the app in a BTP subaccount (say developer subaccount)


• Sells the licenses to customer and provides the deployable artifacts to customer

 

The Application Consumer

• Procures the deployable artifacts


• Deploys app in their BTP subaccount


• Consumes application


• Pays for BTP resources to SAP

 

In the single-tenant scenario:

• It’s customer’s responsibility to deploy and maintain the application on BTP.


• Each customer has its own BTP resources.


• There is no resource sharing among customers.

 

Scenario 2: Multitenant App in BTP

 

The Application Provider

• Develops the app in a BTP subaccount


• Publishes the app to consumers


• Pays for BTP resources to SAP

 

The Application Consumer

• Procures the license to use app


• Subscribe to the app from a consumer subaccount


• Consumes the app

 

In the multitenancy scenario:

• It’s application provider’s responsibility to deploy and maintain the application on BTP.


• Application provider pays for the BTP resources.


• Customers only subscribe and use the app.


• Resources are shared among customers, but each customer’s data is separated securely

 

Below image may help you to understand the relationship between application provider and application consumer.

 

How does Application Consumer Access Multitenant App?

To use a multitenant application on SAP BTP, the application provider must ensure that each consumer:

• Has a dedicated subaccount in the application provider’s global account.

• Subscribes to the application using either the SAP BTP cockpit, SAP BTP command-line interface, or a dedicated REST API.


• Receives a dedicated URL so that its business users can access the application.

 

The resources consumed by multitenant app in SAP BTP, for example compute units, storage, services are managed by the application providers. The cost of these resources and those of application consumers are billed to provider of the multitenant application.

 

Let’s have a glimpse of how this works.

I have created a multitenant app called “My Multitenant App”. This app is deployed in a BTP subaccount called “Provider Account” as shown below.

 

In the same Global Account, there is another subaccount called “Consumer1”.  If we go to Service Marketplace of Consumer1 subaccount, we can view the multitenant app published as a Tile.

 

To subscribe this app from Consumer1, click on the Create button as shown in image below.

Finally, we will have the subscription created and a unique URL provided to access this multitenant app. Now we can access the subscribed app from Consumer1 using this subscription as shown below.

SAP SaaS Provisioning service

SAP SaaS Provisioning service is the most important SAP BTP service for multitenancy.

Once the multitenant app is developed, application provider needs to make it available for consumer by publishing it.

In the example mentioned before, the multitenant app is available for subscription in Consumer1 subaccount’s Service Marketplace. This is done by using SAP SaaS Provisioning service.

 

Important points regarding SAP SaaS Provisioning service:

• SAP SaaS Provisioning service acts as a registry and helps us to publish the multitenant app to consumers.


• It also enables us to automate the subscription and unsubscription process.


• The service also maintains a list of all dependencies and subscriptions of an application.

 

To register the multitenant app with the SaaS Provisioning service, we need to:

• Create a service instance of the SaaS Provisioning service (aka saas_registry)


• And bind it to the application

Below image shows an example code snippet on how to register multitenant app with SaaS Provisioning service in case of a CAP Multi-Target Application.

 Note: At this point, you may skip this coding details if seems too complex.

 

BTP Components/Services Required to Run a Multitenant App

Let’s briefly look into the components that are needed for a multitenant app to run in the Cloud Foundry environment in SAP BTP.

Provider Subaccount

SAP BTP subaccount where multitenant application is deployed.

Consumer Subaccount

SAP BTP subaccount from where we subscribe and use a multitenant application.

The Application Provider (the owner of the multitenant application) owns the global account and the provider and consumer subaccounts.

SAP SaaS Provisioning service

SAP SaaS Provisioning service is where Application Provider registers the multitenant app to publish it for consumers. This service enables us to automate the subscription process.

XSUAA service

The XSUAA service is used for authentication and authorization.

App Router

The application uses tenant-aware App Router service, which is the single point-of-entry for the applications.

 

Each multitenant application must deploy its own application router, and the application router handles requests of all tenants to the application.

 

Tenant Onboarding

When a consumer subscribes the multitenant application, the application must be notified that there is a new consumer.

As part of the application subscription, SAP SaaS Provisioning service provides two callbacks:

getDependencies

This provides dependencies to multitenant reuse services

onSubscription

This allows applications to perform the tenant setup in the application. The implementation depends on the approach to separation that you use for your application.

 

These callbacks help to achieve the tenant onboarding. For example, whenever a consumer subscribes an application, this callback allows the application to perform tenant-specific onboarding steps, e.g. creating a new HANA schema.

 

The tenant onboarding call flow works as follows:

1. From the consumers subaccount the subscription is initiated.


2. Recursively, getDependencies callback is called, first for the application and then for all its dependent services and their dependencies.


3. After the complete dependency tree is built, the onSubscription callback is called.


4. After the tenant-specific persistence, if at all needed, and configuration is created, the application returns the tenant-specific application URL

Tenant Offboarding

When a consumer unsubscribes the multitenant application, there must be a notification sent to the application, which allows you to take care of data deletion and other clean-up activities.

 

Same onSubscription callback is triggered for offboarding, but with the HTTP “DELETE” method to indicate that this tenant must be removed. Once again, the offboarding call is also provided to all the dependent multitenant services that are used by your application.

 

Tenant Identification by Multitenant App

In SAP BTP, every subaccount has a subdomain and a tenant ID as shown below.

 

The Subdomain is unique across all subaccounts in the same region.

The Tenant ID is an UUID (Universal Unique Identifier).

When a consumer subaccount subscribes the application, it gets its own URL that follows the below pattern.

<tenant>-<app-name>.<cfapps>.<region><hana.onedemand.com>

 

Below image shows an example.

For multitenant application, the App Router determines the tenant-specific subdomain out of the URL and then forwards the authentication request to the tenant XSUAA service.

This determination is done by using a regular expression defined in the environment variable TENANT_HOST_PATTERN.

 

What is the significance of TENANT_HOST_PATTERN?

The TENANT_HOST_PATTERN is:

• used in mta.yml file (or manifest.yml file)


• used by App Router


• to identify the tenant that is accessing the application

Each consumer accesses the SaaS Application through a unique URL. To ensure that these requests come to the target application, we define a tenant host pattern for our app router app.

Example:

TENANT_HOST_PATTERN: ^(.*)-${space}-${app-name}.${default-domain}

 

Actual Route for consumer account would be like:

https:// consumer1-app-name.cfapps.us10.hana.ondemand.com



https:// consumer2-app-name.cfapps.us10.hana.ondemand.com

 

Regex placeholder is required because numerous consumer accounts can subscribe to the application and their subdomain is not known beforehand.

 

We can use, more specific or more open regex patter also, but not suggested. Below examples would work but is not recommended.

 

TENANT_HOST_PATTERN: "^(.*)-approuter-app-name.cfapps.eu10.hana.ondemand.com"



OR



TENANT_HOST_PATTERN: '^(.*).n'

 

Tenant mode configuration in xs-security.json

To use a multitenant application router, we must have a shared UAA service. Hence, for multitenant apps, we configure the tenant mode in the xs-security.json as “shared”.

 

{

    "xsappname": "myapp-multitenant",

    "tenant-mode": "shared",

}

 

Data Separation in Multitenancy

There are different ways to achieve data separation in multitenancy. I will use SAP HANA Cloud as an example to explain, however the concepts remain same for any other database.

 

There are mainly 3 ways to achieve data separation.

1. Discriminator Column


2. Schema Separation


3. Database Instance Separation

Discriminator Column

• Tables are shared between tenants, so you have one set of tables for the application


• Simple and straightforward to define


• A column in each table which effectively identifies the tenant id


• At the application level you need to filter on tenant id for every CRUD operation. For example, when you are implementing INSERT or SELECT, you need to have a WHERE clause on TENANT ID.

• Doesn't cost that much because you're just using a single schema potentially in a single database instance


• High risk because it's very easy for you to make a mistake

 

Schema Separation

• A dedicated schema or if it's HANA an HDI Container.


• Recommended approach by sap.


• Very flexible - you can have a single database instance, for example a single HANA Cloud instance. Each tenant will get their own dedicated HDI Container. So effective their own schema and tables.


• Can easily backup individual schemes or HDI containers.


• In terms of cost, you're still working with a single HANA instance or a single database instance so not much effect on cost.

 

Database Instance Separation

• Technically, this is true data separation. A completely dedicated HANA cloud instance or whatever database you want to work with instance for each tenant.


• More expensive.


• You get a complete level of separation


• Straightforward and simple backups because you're taking the entire database instance each time.

There's no strict right or wrong way, it's just a question of finding what's the most suitable and appropriate way for your application.

 

I believe now you have got clear understanding of multitenancy in SAP BTP.

 

If you have any queries, let me know in comment or get in touch with me at LinkedIn!

 

What’s next?

Check the below materials to build your own multitenant applications.

Develop Multitenant Applications in the Cloud Foundry Environment

BTP Multitenant: SAP HANA Academy

Develop and Register Multitenant Application in the SAP BTP Kyma Runtime

 

Join me on  LinkedIn for more such insights on SAP and AI!