Skip to Content
Technical Articles
Author's profile photo Martin Frick
Martin Frick
November 29, 2022 6 minute read

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

Important Links

General

SAP BTP, Cloud Foundry Runtime scenario

SAP BTP, Kyma Runtime scenario

Hello and welcome again to the last part of the blog post series on building your own “Multitenant SaaS application on SAP BTP using CAP”, based on the SAP BTP, Cloud Foundry Runtime. This blog post will summarize the extensive Expert Features. If you are interested in building Multitenant SaaS applications on SAP BTP using CAP, based on the SAP BTP, Kyma Runtime, please check the following blog post.

In the Overview blog post, you have learned the general idea and motivation of developing multitenant SaaS applications on SAP BTP, in the Basic Version blog post you learned the essential implementation specifics of a multitenant SaaS application. The Advanced Version blog post demonstrated how to incorporate central user management or integrate On-Premise systems like SAP S/4HANA to get your SaaS application one step closer to being ready for production.

In this final blog post of our series, you will be focusing on the Expert Features, which is again provided in our sample repository. This blog post covers a plethora of SaaS-related expert features and provides a variety of valuable tutorials, documentation as well as tips and tricks that will jump-start your project.

Let’s first grasp the expert scenario and the derived requirements for the existing SaaS application of our ancient SAP sample partner, CaveStone. After checking the architecture solution diagram, we will move on to summarize the various Expert Feature topics! Excited to see what we have in store for this last part of our blog post series? Promised, it will be a gold mine!

Scenario & Requirements

In this scenario, CaveStone has completed and deployed the Basic and Advanced Version. The developer team is very excited by what they have seen so far. Still, before they can get their own SaaS solution to the SAP Store, there are some more questions and requirements they would like to clarify first. In addition to the Basic and Advanced Version, an understanding of how to implement the following expert requirements was determined:

  1. How can the team develop CAP-based SaaS apps locally or in a hybrid setup?
  2. How can a SaaS solution be deployed to multiple SAP BTP regions?
  3. Does SAP BTP provide services to support DevOps requirements?
  4. Can a custom domain be used for the SaaS consumer tenants?
  5. If there is a need to back up database containers, how can that be done?
  6. Is there a way that SaaS consumers can extend the existing SaaS application?
  7. Can e-mails be sent from within the SaaS application logic easily?
  8. What if a SaaS consumer requires a custom theme? Is that possible and how?
  9. Let’s assume a consumer has its own Identity Provider – Can we integrate that?

As you can see, the partner has a lot of interesting requirements and questions you might also ask yourself after completing the Basic and Advanced Version. Well, let us have a look at the architectural diagram of the Expert Features first, which contains some more components to cover the above requirements.

Expert%20Features%20%u2013%20Solution%20Architecture

Expert Features – Solution Architecture

As you probably noticed, the architecture is quite similar to the Advanced Version and only contains three more services namely SAP Continuous Integration and Delivery, SAP Cloud Transport Management, SAP Custom Domain, and an additional SAP IAS tenant. All these additional services and usage samples will be covered in detail by the respective Expert Feature chapters. 

Requirement Implementation

Whenever code snippets are required for any of the Expert Features, they are provided in a separate folder among the feature docs.

The essential requirement to support local and hybrid development is described in great detail by the following documentation (click here) and provides guidance on how to work in a local environment with CAP multitenancy features, master API testing, and many other tips and tricks that will ease a developer’s life!

If you are planning to deploy your SaaS solution to multiple SAP BTP regions, you should not miss the following documentation (click here), which comes with a lot of aspects and considerations on this topic. As the requirement is very diverse and detailed guidance can fill books, the provided samples shall give you a very first idea of how to get your personal multi region architecture and account setup started.

Smart DevOps processes are essential when planning and designing a production deployment. Check the respective Expert Feature documentation on how to use the SAP CI/CD service (click here) in combination with the SAP Cloud Transport Management service (click here). The provided code snippets and detailed step-by-step guides will help you set up a basic DevOps flow for the sample application.

A professional SaaS application should make use of a proper Custom Domain. While for test and validation scenarios the default domain (cfapps) might be sufficient, in a production scenario you most likely have to provide your consumers with a dedicated subdomain xyz.susaas.com. In this part (click here) of the Expert Features, you will learn in detail how to set up a custom domain for your sample application.

As with most SaaS applications, the data of your SaaS consumers is at the heart of the solution. Being able to manage (click here) and administrate (click here) SAP HDI database containers including backups (click here) is essential when productizing your SaaS solution. You will get an idea of how to get started by visiting the linked Expert Feature chapters.

Closely related to the management of database containers are data model updates. Whenever you update your data model definition, the respective changes need to be distributed and deployed to your tenant database containers. Check the following part of the Expert Features (click here) to learn how such updates can be done using sample HTTP requests.

