Multi-Tenancy Architecture on SAP Cloud Platform, Cloud Foundry Environment
In this article, We’ll offer you insights into the architecture behind multi-tenancy on SAP Cloud System, Cloud Foundry atmosphere. We’ll begin with a short interpretation of multi-tenancy terminology, cover how tenants (application customers) are onboarded or subscribed to a multitenant application, then We’ll move on to the multi-tenant application runtime, and end with offboarding or unsubscribing a tenant. We’ll also outline additional aspects that you need to consider when you develop a multi-tenant solution.
There is already a blog about how to create multitenant applications on the SAP Cloud Platform in the Cloud Foundry environment. If you aren’t accustomed to it yet, We highly recommend that you read it first as it’ll provide you with a better understanding of how you can realize multi-tenancy for your business applications on the SAP Cloud Platform.
What is multi-tenancy?
Multitenancy refers to a software application architecture, in which tenants share the exact same technological resources, but maintain the data divided and identification and gain access to governance for each tenant isolated.
We need to differentiate between 2 kinds of tenants when discussing multi-tenancy:
- Platform-as-a-Service (PaaS) tenants: Application carriers obtain separated system sources to create business applications, either for their own use or multitenant SaaS applications that can subsequently be provided to other SaaS tenants.
- Software-as-a-Service (SaaS) tenants: These tenants gain access to multitenant applications or solutions to which they are subscribed. In SAP Cloud System, Cloud Foundry environment you can develop and deploy a single event of the application that offers multiple users.
Both tenants are represented as subaccounts, the PaaS tenants in addition have accessibility to the platform-specific runtime atmosphere, e.g., Cloud Foundry.
Application provisioning
After the multi-tenant application is developed, the programmer has to register it to the SaaS Provisioning service (saas-registry), to ensure that SaaS tenants can register for it. You can find details in Register the Multitenant Business Application to the SaaS Provisioning Solution on the SAP Help Portal.
Tenant Onboarding
Now, when your application is available for membership by SaaS tenants, the application must be notified that there is a new customer. Refer to Getting Started with Business Application Subscriptions in the Cloud Foundry Setting on the SAP Help Portal, to get more info about how SaaS subscriptions can be developed.
As part of the application SaaS tenant enrollment, 2 callbacks are supplied:
- get dependencies: This gives dependencies to multitenant reuse services.
- on Subscription: This allows applications to perform the tenant arrangement in the application. The execution relies on the approach to the separation that you use for your application.
The tenant onboarding flow looks as follows:
From the customer’s subaccount, the subscription is initiated to the SAP Cloud Platform. Recursively, the get dependencies() callback is called, initially for the application and then for all its reliant services and their dependencies. After the complete reliance tree is developed, the on Subscription() callback is called, starting from the lowest leaf until it gets to the application. After the tenant-specific persistence, if at all needed, and the configuration is created, the application returns the tenant-specific application LINK that is provided in the SAP Cloud System cabin.
To get more information about how to create SaaS registrations in the SAP Cloud Platform cabin, read Beginning with Business Application Memberships in the Cloud Foundry atmosphere on the SAP Help Portal.
Example for data separation with SAP HANA
The blog We pointed out earlier describes the various options you have for separating data for your tenants, relying on your needs. For the majority of situations, we advise choosing the schema separation as it gives the most effective concession between the level of separation and the costs associated with it. In this next figure, you can see exactly how you would certainly recognize the schema separation with SAP HANA:
For every tenant, there is a different HANA HDI container. An HDI container gives a database schema and additional support for the model-driven deployment of database artifacts. These HDI containers need to be mapped dynamically in your application, which means that you have to map the subaccount identifier to the matching HDI container. If your application also needs to store data that is shared by all the tenants, we propose a separate HDI container to host this data.
For even more HDI-related information, you can review HDI Containers on the SAP Help Portal.
Tenant Recognition
To review or save tenant-specific information, the application has to get the subaccount identifier during the runtime. Hence, each tenant gets their own LINK that follows the pattern for the development of multitenant applications:
<tenant>-<app-name>.<CFapp-domain>
You have to configure this pattern within the application-specific application router. To learn more about this task, see Application Router Multitenancy on the SAP Help Portal.
Additionally, you should set up the tenant mode in the xs-security. JSON as “shared”. In this setting, the client secret equals all subaccounts that register for this application. It requires the app router variable “TENANT_HOST_PATTERN” (see above for details) and the corresponding path to be mapped.
Finally, you need to set the tenant-specific route to your application with the Cloud Foundry command-line user interface (cf CLI):
cf map-route <approuter-name-of-your-application> <CFapp-domain> -n <subdomain>-<approuter-host-of-your-application>
For effective usage, you would use a slightly different pattern that separates the tenant and the application names into different subdomains. As a consequence, you would certainly not have to produce paths per lessee, however, you would utilize a generic wildcard route. However, it additionally requires you to create a personalized license for the application, which is something that you would commonly not do throughout growth.
When a user of your customer accesses your application in the internet browser, the application router acquires the renter from this LINK and calls the tenant-aware UAA (individual account and also verification solution) that is responsible for verification of the end individual. The UAA reads the occupant, looks up the equivalent UAA identity area that is set up for this occupant, as well as delegates the verification to the IdP that is set up there. After that, it provides a JSON Web Token (JWT) which contains the subaccount ID for this tenant, the current individual, and the consent scopes of the individual digitally signed. The JWT is then returned to the application router, and from there to the application. When the application needs reliant services internally, it verifies this again with a JWT that contains the same tenant, and hence the tenant is circulated with the complete stack. For more about authorization management, read Authorization and Trust Management in the Cloud Foundry Environment on the SAP Help Portal.
Whenever your multitenant application needs a globally unique subaccount identifier, it can read it from the JWT.
The detailed flow looks like this:
Tenant Offboarding.
When a SaaS tenant is unsubscribed from your application, there needs to be a notice also, which enables you to ensure data deletion and other cleanup tasks. There is the same subscription callback activated as for onboarding, yet this time with the HTTP method “REMOVE” to indicate that this tenant must be eliminated. Once again, the offboarding call is also offered to all the dependent multi-tenant solutions that are used by your application.
Multitenancy with Business Solutions.
Until now, We’ve talked largely about multi-tenant applications, however, there are also recyclable business solutions that may be tenant-aware. An application normally combines several businesses by binding to service instances of these solutions and subscribed to by tenants.
A service provides well-defined reuse business performance for programmatic use through APIs. Services can implement data separation along with both dimensions instance and tenant as shown below:
I. Solution without data separation
The service is not tenant-aware and stores the data without tenant and service separation. For that reason, the application binds against one solution instance and attaches to the service circumstances with a technical customer.
II. Technical service with application data seclusion.
The solution is not tenant-aware, yet it understands the data isolation per solution instance. Applications can understand tenant separation by developing numerous service instances that need to be taken care of by the application itself. As the tenant does not require to be identified, technical users with basic authentication are sufficient.
Solutions that use containers to isolate information by solution circumstances can utilize the Cloud Factory service broker APIs to create or remove a container when a service instance is created or erased.
III. Tenant-aware solution with data shared across applications.
The solution is tenant-aware and is invoked with a business user. Thus, the solution manages the tenant separation by itself and the data of one tenant is shared across the various applications.
Such a service is applicable for the tenant onboarding outlined for applications. This means there will be an onboarding callback in which the solution should instantiate its tenant-specific storage. In case of numerous onboarding calls due to usage by numerous applications, just one container shall be created.
IV. Tenant-aware services with application data isolation.
The solution is tenant-aware and invoked with a business user. On top of that, the data is separated by service instances. This is normally one of the most complicated options. If required, it can be recognized either by having a different storage per tenant and a discriminator column for keeping the service circumstances or the other way around. For the first option, the regular tenant onboarding callback can be used to create the storage, for the latter one the creation of the service instances could serve as a trigger.
If a consuming application needs to be determined in the perseverance of service, the solution instances ID (can be read from the JWT) should be used as the only identification of the consumer.
This figure shows the consumption options that we have just outlined.
Click here to know more: https://zarantech.teachable.com/p/sap-s4-hana-finance-training
Summary
We hope we covered all the topics related to Multitenancy Architecture on the SAP Cloud Platform. For questions or added info on this subject, you can visit our website.
Our article is a great area to get going when it comes to learning more about the power of the SAP Cloud Platform. Also, if you want to learn more, we are here to help you.
At ZaranTech we offer self-paced online training programs on market-relevant SAP topics. Enroll with us and skyrocket our careers.
Get any SAP video course — https://zarantech.teachable.com/courses/category/sap
Join SAP Learner Community on Linkedin — https://www.linkedin.com/showcase/sap-learner-community/
