Hello and welcome to the second part of the blog post series on building your own multitenant SaaS application on SAP BTP using CAP. As mentioned in the overview blog post Multitenant SaaS applications on SAP BTP using CAP? Tried-and-True! by Martin Frick, this is the second blog post of the series summarizing the Basic Scope.   

In today’s journey, you will learn how to develop a multitenant SaaS application that meets certain basic Software as a Service requirements (mentioned below). It is called the “Basic Scope” because anyone who has access to an SAP BTP Trial account or an SAP BTP Pay-As-You-Go (PAYG) account can join this journey. (PAYG account owners are able to run this sample for completely free thanks to the available free-tier services).

For the source code repository, click here.  

Firstly, you will understand the scenario and the requirements of the SAP sample partner CaveStone for such a SaaS application. Then you will move on to the architectural solution diagram, and finally, you will be reading about the implementation overview of the solution.   

Scenario & Requirements   

Many SAP BTP partners and customers require an application that can be reused by their own customers or internal stakeholders.   

Let’s imagine the sample SAP partner CaveStone, wants to create a cool new multitenant SaaS application and sell the solution to its valued customers. Before directly jumping into a productive development phase, CaveStone wants to get an idea of how to deploy multitenant SaaS applications in SAP BTP and intends to validate some integration scenarios with SAP and third-party systems.  

All in all, the sample customer has the following requirements:  

1. A multitenant SaaS application with automated tenant on and offboarding with minimum manual effort 
2. Data isolation across consumer tenants  
3. A multitenant SaaS API (Application Programming Interface) for integrating third-party systems  
4. In-app user management for each consumer tenant  
5. Autoscaling of the application components 
6. Application logging  
7. Real-time notifications about events that may be of interest to the business and operations  
8. A place to store application credentials securely  
9. A frontend application which is compliant with SAP Fiori Design Guidelines  

Well, that sample SAP partner sounds like a perfect candidate to validate the Basic Scope of our sustainability SaaS (Susaas) sample scenario which luckily covers all these requirements in great detail!   

Implementation & Highlights

As explained in the overview blog post, the sample repository consists of three branches.  

1. main: Branch for documentation 
2. basic: Branch for the basic version of the sample SaaS application that can run in SAP BTP Trial accounts and SAP BTP PAYG accounts with available free-tier services
3. advanced: Branch for the advanced version of the sample SaaS application requiring an SAP Free Tier or Enterprise account  

As mentioned in the introduction, this blog post will be focusing on the basic branch of the sample GitHub repository. Before starting with how we address the above requirements in the implementation of the basic branch, let us have a look at the solution architecture below and check out some core components of this initial scope. 

Solution Architecture

Basic Scope – Solution Architecture 

Component Deep Dive  

Let us deep dive into the Basic Scope solution components and see how the sample application deployed in your SAP BTP account will address our SAP sample partner’s requirements. 

The SaaS Business Application Service is a multitenant business application developed using the SAP CAP (Cloud Application Programming Model) framework. Choosing CAP as a framework helped us meet the partner requirements. CAP has built-in support for schema separation with the help of SAP Service Manager. Data isolation across consumer tenants, automation of HDI Container creation and deletion on tenant lifecycle hooks (onboarding and offboarding), also come out of the box with the framework. In addition to that, CAP has built-in support for SAP Fiori Elements frontends, which is also compliant with SAP Fiori Design Guidelines.  

Our multitenant SaaS application’s central entry point is the Approuter application. Currently, a standalone Approuter is a must have when developing multitenant applications on SAP BTP. With the help of an XSUAA service instance, Approuter has a built-in support for login isolation across multiple consumer tenants. For more information, please refer to the detailed documentation. 

The Application Autoscaler, Application Logging, Alert Notification and Credential Store services provided by SAP BTP support some of the most basic requirements since, SAP Credential Store is the recommended place for storing required credentials and the Application Logging service helps us to collect essential logs. The Application Autoscaler lets you automatically increase or decrease the number of your application instances based on the policies you have defined in terms of memory consumed, CPU, response time, or throughput. Real-time notifications for administrators or operators can be sent in real-time with the help of the Alert Notification service.  

One of the other requirements was having a Multitenant SaaS API for this Basic Scope SaaS application so that consumers could easily integrate data from any kind of system. In this case, you will learn how to deploy a CAP based backing service. A backing service is simply any service that is consumed by an application. For example, in SAP BTP, SAP HANA Cloud, and XSUAA are backing services. In this specific use case, you will deploy our own backing service providing a multitenant SaaS API. This allows you to create a separate SaaS API service instance in consumer subaccounts with unique credentials for each tenant subaccount. After this creation, this service instance can be consumed by any application in the tenant subaccount or by other third-party applications. For implementation details, please refer to the relevant documentation in the provided GitHub repository. 

Summary & Conclusion

By following this blog post, you have gained important insights on how a SAP partner’s requirement can be solved by developing a multitenant application in SAP BTP. Through the architectural diagram, you have seen which problems can be overcome with which implementation or service.

For detailed information, please refer to our sample GitHub repository. For a deep understanding of the architecture, we strongly recommend deploying the basic branch to your SAP BTP Trial account or your SAP BTP PAYG account and experimenting by yourself. To do so, please follow the steps described in the Github repository step by step guide. 

Please share your thoughts and experiences with us in the comments. We are looking forward to hearing your thoughts and feedback and feel free to follow Alper Dedeoglu for future posts.

I would like to take this opportunity to thank Martin Frick, Uwe Klasing, Anirban Majumdar and Ajit Kumar Panda  for the great collaboration and support.

Further Readings & Actions

You can explore the links below to further your understanding of the concepts covered in this blog post.

Developing Multitenant Applications in the Cloud Foundry Environment

The hidden life of ServiceManager handled containers

SAP Approuter

Getting your head into Cloud Application Programming model multitenancy

Follow SAP Business Technology Platform Topic Page

Ask questions about SAP BTP, Cloud Foundry environment and follow