Your SaaS solution might be great and fit the requirements of your consumers to 99 % but let us guarantee you something. There will always be that one consumer who needs an additional field in one of the available forms. Fortunately, CAP supports extension scenarios using Consumer Extensibility (click here) or Feature Toggles (click here). Both topics will be covered in detail including sample code snippets in our documentation.

You already learned how to use the Alert Notification service to receive application notifications. While this is a nice feature for monitoring purposes, it will most likely not be sufficient for the messaging requirements of a productive SaaS application. If you plan to send emails from within your application logic to the users of your SaaS solution, consult the following sample documentation (click here) of the Expert Features.

A company’s theme and style are usually among the most important selling points and help employees and customers when it comes to brand recognition. So why not giving your SaaS consumers the option to create an own theme for their SaaS tenant? Learn how to do so using the SAP Theme Designer service in the following Expert Feature (click here)!

Let’s assume for the moment that you intend to provide your SaaS service to a significant B2C client with hundreds or perhaps thousands of users. This will change the game in a number of ways. One requirement that will be taken to another level is user management. Learn in the following chapter (click here) of the Expert Features, how to integrate a consumer’s own Identity Provider like Azure Active Directory with your SaaS application. Learn about several alternatives and select the one that best satisfies the needs of your customers.

This is just a very brief summary of the various topics that the Expert Features cover in detail. Start right away by digging deeper into the very first subject that is at the top of your list!

Conclusion

With this blog post, you have finally concluded your SaaS journey. You started with the Overview blog post, learned how to deploy a simple SaaS application in the Basic Version, sharpened your knowledge in the Advanced Version, and now spiced up your skills to enhance own SaaS solutions with our Expert Feature topics on your road to production.

From tips and tricks for local development, a simple DevOps setup, the administration, and management of database containers, or the usage of a custom domain for your solution – This blog post wraps up the topic of Multitenant SaaS application on SAP BTP using CAP, and releases you into the wild with a bag full of useful knowledge and resources for your reference!

Feel free to try out the Expert Features with your own SAP BTP account and share your feedback! We are looking forward to hearing from you. To stay up to date or to get in contact, follow my colleague Alper Dedeoglu and myself Martin Frick!

Further Readings

Regarding this Expert Features, you will find a lot of further content linked in the different chapters provided in the GitHub documentation. The following list contains just some selected highlights.

SAP Help – SAP HDI Administration

SAP Help – Custom Domain Service

CAP documentation – Extending SaaS Apps

SAP BTP Multi-Region reference architectures for High Availability and Resiliency 

