Developing multi-tenant applications on HCP – Application Overview(Part 2)
As outlined in the Introduction blog, ITeLO Consulting has developed a pollution monitoring SaaS application. To provide this as a multi-tenant SaaS to its customers, ITeLO must make use of the multi-tenant capabilities of HCP.
In this blog, we will get a high level understanding of the application and its architecture.
It is a pollution monitoring application that helps Oil & Gas companies compare air quality onsite (at the plant) vs. the air quality at the city/region (where the plant is located). The idea is to determine the pollution levels due to emissions from the plant. To get an idea of the scale of operations within the plant, information such as – number of workers in the plant and area of the plant – is also shown.
The application provides role based access so the logged in user sees different data depending on his role. There are 2 roles used in the application:
- Plant Supervisor responsible for a specific plant; sees air quality data only for his plant.
- Area Manager responsible for an area that can contain multiple plants. He sees air quality data for all plants within his area.
The application has various components/layers – an important design principle for such an application is to ensure tenant isolation across various layers/services.
As described in the previous blog, there are 3 HCP accounts managed by ITeLO Consulting:
‘ITeLO Consulting (Provider)’ account
This is the provider account in which the database, business logic and user interface applications are running.
The air pollution data of each plant is stored in the HANA DB using HCP Persistence Service. The data of different tenants are kept separate by using the tenant isolation features provided by JPA.
The business logic is defined in the Java application which runs in the provider account. The same instance of the Java application is run for different tenants. Each tenant creates a subscription to this Java application and gets a unique consumer access URL. This is the URL that will be used by end users to access the application.
Whenever the application is accessed using this URL, HCP can extract the tenant ID that can be used to identify the tenant in the application logic. As one example, we will see how such a tenant ID can be used to isolate tenant data stored in the database in the upcoming blogs.
The UI logic is defined in an HTML5 application that runs on the provider account. Just like the Java application, the same instance of the HTML5 application is run for different tenants. And the application is accessed using a unique consumer access URL.
‘ABC PetroCorp (Consumer)’ account
This is the consumer account for ABC PetroCorp in which subscriptions are created and tenant specific configurations – such as the Identity Provider and connectivity to on-premise services – are made.
Remember that the Java/HTML5 applications are not deployed or copied to this account.
Identity and Access Management
Only employees of ABC PetroCorp should be allowed to access the subscribed applications.
ABC PetroCorp has its own Identity Provider (SAP HANA Cloud Identity Authentication service) that contains information about their employees such as name, email id, organization, role etc. This Identity Provider will be configured in the ABC PetroCorp (Consumer) account such that the subscribed applications can be accessed only by their employees.
ABC PetroCorp has on –premise services running within their landscape that provide information about their plants – details like no. of workers at each plant, area of the plant etc. All this information has to be pulled from their landscape and provided to the subscribed application using the SAP Cloud Connector.
‘XYZ EnergyCorp (Consumer)’ account
Consumer account for XYZ EnergyCorp. Similar to the ABC PetroCorp (Consumer) account.
- We looked at functionality of the pollution monitoring application.
- We looked at HCP services & capabilities that ITeLO Consulting used for building the multitenant application.
In the next blog, we will provide step-by-step instructions of setting up such an account landscape with provider and consumer accounts.
I got a question concerning the Database part of your blog post.
You refer to the SAP Documentation that suggest the two alternatives of seperating the tenant data: a discriminator column or a seperate schema for each tenant.
But I see some issues with both of these approaches:
Use a separate schema for each tenant:
Use a discriminator column in each table storing tenant data:
So when it comes to data isolation the schema approach is of course the more obvious approach, but can you suggest a way to do this without having the persistence units in the code? Is there a way in HCP to create persistence units on the fly via configuration?
How would you handle the tenant data seperation for an app with lots of customers?
Thanks for your interest in the topic! Stay tuned for the next blog in the series on bringing in multitenancy in the persistence layer. Most of your questions will be answered 🙂
As promised, Part 4 of the blog series has just been published.
Hope this helps in clarifying atleast some of your queries.
yes thank you. Looks quiet interesting.
I'll have a look and evaluate the solutions, specially the TenantTableDiscriminator with Type Schema.
Is there a timeplan for when the GA Release of the MDC Feature is planned?
As of now, we do not have a date set for the GA of HANA MDC on HCP.
Watch out for announcements around, late Q1 next year.
If the cusumer can subscrible the application more than one time? Like if there is a partner who has a partner account, and he need to provide two application for A and B customer since the customer don't have their own account. So partner need to subscible the application two times and do different configuation (like different data connnection), and then hand it to A and B. Do you think it is possible and how? Thanks.