Skip to content

2. Deploy as SaaS

Jump to bottom
Arley Triana Morin edited this page Jul 6, 2023 · 25 revisions

After completing the development of the application, the next step is to deploy it as a SaaS (Software-as-a-Service) application. Basically, this means that we have to fulfill these requirements:

  • Multitenancy — The single deployed application shall be used by multiple customers (tenants) in parallel.

  • Tenant Provisioning — When new tenants subscribe to the SaaS application, tenant-specific resources, such as new messaging channels, database schemas, or containers, must be provisioned.

  • Tenant Isolation — To maintain tenant isolation, incoming requests from different tenants must be served in isolation, e.g., using separate databases with dedicated connection pools for each tenant to prevent data leakage and ensure data security.

  • Dynamic Extensibility — all customers need to tailor applications to their specific needs without modifying the underlying application code. This includes the ability to add new fields and entities dynamically at runtime, enabling customization while maintaining the integrity and stability of the shared application. Since SaaS applications serve multiple tenants, code modification is not possible. Instead, everything must happen dynamically at runtime.

Let's see how to accomplish that in a CAP-based application...

Enable MTX

The great news is that CAP applications come with built-in support for multitenancy and dynamic extensibility. We just need to enable multitenancy and extensibility by running a simple command-line instruction:

cds add mtx

To do this in the Business Application Studio (or VSCode), follow these steps:

  1. Switch back to the incidents project.

  2. Open a new terminal: Menu > Terminal > New Terminal:

    image-20221110184007158

  3. Copy and paste the above command into the terminal and press Return:

    image-20221110205327059

Note: If you encounter an error message regarding packages that have not been installed yet, run npm i before running cds add mtx again.

This command adds the necessary lines to our project's package.json file. No other changes are required to our project's content.

image-20221110204809987

  1. Run npm install to install the new dependency to @sap/cds-mtxs. This package implements all the capabilities for multitenancy, toggles, and extensibility.
npm install

  1. In the terminal, click on the Split Terminal button at the top of the terminal panel, and then select bash:

    image-20221110191842539

  2. Navigate to the sidecar directory:

cd mtx/sidecar
  1. Run npm i to install the new dependency for sidecar:
npm i
  1. Use the following command to instruct cds to watch for relevant changes in the specified project or current working directory. It will compile and run the server whenever a change is detected:
cds w

Restart the Server

Starting with cds version 6 and with the new streamlined implementation of @sap/cds-mtxs, CAP allows us to test fully-fledged multitenant applications in local mock environments using an SQLite database. This eliminates the previous requirement of deploying to a productive environment with SAP HANA databases, which was complex, expensive, and time-consuming.

To restart the server, follow these steps:

  1. Terminate the server currently listening on port 4004 by pressing Ctrl + C (or ^C) in the terminal.

  2. Run the following command in the terminal:

cds w

  1. After executing the command, you should see the following output in your terminal:

    image-20221110190854830

Note: The new lines in the output, inform us about the multitenancy services now being served in addition to the Incidents Service. It also mentions that no application database has been bootstrapped yet, as this will be deferred until tenant subscriptions occur.

Subscribe Customers

Now that our server runs in multitenancy mode, it's ready to accept tenant subscriptions. Let's subscribe to three tenants: t1, t2, and t3. While in production, this process would typically be handled through the SAP BTP's SaaS Provisioning Service. However, we can use the cds subscribe command during development to simulate the subscription process.

To perform the subscription and observe the server's reactions in the log, follow these steps:

  1. In the terminal where the server output is displayed, click on the Split Terminal button at the top of the terminal panel and then select bash:

    image-20221110191842539

  2. Copy and paste these commands into the right-hand-side terminal:

cds subscribe t1 --to http://localhost:4005 -u alice
cds subscribe t2 --to http://localhost:4005 -u carol
cds subscribe t3 --to http://localhost:4005 -u erin

The password to all users is empty, you can hit enter each time you are asked for one

  1. See the left-hand-side terminal's showing the server's reactions:

image-20221110192159954

Customers vs Tenants

We frequently use the terms "customer" and "tenant" in combination, sometimes in some in-precise stand-ins for each other. Therefore let's clarify these terms in detail here:

  • SaaS customers are BTP customers who subscribe to SaaS applications
  • Each subscription creates a new tenant → tenants represent subscriptions
  • Tenants live in isolation → each has a separate database, separate extensions
  • SaaS customers can create multiple subscriptions → hence have multiple tenants, e.g. for test and production.

Adding Users

In a production environment, users would be added by SaaS customers individually via respective identity provider services. However, during development, CAP servers run with so-called mocked authentication using statically registered users.

To simplify the process and speed things up, we have preconfigured the users in the .cdsrc.json file of the incidents project upfront.

{
   "requires": {
      "auth": {
         "users": {
            "alice": { "tenant": "t1", "roles": [ "cds.Subscriber", "admin" ] },
            "bob":   { "tenant": "t1", "roles": [ "cds.ExtensionDeveloper" ] },
            "carol": { "tenant": "t2", "roles": [ "cds.Subscriber", "admin" ] },
            "erin":  { "tenant": "t3", "roles": [ "cds.Subscriber", "admin" ] }
         },
         "tenants": {
            "t2": { "features": [] },
            "t3": { "features": ["solar"] }
         }
      }
   }
}
  • Note 1: The .cdsrc.json file contains configurations similar to package.json but is not meant for production use.
  • Note 2: This information is provided for your understanding, and no additional action is required from you. The users are already preconfigured in the file.

Summary

We've now built an application that is deployed as a SaaS solution and subscribed to two SaaS customers as tenants t1, t2, and t3.

CAP Spotlights:

  • Intrinsic Multitenancy and Extensibility — When building a CAP application you don't care about multitenancy or extensibility, but just focus on your domain tasks at hand. No extension points need to be prepared. Later, you can simply deploy it as a multitenant SaaS application, with simple switches turned on or off. CAP cares for all tenant isolation as well as the provisioning of tenant-specific resources out of the box.
  • Streamlined MTX — While running multitenant SaaS software frequently means doing so in productive environments only, with complex and tedious setups, and poor turn-around times, CAP's streamlined MTX services allow to run your apps in multitenant mode and test extensibility while staying with minimum setup and minimized costs.

In the next exercise 3 — Custom Extensions we will slip into the shoes of an individual SaaS customer, adding extensions to tailor it to the customer's specific needs.

Clone this wiki locally