1. Running Multitenant Application in SAP HANA Cloud Platform
Nikhil Dhairyawan, Pankaj Kumar, SAP HANA Cloud Platform Product Management April, 2016

2. Concepts for Multitenancy

3. Multi-tenancy on SAP HANA Cloud Plaform
With SAP HANA Cloud Platform you can develop and run multi-tenant (tenant-aware) applications
Applications running on a shared compute unit that can be used by multiple consumers (tenants)
Each consumer accesses the application through a dedicated tenant-specific URL.

4. Understanding SAP HANA Cloud Platform Accounts
Users
Data
Configuration
Apps
Resources
Datacenter
Each account holds:
Resources that can be consumed by apps
Users allowed to work in the account
Apps deployed and running in the account
Data written by apps running in the account
Configuration for apps running in the account
Each account is assigned to a datacenter. *
Each account is fully isolated.
*) New datacenters in setup

5. Sub – Accounts Concept … DEV QA PRD Global Account Sub-Accounts
IdP
HANA
Destination
Java
VMs QA
IdP
HANA
Destination
Java
VMs
PRD
IdP
HANA
Destination
Java
VMs …
Datacenter

6. Pairing of Accounts with Backend Systems
PRD
HANA
Destination
Java
VMs
Java
DEV
VMs …
HANA
Destination
Cloud Connector
S/4HANA
Cloud Connector
S/4HANA …
DEV
PROD

7. Account and Quota Management
Created over Cloud Cockpit
1:1 mapping of SAP HANA Cloud Platform and cloud product accounts
Model your own release/testing process
Assigned Quotas, Resources and members
Flexibility and separation of concerns
Explain the 1:1 account mapping
Separate groups of people
Dev/test/prod with different people
Clean cut isolation
Same approach as SAP products -> separate accounts

8. Prerequisites for a Multitenant Application
Subscription = Contract between Consumer & Tenant
To be able to use a tenant-aware application, a consumer:
Must have an account for SAP HANA Cloud Platform
Must be subscribed to this application
Receives a dedicated URL where to access the application
Account Providers:
Must implement the Tenant API
The application is not deployed or run in the consumer account, instead only a subscription to the provider application is created. Therefore this consumer account does not require resources like compute units. Subscriptions allow the customer to configure certain features of the applications (like connection parameters, role assignments) and launch applications through consumer-specific URLs.
A subscription means that there is a contract between an application provider and a tenant who authorizes the tenant to use the provider's application.
Currently, you can trigger the subscription via the console client for testing purposes. For more information, see Providing Multitenant Applications to Tenants for Testing.
When an application is accessed via a consumer specific URL, the application environment is able to identify the current consumer. The application developer can use the tenant context API to retrieve and distinguish the tenant ID, which is the unique ID of the consumer. When developing tenant-aware applications, data isolation for different consumers is essential. It can be achieved by distinguishing the requests based on the tenant ID. There are also some specifics in the usage of different services when you develop your multitenant application.
Subscriptions represent applications that your account has purchased for use from an application provider. As the consumer account, you do not own, deploy, or operate these applications yourself. Subscriptions allow you to configure certain features of the applications and launch them through consumer-specific URLs.
You can subscribe an account to an application that is running in another account only if both accounts (provider and consumer account) belong to the same landscape.
In a provider-managed application scenario, each application consumer gets its own access URL for the provider application. To be able to use an application with a consumer-specific URL, the consumer must be subscribed to the provider application. When an application is launched via a consumer-specific URL, the tenant runtime is able to identify the current consumer of the application. The tenant runtime provides an API to retrieve the current application consumer. Each application consumer is identified by a unique ID which is called tenantId.

9. General Programming Guidelines for multitenant programming
Shared in-memory data such as Java static fields, caches, static tables will breach tenant isolation
Avoid any possibility that an application user can execute custom code in the application JVM, as this will certainly give them access to other tenants' data
Avoid any possibility that an application user can access a file system, as this will certainly give them access to other tenants' data.

10. Multitenant Core Services in HCP
Connectivity Service
Identity and Access Management Service
Persistency Service
Document Service
Keystore Service
Extensions service

11. Managing Connectivity in Multi-tenant Applications

12. Destination
Destinations are used for the outbound communication of a cloud application to a remote system
Contain connection details for remote communication
Contain symbolic names
The connectivity service resolves the destination at runtime based on the symbolic name provided
The currently supported destination types are HTTP, Mail and RFC.