Assigned Tags

      9 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo max jessi
      max jessi

      This is brilliant, thanks for these blog series!

      Author's profile photo Martin Frick
      Martin Frick
      Blog Post Author

      Thanks for that friendly feedback! 😀

      Author's profile photo Harikishore Sreenivasalu
      Harikishore Sreenivasalu

      Thank you Martin, great series. I have a question on the HANA Cloud tenant. We have scenario of data replication using HANA SDI from subscriber's S4/HANA / SAP ECC into the HANA containers. If the HANA Cloud need to deployed on the customer's subaccount, can that be managed ?

      Author's profile photo Martin Frick
      Martin Frick
      Blog Post Author

      Hi Harikishore,

      thanks for your comment and that interesting question! Would you be so kind to share some more details about your requirement so we can think about potential ideas please? Are you planning to connect your SaaS application to a SAP HANA Cloud running in the customers own SAP BTP Subaccount (different global account) or in the SaaS subaccount provided by you as the SaaS provider?

      Thanks for further input!

      Martin

      Author's profile photo Harikishore Sreenivasalu
      Harikishore Sreenivasalu

      HI Martin

      We would like to have the SaaS application connecting to dedicated SAP HANA Cloud in the SaaS provider subaccount. Our Pricing and CPQ application requires data replication from Customer's S4/HANA or SAP ECC to a dedicated SAP HANA Cloud tenant for each customer instead of 1 SAP HANA Cloud Tenant with multiple containers.

      The location of the SAP HANA Cloud tenant needs to follow customer's Hyperscaler choise and data center location due to data protection and privacy.

       

      regards

      Harikishore

      Author's profile photo Martin Frick
      Martin Frick
      Blog Post Author

      Hi Harikishore,

      thanks again for that interesting challenge and the additional information. We've done some validations and hope that the following results and hints will help you with the mentioned scenario.

       

      SAP HANA Cloud and SaaS app in different regions

      If you're planning to connect a SaaS application to SAP HANA Cloud instances in different regions (e.g. SaaS application running in eu10 and HANA Cloud instance running in us20), to my best knowledge there is no other way then manually connecting to the HANA Cloud instances from within your application logic using @sap/hdbext npm package. You might store the relation and credentials of each HANA Cloud instance in a save place and read it when connecting from within your application logic. In my tests I was not able to create a container instance for a HANA Cloud instance running in another region using the Service Manager (container plan). The HANA Cloud needs to be available in the space in which your Service Manager is running. Consider following similar questions in the community (click here), if this topic is of interest for you or reach out to the respective community members.

       

      SAP HANA Cloud and SaaS app in same region

      If you set up your HANA Cloud instances into the same region as your SaaS application you can use a simplified option explained below. As you are offering your consumers to choose a region for their HANA Cloud instance, I assume you're anyway planning to deploy the SaaS application itself to the respective regions? Otherwise data would be stored in e.g., eu10 (with AWS) but processed in us20 (with) Azure which doesn't make sense to me from a data security perspective.

      Process

      Since a few releases, the @sap/cds-mtxs package provides you an option to pass a database_id in the subscription payload (see here). If you adapt the saas-registry config in your your mta.yaml accordingly, you can provide the database_id of an existing SAP HANA Cloud database created in or shared with your Space upon setup of a new subscription (see screenshot).

      Alternatively, you can also try to setup a new HANA Cloud instance during the subscription process automatically if required and use the resulting datbase_id instead of creating the HANA Cloud instance upfront manually for each new customer (depending on your use-case).

      mta.yaml

      config:
        xsappname: ~{susaas-uaa/XSAPPNAME}
        appName: ~{susaas-approuter/application}-${org}
        displayName: Sustainable SaaS ${space}
        description: Sustainable SaaS Application
        category: SaaS Multitenant Apps
        propagateParams: true
        paramsSchema: 
          schemas: 
            subscription:
              create:
                parameters:
                  $schema: 'http://json-schema.org/draft-04/schema#'
                  additionalProperties: false
                  _show_form_view: true
                  type: 'object'
                  properties:
                    databaseId:
                      type: 'string'
                      title: 'SAP HANA Cloud Database ID'
                      description: 'Enter SAP HANA Cloud Database ID'

      During subscription, you can then read this database_id parameter and inject it into the subscription payload in the required format. Check the sample below to see how to read and inject the parameter into the subscription payload.

      srv/provisioning.js

      service.on('UPDATE', 'tenant', async (req, next) => {
        console.log("Subscription data:",JSON.stringify(req.data));
        const Automator = require("./utils/automator");


        if(req.data?.subscriptionParams?.databaseId){
            let params = {
                "_": {
                    "hdi": {
                        "create":{
                            "provisioning_parameters": { 
                                "database_id" :  req.data?.subscriptionParams?.databaseId
                            }
                        }
                    }
                }
            };

            req.data = { ...req.data, ...params }
        }

      This will deploy the tenant container to the respective database defined during the subscription process. You can validate this by checking the service-manager details for each container. In the below example you can see that the two available tenants (63c57b07 and 4f647373) are connected to different SAP HANA Cloud instances.

      This approach hasn't been tested extensively by us so in case you want to try it yourself, please do some proper testing on your side covering the whole lifecycle of the database container (create, update, delete aso.). Furthermore, you might encounter issues with a shared database container as used in our sample. For my tests I had to remove that component which doesn't mean it is somehow possible 🙂

      Feel free reach out in case of further questions!

      Martin

      Author's profile photo Harikishore Sreenivasalu
      Harikishore Sreenivasalu

      This looks promising. Let me run through the approach and get back to you. Thank you very much for the detailed explanation and suggestions.

      Author's profile photo Timo Stark
      Timo Stark

      Hi Martin,

      While the paramsSchema really looks promising: Is there any official documentation for this? I can not find anything about the possibly valid fields / values.

      There might be some interesting scenarios if we can have influence on the subscription screen.. Examples would be showing manual pre-/post processing activities, nice value helps, some additional links / documentation references, [...]

      Thanks & Regards,

      Timo

       

      Author's profile photo Martin Frick
      Martin Frick
      Blog Post Author

      Hi Timo Stark,

      Thank you for your question, however, we regret to inform you that at present, there is (at least to our knowledge) no official documentation available regarding these fields and configuration options. As we also encountered this issue through a trial and error process, we understand your concern.

      Your suggestions regarding pre- and post-processing are noteworthy and we will strive to identify the relevant team responsible for documenting this in a suitable manner. While we have included this on our to-do list, we cannot commit to providing a resolution in the immediate future.

      We appreciate your active participation in the community and thank you for bringing up this important matter. Your feedback is valuable and assists us in prioritizing and enhancing our material according to the community's needs. We encourage you to continue sharing your thoughts, ideas and insights with us.

      Martin