Skip to Content
Technical Articles
Author's profile photo Alper Dedeoglu

Multitenant SaaS apps on SAP BTP using CAP? Tried-and-True! – The Advanced Scope

Important Links

SAP BTP, Cloud Foundry Runtime scenario

OverviewBasic Scope / Advanced Scope / Expert Scope

SAP-samples GitHub Repository – Cloud Foundry

SAP BTP, Kyma Runtime scenario

SAP-samples GitHub Repository – Kyma

SAP BTP, Cloud Foundry and Kyma Runtime – A Comparative Analysis
Multitenant SaaS applications on SAP BTP using CAP? SAP BTP, Kyma Runtime!
SaaS Self-Onboarding and One-Domain Concept in SAP BTP, Kyma Runtime using CAP

Hello and welcome again to the third part of the blog post series on building your own multitenant SaaS application on SAP BTP using CAP. The third blog post of the series will summarize the Advanced Scope 

In the overview blogpost you have learned the general idea and motivation of developing multitenant SaaS applications in SAP BTP, in the basic scope blog post you learned the fundamental implementation details of the multitenant SaaS application. In this blog post you will learn about the Advanced Scope, which will take you one step closer to production readiness. 

In this blog post you will be focusing on the advanced scope, which is implemented and documented in our sample repository. 

You will first grasp the scenario and the advanced scope requirements for this SaaS application from the SAP sample partner, CaveStone. You will then see the architectural solution diagram before moving on to the solution’s implementation overview. 

Scenario & Requirements   

In this scenario our SAP Partner, has successfully completed and deployed the basic scope, then they decided to take their solution to the next step. Of course, the next step has its own requirements. In addition to the basic scope, the necessity of implementing the following requirements was determined because of the analysis. At the end there are only three additional requirements this time as described below. 

  1. Having a central identity provider (IDP) for SaaS provider that is highly configurable 
  2. In addition to have a multitenant SaaS API, the relevant API should have enterprise-level security, traceability, and monetisation. Also, the multitenant SaaS API should offer different request limits for different service plans.  
  3. The capability for various clients to transfer data through the multi-tenant API from their SAP systems to the SAP Partners multitenant SaaS solution 

Next, you might want to look over the architectural diagram now that you have a better understanding of the requirements. 



Advanced Scope – Solution Architecture 

Solution Implementation 

The first requirement is a centralized user storage. Software service providers naturally desire to manage their customers independently from the global SAP ID service, which is the major justification for this requirement. Additionally, it is typical for a software service provider to desire to change their multitenant application’s login interface. Given that the SAP IAS (Identity Authentication Service) satisfies all these criteria; you will configure the SAP IAS service in this sample application as the primary identity provider for your multitenant SaaS application. Relevant documentation can be found on this section of repository. 

The second requirement was adding enterprise level qualities to the API endpoint, which is deployed with basic scope. SAP API Management service of the Integration Suite serves this purpose. With many different policy options, it is possible to add enterprise-level qualities to your endpoints, such as IP whitelisting, rate limiting, JSON (JavaScript Object Notation) thread protection, Regex protection, and so on. In this sample application, you will be implementing an API policy with the help of SAP API Management. With this policy, you will be able to allow different numbers of requests for a given time interval to your API according to different service plans. Relevant configuration is documented in this section of the repository. 

The last requirement is pushing data from different SAP systems of the clients (tenants) to your multitenant SaaS API to convert data into value. In this sample, you will learn how to push data from an SAP S/4HANA system. You will be implementing your ABAP program, and after that, you will be pushing data to your multitenant SaaS solution over your multitenant SaaS API endpoint. Implementation and details can be found here.


With this blog post, you have continued your journey, which you started with the overview blog post and the basic scope blog post. You have seen how to integrate helpful SAP BTP services such as SAP IAS and SAP API Management. Following that, you learned how to use the ABAP stack to implement a push approach in the SAP S/4HANA system. Overall, you got one step closer to production readiness. With all the implementation details and step-by-step guide, feel free to try out the advanced scope with your free-tier accounts and share your feedback! We are looking forward to hearing from you.

Feel free to follow me from here: SAP Community profile.

Further Readings 

You might find following documentations, blog posts enlightening. Feel free to read them for detailed information. 

SAP API Management Official Documentation 

SAP API Management Full Overview Blog Post 

SAP Identity Authentication Service Official Documentation 

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Alejandro Sensejl
      Alejandro Sensejl

      Hi SAP Community profile , thanks for sharing and especially for Git Repo! What I do not understand as it is not explained in architecture or descriptions: Do both provider and consumer have to be in same global account? I would expect to have two global accounts: provider from partner global account and consumer from customer global account. Cheers, Alej

      Author's profile photo Alper Dedeoglu
      Alper Dedeoglu
      Blog Post Author

      Hi Alejandro,
      Thanks for reaching out.
      Yes, provider and and consumer should be in same global account to be able to work with current setup.



      Author's profile photo Alejandro Sensejl
      Alejandro Sensejl

      Thanks for your lightning fast response. What is the recommended partner use case for this? Should partner own global account or customer?

      Author's profile photo Alper Dedeoglu
      Alper Dedeoglu
      Blog Post Author

      SAP Partners should own the SAP BTP Global Account since they are the provider of software. Then their customers can pay for the service they get.

      For general idea I would strongly recommend to go through the documentation of the repository.

      You can check SAP Store website for current SAP and SAP Partner solutions.

      For the example use case, I would strongly recommend to read the blog post from my colleague Martin Frick.


      Author's profile photo Alejandro Sensejl
      Alejandro Sensejl

      Thanks for clarification. 👍