13. Provider Specific Destination
A common shared destination (DestinationProvider=Application)
The destination is always read from the provider account

14. Consumer Specific Destinations
Resolution of destination by connectivity service
Subscription level of Consumer Account
Account level of consumer account
Application level of provider account
Applications which require connectivity to a remote service may use the connectivity service to configure the HTTP endpoint. In a multi-tenant application, such an endpoint can either be defined once by the application provider, or by each application consumer. If the application wants to use the same endpoint, independent from the current application consumer, the destination, which contains the configuration of endpoint, is uploaded once by the application provider. If the endpoint shall be different for each application consumer, the destination can be uploaded by each application consumer.
Destinations can be uploaded on account level, which means that the destination is visible for the whole account, or on subscription level, which means that the destination is only visible for the dedicated subscription. When the application accesses the destination at runtime, the Connectivity Service tries first to lookup the requested destination in the consumer account on subscription level. If no destination is available there, it’s checked if the destination is available on the account level of the consumer account. If there is still no destination available the fall back is to look into the application level of the provider account.
Provider Specific Destination
If an application consumer shall not be able to specify an endpoint for the provider application, the property “DestinationProvider=Application” can be set in the HTTP Destination. In this case the destination is always read from the provider application.

15. Destination visibility
Destinations visibility according to the level:
Destination uploaded on account level - it is visible for the whole account
Destination uploaded on subscription level - it is only visible for the dedicated subscription
Destination uploaded on application level - it is visible by all tenants and accounts, regardless their permission settings
Consumer account
Account
Subscription
overrides
Application
may override
Connectivity destinations are part of SAP HANA Cloud Platform connectivity service and are used for the outbound communication of a cloud application to a remote system. They contain the connection details for the remote communication of an application. Connectivity destinations are represented by symbolic names that are used by on-demand applications to refer to remote connections. The connectivity service resolves the destination at runtime based on the symbolic name provided. The result is an object that contains customer-specific configuration details, such as the URL of the remote system or service, the authentication type, and the relative credentials.
Destinations can be uploaded on account level, which means that the destination is visible for the whole account, or on subscription level, which means that the destination is only visible for the dedicated subscription. When the application accesses the destination at runtime, the Connectivity Service tries first to lookup the requested destination in the consumer account on subscription level. If no destination is available there, it’s checked if the destination is available on the account level of the consumer account. If there is still no destination available the fall back is to look into the application level of the provider account.
Provider account

16. SAP HANA Cloud Connector in multi-tenancy
HANA Cloud Platform
Tenant API
Consumer Account 1
Consumer Account 2
TenantID ..
Subscription
Subscription
Destination 2
TenantID 2
Destination 1
Provider Account
Application
Connectivity Service
TenantID 1
Customer 1 On-premise
Customer 2 On-premise
Firewall
SCC
SCC
ERP …
HCM … …

17. Managing Multi-tenancy in Identity & Access Management Service

18. Multi-tenancy in Identity & Access Management Service
Access rights are usually maintained by application provider
Application provider may provide predefined roles
Application consumer can assign users to these roles or create custom roles
Access rights for tenant-aware application are usually maintained by the application consumer, not by the application provider. An application provider may predefine roles in the web.xml when developing the application. By default, predefined roles are shared with all application consumers, but could also be made visible only to the provider account. Once a consumer is subscribed to this application, shared predefined roles become visible in the cockpit of the application consumer. Then, the application consumer can assign users to these roles to give them access to the provider application. In addition, application consumer accounts can add their own custom roles to the subscribed application. Custom roles are visible only within the application consumer account where they are created

19. Managing Scalability of Applications

20. Scaling Applications
Java Applications developed can run on one or more processes (VMs)
Compute Unit quota for an account determines the number of processes that can be started
One or more JVMs can be shared between all consumers in case of Multi-tenant applications
Scaling down with soft shutdown on application processes
Advantages:
Savings in resource costs
Manage failover scenarios
Savings in operational costs
A Java application developed on the SAP HANA Cloud Platform can run on one or more application processes (virtual machines). The use of multiple processes enables distribution of application load and provides failover capability. The number of processes that can be started depends on the compute unit quota (number of compute units) assigned to the account
In case of a multi-tenant application, one or more JVMs can be shared between all consumers as depicted in the diagram. This approach allows much better platform resource utilization. Especially smaller applications or scenarios where the peak load of the different consumers is distributed across the day will benefit from this approach with lower resource cost.
Advantages
 Savings in resource costs: The application provider may decide to share resources (for instance compute units) across multiple consumers to optimize the utilization of the resource and minimize the overall resource costs.
 Savings in operational costs: The application operator may upgrade the application to a newer version for all customers in one step instead of doing the almost identical upgrade for each customer individually, thus saving overall operational costs.

21. Data Isolation for Multi-Tenant Applications

22. Data Level Isolation using the Persistency service
Sharing a single database schema between all application consumers
Discriminatory field in each table
Tenant ID can be used as a value in discriminatory field
Each SQL statement should use the Tenant ID
Schema level isolation
A schema for each tenant bound to the application
The application uses JNDI to dynamically look up the data source
Multi-Data Container (MDC) isolation*
A DB container for each tenant bound to the application DB DB
In a multi-tenant application that stores data in a database, data from different consumers must be separated in the database. Data isolation in the persistence service can be achieved via a discriminator column in each table of the database schema. In this approach a single DB schema is shared between all application consumers. The tenant identifier provided by the Tenant Runtime can be used as value in the discriminator column. To ensure data separation in the application, each SQL statement must include the tenant identifier. To implement such a separation via a discriminator column, the multi-tenancy annotations of EclipseLink/JPA may be used. Entities which shall be tenant aware are annotated with annotation. The discriminator column is defined via annotation. As the length of the tenantId which is provided by the tenant runtime differs from the default length for the discriminator column in EclipseLink, its important set the correct length of 36 characters. When accessing data for a multitenant entity, the tenantId must be provided to the entity manager.
* Planned on HCP

23. Sharing a single database schema between all application consumers
To implement such a separation via a discriminator column, the multi-tenancy annotations of EclipseLink/JPA may be used. Entities which shall be tenant aware are annotated with annotation. The discriminator column is defined via annotation. As the length of the tenantId which is provided by the tenant runtime differs from the default length for the discriminator column in EclipseLink, its important set the correct length of 36 characters. When accessing data for a multitenant entity, the tenantId must be provided to the entity manager.

24. Database Specifics of Multi-Tenant Applications
Discriminator column isolation
Low footprint
Non-intrusive to introduce
Use stored procedures and prepared statements ONLY
No explicit SQL commands!
Tenant-specific backup/restore challenges
SAP HANA Cloud Platform
Multi-tenant Application DB

25. Schema level isolation
Schema isolation \ Multi DB Container isolation
Medium footprint
Minimal effort to adapt to
Leverage DB tools to manage tenancy
More control for backup/restore
SAP HANA Cloud Platform
Multi-tenant Application DB

26. Data Level Isolation Application Application JNDI
Consumer Account 1
Consumer Account 2
Consumer Account 1
Consumer Account 2
Subsciption
Subsciption
Subsciption
Subsciption
Provider Account
Provider Account
Application
Application
JNDI
Schema Isolation: With this approach, you create a new schema for each tenant, bind it to the application, and the application uses JNDI to dynamically look up the data source. The multitenant application must then use the appropriate data source when accessing tenant data. For more information, see Using Dynamic Data Source Lookup.
Using Dynamic Data Source Lookup:
The data source is determined dynamically at runtime and does not need to be defined beforehand in the web.xml or persistence.xml file. This allows you to bind additional schemas to an application and obtain the corresponding data source, without having to modify the application code or redeploy the application.
HANA Database
HANA Database
Schema
Tables with Tenant ID
Schema 1
Schema 2
Tables with
Tenant ID
Eclipse Link/PA User Guide
Dynamic Data Source Lookup

27. Multi-tenant Application
Dedicated Databases
Dedicated database instance
High cost and 100% isolation
Minimal effort to adapt to
Leverage DB tools for administration
Fine-grained control over data management
SAP HANA Cloud Platform
Multi-tenant Application DB DB

28. Multi-tenant Application
Multitenant Database Containers (MDC) Several tenant databases in a single database container
Planned
Multitenant database containers
A single database container = a tenant database
Run multiple tenant databases on one SAP HANA system (SID)
Run/support multiple applications/scenarios on one SAP HANA system (SID) in production
Strong separation of data and users
Application specific life cycle management
Resource management – allocate memory and/or CPU per tenant DB
Easy move of tenants/applications to different hosts/systems
Multi-tenant Application
SAP HANA Instance
Tenant DB 1
Tenant DB 2

29. Multi-tenant Applications with HCP Getting More Information
Testing multitenant applications

30. Thank you
Contact information:
Timo Renner
Title
Address
Phone number